curl의 낮음·중간 심각도 취약점은 공개 절차로 처리합니다

AI 요약

curl 프로젝트는 2026년 10월 26일부터 LOW 또는 MEDIUM으로 판단한 취약점 제보를 GitHub 저장소 이슈로 접수합니다. HIGH와 CRITICAL 제보만 HackerOne에서 비공개로 처리합니다. 제보자가 심각도를 판단하기 어렵다면 HackerOne에 먼저 제출해도 됩니다. 프로젝트가 심각도를 검토한 뒤 LOW나 MEDIUM으로 분류하면 GitHub에 다시 제출해 달라고 요청하고 HackerOne 제보는 공개 사실을 알린 뒤 informative 상태로 닫습니다. 최근 몇 년 동안 들어온 제보의 90% 이상은 빠르게 HIGH 미만으로 분류할 수 있었다고 설명합니다.

공개 접수로 바꾸는 이유

Daniel Stenberg는 취약점 제보가 계속 밀려들고 있으며 몇 달 안에 줄어들 것으로 보이지 않는다고 말합니다. 주요 유지보수자들이 과부하를 겪어 프로젝트가 버티기 어려운 상황이라며 이번 절차 변경을 생존 전략의 다음 단계로 제시합니다. 공개하면 취약점 판단과 이해, 보안 권고문 작성, 문제가 처음 들어온 시점 조사에 더 많은 사람이 참여할 수 있습니다. 수정이 문제를 제대로 해결했는지 확인하고 인접한 유사 문제를 놓치지 않는 데 도움을 기대합니다.

최근에는 새 CVE와 수정 사항을 공개한 직후 AI를 사용하는 연구자들이 모델과 도구로 수정의 유사한 실수나 누락을 찾는 흐름이 있다고 설명합니다. 프로젝트는 출시 전에 검토 과정을 공개하면 이런 검증을 더 잘 받을 수 있다고 봅니다. 공개 절차가 제보 한 건당 필요한 작업량을 줄이지는 않지만 여러 사람이 부담을 나눌 여지가 있고, 논의에서 나온 교훈과 문서도 더 쉽게 공유됩니다. 배포판과 curl 사용자도 보안 수정 정보를 더 일찍 확인할 수 있습니다.

공개에 따르는 위험과 심각도 판단

LOW·MEDIUM 제보를 공개하면 악의적인 사용자도 취약점 정보를 즉시 볼 수 있어 기존 curl 사용자에게 악용 기회가 조금 더 길게 열립니다. 프로젝트는 이를 인정하면서도 위험을 낮추기 위해 HIGH 미만만 공개하기로 했습니다. 연구자가 심각한 문제를 낮게 판단해 공개 접수할 위험도 제기됐지만, 제보자가 문제를 실제보다 낮게 보고하는 일은 거의 없다고 봅니다. 취약점을 공개 제보하는 위험은 정책 변경 전에도 존재했다고 덧붙입니다.

프로젝트는 LOW 취약점을 모두 무시하는 방안도 논의했지만, CVE 절차에는 이의 제기가 있고 실제 취약점에 CVE를 발급하지 않으면 다른 주체가 발급할 수 있어 진짜 문제를 외면할 수 없다고 설명합니다. 다만 사용자나 기존 애플리케이션에 피해를 주지 않는 제보는 더 적극적으로 거부하겠다는 입장입니다.

AI 모델이 현실에서 거의 쓰이지 않을 조합이나 옵션 순서를 만들어 예상 밖 동작을 찾아내고, 이를 취약점으로 보고하는 사례도 늘고 있다고 지적합니다. libcurl은 옵션과 프로토콜을 조합하는 경우의 수가 매우 많습니다. 프로젝트는 발생 가능성이 낮거나 애플리케이션이 즉시 알아차릴 문제까지 CVE 절차로 처리하면 유지보수자와 사용자 모두에게 불필요한 일이 늘어난다고 설명합니다. 심각도는 LOW, MEDIUM, HIGH, CRITICAL 네 단계로 나누며 최근 판단 사례와 기본 지침을 참고합니다. 지침은 더 명확하게 다듬을 수 있다고 덧붙입니다.

원문: Daniel Stenberg 블로그 / 번역·요약: Trawling