균열 생긴 ‘취약점 공개’ 생태계···CISO가 직면한 과제

책임 있는 공개(responsible disclosure)는 ‘옳은 일을 하면’ 신속한 대응과 공정한 대우, 존중을 받게 되며, 경우에 따라서는 보상까지 뒤따른다는 전제를 바탕으로 작동해 왔다. 그러나 이런 전제는 점차 현실과 어긋나고 있다. 이때 기업은 보안 연구자와의 신뢰 관계를 잃고, 규제·법적·평판상의 리스크를 동시에 떠안을 수 있다.

최근 몇 년간 보안 연구자는 책임 있게 공개한 취약점에 대해 기업의 공식적인 인정을 받기까지 수개월, 길게는 1년 이상을 기다려야 했다. 그 사이 해당 취약점이 조용히 고객을 위험에 노출시키는 경우도 적지 않았다. 침묵이 이어지거나 취약점 심각도 평가를 둘러싼 의견 차이 등이 자주 반복되면서 연구자의 불만이 커졌고, 그 결과 일부 연구자는 공개 폭로나 법적 대응에 나섰다. 이 과정에서 기업이 해당 행위를 협박이나 갈취로 규정한 사례도 있었다.

취약점 보고 절차가 지연되고 형식적으로 굳어질 뿐만 아니라 보상마저 줄어들면서, 취약점 제보가 기업과 연구자가 협력해 문제를 해결하는 대신 갈등과 압박으로 이어지는 경우가 점점 늘고 있다. 기업 CISO에게 이는 더 이상 윤리의 문제가 아니다. 거버넌스와 리스크 관리 차원의 문제로 성격이 바뀌고 있다.

최근의 분수령

가장 최근 사례로는 리액트2쉘 취약점(React2Shell, CVE-2025-55182)이 있다. 이는 적절한 구조가 갖춰졌을 때 책임 있는 공개가 어떻게 작동할 수 있는지를 보여주는 사례다. 해당 취약점은 2025년 11월 29일 리액트 유지관리자에게 비공개로 전달됐다. 이후 리액트 팀과 넥스트.js(Next.js) 유지관리자, 넥스트.js를 관리하는 웹 플랫폼 기업 버셀(Vercel), 아마존웹서비스(AWS)와 클라우드플레어 등 주요 클라우드 사업자가 협력 대응하면서, 공개 전에 패치를 개발하고 검증할 수 있었다.

신속한 인지와 조치에도 불구하고 이 취약점은 실제 환경에서 빠르게 악용됐다. 대응 책임은 유지관리자, 프레임워크 통합 주체, 하위 사용자 전반으로 분산됐다. 리액트가 현대 웹 스택의 핵심인 만큼, 해당 취약점의 영향은 전 세계 개발 및 보안 팀으로 확산됐다. 이는 공개 절차가 비교적 잘 작동한 사례조차도 광범위한 운영 리스크로 이어질 수 있음을 보여준다.

리액트는 리액트 재단을 중심으로 한 제도적 지원과 기술 대기업 다수의 후원을 받고 있다. 그 덕분에 취약점에 대한 공동 대응과 원활한 커뮤니케이션, 장기적인 유지보수가 가능했다.

반면 기업의 후원도, 공식 보안 조직도, 버그 바운티 프로그램도 없는 상태일 때, 널리 사용되는 오픈소스 프로젝트에서 이와 유사한 치명적인 취약점이 발견되는 경우도 있다.

이런 상황에서 취약점을 악용하는 행위는 명백히 비윤리적이다. 그러나 문제를 제보하는 과정 역시 결과를 장담할 수 없는 무보수 노동으로 이어지는 경우가 많다. 리액트2쉘 이후 실무자 커뮤니티에서 제기된 고민은 특정 사건 자체가 아니라, 보다 구조적인 인센티브의 공백에 있었다. 책임 있는 취약점 공개가 보상도, 신속한 대응에 대한 확실한 약속도 제공하지 못한다면, 연구자가 계속해서 ‘옳은 선택’을 할 현실적인 동기는 무엇이냐는 질문이다.

이 질문이 많은 공감을 얻은 이유는 새로워서가 아니다. 취약점 공개가 본래 작동해야 하는 방식과 실제 현장의 현실 사이의 괴리가 커지고 있음을 드러내기 때문이다.

윤리적 취약점 공개의 회색지대

이런 상황이 반복되면서, 취약점 연구는 더 이상 순수한 협력에 머물지 않게 됐다. 문제 해결을 위한 제보와 기업을 상대로 한 압박 사이의 경계가 흐려지고 있으며, 이 흐름은 취약점 공개 분쟁을 둘러싼 여러 실패 양상에서 공통적으로 나타난다.

침묵과 심각도 공방: 보안 연구자가 상세한 취약점 보고서를 제출해도 수개월 동안 아무런 답변을 받지 못하거나, CVE 적용 범위와 CVSS 점수를 둘러싼 의견 차이로 기술 논의가 사실상 협상으로 변질되는 사례가 반복되고 있다. 연구자는 취약점 수준이 과소평가되지 않기 위해 보다 공격적으로 위험성을 입증하려 하고, 벤더는 과장된 리스크라고 판단하며 이에 맞서는 구도가 형성된다. 일부 버그 바운티 참여자는 이런 저항과 지연을 예상해, 초기 단계부터 취약점 심각도를 높게 설정하기도 한다.

또 다른 서비스 거부(DoS) 절차: 자동화된 스캐너와 AI 기반 퍼징 도구, 현실성과 거리가 있는 이론적 취약점이 유지관리자와 보안 조직으로 대량 유입되면서, 신호 대비 잡음이 지나치게 커지고 있다. 이 같은 문제는 cURL 프로젝트 설립자인 다니엘 스텐베르그가 반복적으로 지적해 온 부분이기도 하다. 이에 대한 방어적 대응으로 유지관리자는 점점 더 구체적인 악용 가능성 증명을 요구하게 됐고, 그 결과 정당한 취약점조차 논의 대상이 되지 못하는 상황이 벌어지고 있다. 일부 프로젝트에서는 버그 바운티가 실제 보안 개선에 기여하는지, 아니면 인센티브라는 이름으로 분류·검증 비용을 외부로 전가하는 수단에 불과한지에 대한 회의론까지 제기되고 있다.

대응을 끌어내기 위한 압박 확대: 기존의 취약점 공개 채널이 무응답이거나 문제를 가볍게 넘기는 태도를 보일 경우, 일부 연구자는 대응을 이끌어내기 위해 공개 압박이나 법적 위협, 윤리 논란을 부를 수 있는 방식으로 취약점을 시연하기도 한다.

이러한 실패 양상은 각각만 놓고 보면 나름의 합리성을 갖고 있는 듯 보인다. 그러나 이들이 맞물릴 경우 신뢰는 빠르게 훼손되고, 책임 있는 공개는 협력이 아닌 대립으로 번질 수 있다.

실제 사례

2025년 한 대형 배송 플랫폼에서 이메일 스푸핑 취약점이 보고됐지만, 해당 기업은 문제가 적용 범위 밖이라는 판단을 내렸고, 이는 심각도와 영향도를 둘러싼 분쟁으로 이어졌다. 문제의 핵심은 취약점의 존재 여부가 아니라, 기업 내부에서 정의한 리스크 기준을 넘는지 여부였다. 공개 절차는 사실상 중단됐고 양측의 불만은 커졌다. 그 과정에서 기업이 문제 제기를 협박에 준하는 행위로 간주하면서, 취약점 제보자는 버그 바운티 프로그램에서 배제되기에 이르렀다.

유사한 양상이 한 차량 호출 서비스 기업에서도 나타났다. 여러 연구자가 해당 기업의 도메인에서 발송된 것처럼 보이는 이메일을 보낼 수 있는 취약점을 보고했지만, 명확한 재현 절차와 반복적인 후속 문의에도 불구하고 1년 넘게 아무런 답변을 받지 못했다. 윤리적 공개는 조치로 이어지지 않았고, 침묵만 돌아왔다.

다른 한편에서는 동일한 취약점에 대해 여러 주체가 CVE(공통 취약점 식별자) 귀속을 두고 다투는 사례도 발생했다. 원래는 조율과 협력을 위한 제도가 인정을 받기 위한 경쟁으로 변질되면서, 문제에 대한 인식이 왜곡되는 결과를 낳았다.

더 우려스러운 사례는 연구자가 아예 윤리적 선을 넘은 경우다. 오픈소스 라이브러리를 탈취해 클라우드 자격 증명을 수집하거나, 정상적인 패키지를 장악해 구인 구직 메시지를 삽입하는 방식으로 하위 사용자를 위험에 빠뜨린 경우도 있었다. 이런 행위는 어떤 이유로도 정당화될 수 없다. 다만 이는 인내와 협력보다 주목도, 영향력에 점점 더 높은 보상을 제공하는 취약점 공개 생태계가 만들어낸 결과로 이해할 필요가 있다.

취약점 공개 갈등이 벌어지는 이유

이 같은 분쟁을 직업 윤리나 관행의 붕괴로만 설명하기 쉽지만, 그 이면에서는 여러 구조적 요인이 동시에 맞물리고 있다.

우선 취약점 보고 자체가 급증했다. 자동화 스캐너와 AI 기반 퍼징 도구가 확산되면서, 기술적으로는 유효하지만 실제 운영 환경에서는 의미가 크지 않은 취약점까지 대량으로 생성되고 있다. 이에 따라 유지관리자와 보안 팀은 제한된 시간과 자원 속에서 방대한 보고를 선별해야 하는 상황에 내몰리고 있다.

여기에 컴플라이언스 압박까지 더해지면서 기업의 대응은 더욱 경직됐다. 일단 CVE가 보고되면, 맥락이나 실제 악용 가능성이 충분히 검토되기도 전에 기본적으로 ‘문제’로 취급되는 경우가 많다. 실제 영향과는 무관하게 높은 심각도 점수가 매겨질 경우, 빌드 실패나 감사 대응, 경영진 보고로까지 이어지는 사례도 적지 않다. 이는 SCA 도구가 사실상 무시하거나 예외 처리해야 할 경계 사례 때문에 빌드를 차단하는 상황에 놓인 개발자들이 공통적으로 호소해 온 불만이기도 하다.

CVSS 점수 산정 방식 자체가 기계적으로 계산되며 특정 환경을 고려하지 않도록 설계돼 있다는 점도 문제다. 실제 영향이 거의 없는 특정 사례가 이미 악용되고 있는 취약점과 비슷한 점수를 받는 일이 발생하고, 이는 경고 피로와 점수에 대한 불신을 키우는 요인으로 작용한다.

여기에 더해 오픈소스 인프라는 여전히 구조적으로 자금이 부족한 상태에 놓여있다. 많은 핵심 구성 요소가 소수의 개인 유지관리자에 의해 관리되고 있지만, 이들은 수많은 서비스가 연결된 전 세계 의존 구조에서 발생하는 운영 비용을 떠안을 의무도, 감당할 역량도 갖추지 못한 경우가 대부분이다.

이런 환경에서 실제 환경에서의 영향 증명을 요구하는 것은 적대적인 대응이라기보다는 잡음을 걸러내기 위한 방어적 조치에 가깝다. 다만 겉보기에는 합리적으로 보이는 이러한 요구가, 이후 단계에서 또 다른 문제를 낳는다는 점이 간과되고 있다.

취약점 입증이 무보수 컨설팅이 되는 순간

많은 분쟁에서 공개가 무산되는 이유는 취약점이 존재하지 않아서가 아니라 실제 환경에서의 영향을 증명하는 과정이 감당하기 어려운 부담이기 때문이다. 실제로 어떤 영향을 미치는지를 입증하려면 환경별 분석이 필요하지만, 그 비용과 노력을 어느 쪽도 사전에 고려하지 않는 경우가 많다.

연구자는 현실적인 개념 증명(PoC)을 만들거나 공격 시나리오를 설명하고, 자신이 통제할 수 없는 다양한 설정 환경에서 가정을 검증해 달라는 요구를 받는다. 유지관리자 역시 원래 설계 범위를 훨씬 벗어난 하위 사용 환경과 활용 방식까지 고려해야 하는 상황에 놓인다. 양측 모두 보상 없이 시스템 전반을 분석하는 역할을 떠안게 되는 셈이다.

유지관리자가 의미 없는 보고를 걸러내려는 데에는 충분한 이유가 있다. 연구자 역시 문제 제기를 하기 위해 넘어야 할 문턱이 계속 높아지고 있다고 느낄 만하다. 문제는 이 과정에서 발생하는 비용과 부담을 어디에서도 책임지지 않는 구조라는 점이다.

CISO가 마주한 현실적 과제

기업 사이버보안 책임자에게 이 문제는 추상적인 논의가 아니라 현실적으로 영향을 미칠 수 있다.

취약점 공개 채널이 느리고, 무성의하거나, 대립한다고 인식하는 순간 연구자는 이탈하기 시작한다. 일부는 침묵을 택하고, 일부는 공개적으로 문제를 키운다. 또 다른 일부는 윤리적으로 논란의 소지가 있는 선택을 하기도 한다. 그러나 이런 결과 가운데 보안 수준을 실제로 높이는 경우는 많지 않다.

현실적으로 흐름을 좌우하는 대부분의 결정 권한은 소프트웨어 벤더, 플랫폼 업체, 오픈소스 관리 주체에 있다. 이런 환경에서 기업 CISO는 제품 보안 사고 대응 조직(PSIRT), 취약점 접수 체계, 공개 일정, 연구자와의 소통 방식을 총괄한다. 바로 이 지점에서 인센티브가 설정되고, 연구자 경험이 형성되며, 분류·판단 과정이 협력으로 이어질지, 갈등으로 이어질지가 갈린다.

벤더, 플랫폼, 오픈소스 환경과 맞닿아 있는 CISO에게 만능 해법은 없다. 다만 취약점 공개를 개인의 선의에 맡길 문제가 아니라, 명확한 책임과 절차를 갖춘 운영 기능으로 다루기 시작할 때 결과는 분명히 달라진다. 이때 CISO가 실질적으로 취할 수 있는 조치도 분명히 존재한다. 주요 대응 방안은 다음과 같다.

1. 취약점 제보에 대한 접수 및 초기 분류의 서비스 수준 기준을 설정하고, 수정에 시간이 걸리더라도 이를 일관되게 준수해야 한다.
2. 단순히 취약점을 접수하는 역할을 넘어, 연구자 경험 전반을 책임질 명확한 담당 주체를 지정할 필요가 있다.
3. 취약점 심각도 분류 기준을 공개하고, 제보 내용에 동의하지 않을 경우 그 판단 근거를 문서로 남겨야 한다.
4. 환경적 맥락을 고려하지 않은 채 CVSS 점수를 배포 차단의 기준으로 기계적으로 적용하는 관행은 피해야 한다.
5. 보고가 과도하게 몰릴 경우 서드파티 취약점 공개 프로그램이나 조정 기관을 활용해 마찰을 줄일 수 있다.
6. 버그 바운티 제공이 어려운 경우 금전적 보상 대신 의미 있는 비금전적 인정 방안을 마련해야 한다.
7. 내부적으로 종속성 패치를 진행할 경우, 수정 사항을 상위 오픈소스 프로젝트에 환원하는 데에도 책임을 져야 한다.
8. 선의의 테스트와 연구 활동에 대해 법적 보호를 명시하는 안전 조항을 제공함으로써 불필요한 대립을 줄일 수 있다.
9. 기업이 의존하고 있는 오픈소스 프로젝트에 대해 후원, 계약, 컨소시엄 참여 등 다양한 방식으로 재정적 지원을 해야 한다.
10. 취약점 입증 과정에서 어떤 수준의 증거를 요구하는지, 그리고 무엇까지는 요구하지 않는지를 명확히 밝혀야 한다.

이 조치들은 악용 코드 판매를 용인하자는 얘기도 아니고 취약점에 대한 몸값을 지불하라는 뜻도 아니다. 핵심은 보안 연구자에게 모든 책임을 맡긴 채 선의에만 기대는 방식으로는 책임 있는 공개가 유지되기 어렵다는 점을 인정해야 한다는 것이다.

의료, 금융, 교육 등 소프트웨어를 소비하는 기업에서 일하는 CISO에게 이 리스크는 각각 다른 방식으로 나타나지만, 그 심각성은 결코 작지 않다. 상위 단계에서 취약점 공개가 제대로 작동하지 않을 경우, 그 여파는 하위 단계에서 패치 지연, 취약한 임시 통제 수단, 불완전하거나 왜곡된 신호에 기반한 보안 의사결정 같은 문제로 이어질 수 있다.

이런 격차가 해결되지 않으면 결국 거버넌스 실패로 이어질 수 있다. 이미 알려진 취약점이 왜 패치되지 않았는지, 왜 위험 신호가 무시됐는지, 왜 벤더의 설명을 충분한 검증 없이 받아들였는지에 대해 기업이 설명하지 못하는 상황이 발생할 수 있다.

기업 CISO는 조달 요구사항 설정, 벤더에 대한 책임 부과, 그리고 취약점 데이터를 실제 환경에 맞게 얼마나 엄격하게 해석한 뒤 기업 차원의 대응으로 연결하는지를 통해 시스템에 영향을 미친다. 취약점 공개의 품질을 서드파티 리스크 요소로 다루는 일은 이제 선택이 아니라 필수에 가까워지고 있다.
dl-ciokorea@foundryco.com