curl 프로젝트, CVE 분쟁에서 승리: '이론적 위험'은 CVE가 아니다

A CVE Dispute

curl 프로젝트는 CNA(취약점 번호 발급 기관)로서 처음으로 CVE 분쟁을 겪었습니다. 보고자는 curl의 와일드카드 인증서 검증 버그에 CVE를 요구했지만, curl 팀은 'LOW 미만'의 극히 이론적인 위험이라 판단해 거부했습니다. MITRE의 최종 판정도 curl의 결정을 지지했습니다. 이 글은 CVE 발급의 생태계 비용, 낮은 심각도의 취약점 처리 원칙, 그리고 이번 분쟁의 기술적 세부 사항을 설명합니다.

모든 CVE는 엄청난 비용을 수반합니다. 그 비용은 우리에게 부담되지 않고 우리가 실제로 보거나 느끼지 못하지만, 생태계에 부담이 되는 비용이며 우리가 무시해서는 안 된다고 생각합니다.
  1. ealready_value

    > 모든 CVE에는 이렇게 막대한 비용이 따릅니다. 그 비용은 우리에게 부과되지 않고 우리가 실제로 보거나 느끼지 못하지만, 생태계에 부과되는 비용은 무시해서는 안 된다고 생각합니다.

    CVE에 대해 미묘한 관점을 취하지 않는 보안 팀이 많다는 점을 인식한다는 점에서 이 태도를 정말 높이 평가합니다. 예를 들어, 한 번은 보안 팀이 우분투에 기본으로 설치된 VMware 지원 패키지를 패치하도록 요구한 적이 있었는데, 우리는 EC2에서 실행 중이었고 해당 CVE는 VMware에서 실행되어야 했습니다. 그들과 논쟁하는 것은 무의미했습니다. 그들은 해당 CVE가 우리에게 적용되는지 확인하는 데 관심이 없었고, 단지 고쳐야 한다는 것만 관심이 있었기 때문입니다.

    보안을 담당해야 하는 많은 팀은 "이 CVE가 우리에게 영향을 미치는가?"라고 묻지 않고, 단순히 패치의 부담을 아래로, 밖으로 전가합니다. 어떤 경우에는, 업데이트하기 쉽고 중앙에서 배포할 수 있는 SaaS 제품의 경우처럼, 그 부담은 어렵기보다는 성가시고 좌절스럽습니다. 어떤 경우에는, 복잡한 배포가 있거나 고객이 제어하는 업데이트가 있는 경우처럼, 그러한 명령은 모든 낮은 CVE를 패치하기로 결정하지 않은 팀에게 큰 부담을 줍니다.

  2. Aurornis

    이 문제를 해결하기 위해 노력하는 동안 이 사람이 MITRE에 보낸 이메일 통신 중 일부를 볼 수 있다면 매우 흥미로울 것입니다.

    우리 모두는 어떤 사람들이 LLM을 사용하여 코드를 작성하고 PR을 제출하는 방법에 익숙하지만, 점점 더 많은 사람들이 LLM을 사용하여 이메일과 같은 통신으로 지칠 줄 모르고 문제를 싸우고 심지어 물리적 서류를 제안하는 것도 제안하는 문제가 커지고 있습니다.

    이제 기관에 대해 무언가를 주장하는 노력이 거의 0에 가까워짐에 따라, 더 많은 사람들이 자신의 LLM과 하네스를 사용하여 그들을 위해 몇 가지 전투를 싸우게 하는 아이디어를 얻고 있습니다. 그들에게는 비용이 거의 들지 않는 것처럼 느껴지지만, 개인적 이득의 확률이 0이 아니라면 그렇게 합니다. 지방 정부에서 대학 행정 사무실에 이르기까지, 부여될 가능성이 없더라도 무엇이든 요청하는 것이 시도해 볼 가치가 있다고 생각하는 끈질긴 발신자들로부터 계속 오는 요청에 압도당하고 있다는 이야기를 많이 듣고 있습니다.

    우리는 이전에 대부분의 사람들이 받을 자격이 없는 것을 주장하기 위해 노력하지 않을 것이라는 사실에 의존했던 많은 커뮤니케이션 및 요청 시스템을 재고해야 할 것 같습니다. 주장하는 비용이 0에 가까워지면, 기계는 그들을 위해 성공할 확률이 0이 아닌 것을 계속 시도할 수 있습니다.

  3. rwmj

    지금 인센티브가 정말 좋지 않습니다. 전통적으로 curl과 같은 중요한 프로젝트에 대한 CVE에 이름을 올리는 것은 커뮤니티에서 일정한 명성을 가져다주었습니다. 그것을 활용하여 승진이나 더 나은 직업을 얻을 수도 있으므로 돈도 분명히 관련이 있었습니다.

    이제 많은 사람들이 LLM에 코드를 던지고 나온 것을 "보안" 보고서에 복사하여 붙여넣고 있습니다.

    우리는 우리 프로젝트의 경우 LLM이 생성한 보안 보고서는 공개 목록에 복사하기로 결정했습니다. 모든 사람이 LLM에 접근할 수 있으므로, 하나의 LLM 인스턴스가 그것을 발견했다면 모든 LLM 사용자가 이미 또는 곧 발견할 것이라고 가정합니다. 중요하면 고치겠지만, 신호 대 잡음비가 꽤 나쁩니다.

    결국 이것은 낮은 난이도의 문제가 발견되고 수정되면서 더 안전한 서비스로 이어질 것이라고 생각합니다. 그러나 불행히도 LLM이 생성한 말도 안 되는 것의 홍수가 곧 끝나지는 않을 것 같습니다.

  4. woodruffw

    이런 지옥 같은 경험은 CVE 시스템이 양쪽 모두를 가지려고 하는 좋은 예입니다. 공격할 때는 수비수에게 풍부한 정보 소스이고, 방어할 때는 기본 보고서의 품질이나 정확성에 대해 아무것도 암시하지 않는 불투명한 ID일 뿐입니다.

  5. cynicalsecurity

    누군가는 정말로 이것을 이력서에 넣고 싶었나 봅니다.

이 날의 다른 글

2026-08-31