curl 프로젝트는 취약점 공개 절차를 바꿔 2026년 10월 26일부터 LOW 또는 MEDIUM으로 판단한 취약점 제보를 GitHub 저장소 이슈로 받는다. HIGH 또는 CRITICAL 취약점만 HackerOne 추적 시스템에서 비공개로 처리한다.
등급을 판단하기 어려운 보안 연구자는 HackerOne에 제보할 수 있다. curl 프로젝트는 지난 몇 년간 접수된 제보의 90% 이상을 HIGH 미만으로 빠르게 평가할 수 있었다고 밝혔다. HackerOne에 접수된 제보를 LOW 또는 MEDIUM으로 판단하면 GitHub에 다시 제출하도록 요청하고, HackerOne에서는 정보 제공 목적으로 종결한 뒤 공개한다.
이번 변경은 취약점 제보가 계속 밀려드는 상황에 대응하기 위한 조치다. curl 프로젝트는 주요 유지보수자들이 과중한 업무로 한계에 몰렸으며, 제보량이 앞으로 몇 달 안에 줄어들 것으로 예상하지 않는다고 설명했다.
공개 절차에서는 누구나 제보와 취약점의 평가·이해에 참여하고, 보안 권고문 작성이나 문제가 처음 도입된 시점을 파악하는 데 도움을 줄 수 있다. curl 프로젝트는 공개 검토가 수정 사항이 문제를 제대로 해결하는지, 관련된 다른 문제를 놓치지 않았는지 확인하는 데 보탬이 되기를 기대한다. 또한 배포판과 curl 이용자가 보안 수정 사항을 더 일찍 파악할 수 있다고 밝혔다.
curl 프로젝트는 수정 사항을 발표할 때마다 AI를 사용하는 연구자들이 모델과 도구로 수정 누락이나 유사한 실수를 찾는 흐름이 있다고 설명했다. 절차를 처음부터 공개하면 새 버전을 내기 전에 이런 검토를 더 잘 받을 수 있다는 기대다. 다만 공개한다고 제보 한 건을 처리하는 데 필요한 일이 줄어드는 것은 아니며, 부담을 더 많은 사람과 나누고 논의에서 나온 교훈과 문서를 쉽게 확인할 수 있기를 바란다고 덧붙였다.
공개 처리에는 위험도 따른다. LOW나 MEDIUM으로 잘못 판단한 HIGH 취약점을 연구자가 GitHub에 올릴 수 있다는 우려가 제기됐지만, curl 프로젝트는 연구자가 제보의 심각성을 실제보다 낮게 평가하는 경우는 거의 없다고 봤다. 취약점을 공개하면 선의의 이용자뿐 아니라 악의적인 행위자도 바로 내용을 확인할 수 있어 curl 이용자를 겨냥한 악용 기회가 조금 더 길어질 수 있다. 프로젝트는 이를 피할 방법이 없다고 보고, 이런 위험 때문에 HIGH 미만 취약점에만 공개 절차를 적용한다고 밝혔다.
curl 프로젝트는 LOW 취약점을 모두 묵살하는 방안도 논의했지만, 실제 취약점에 CVE를 부여하지 않으면 다른 주체가 부여할 수 있어 진짜 취약점을 무시할 수는 없다고 설명했다. 다만 사용자나 기존 애플리케이션에 실제 피해를 주지 않는다고 판단한 제보는 더 엄격하게 거부하겠다는 방침이다.
프로젝트는 AI 모델이 실제 환경에서 쓰일 가능성이 낮은 옵션 조합이나 순서를 찾아내거나, 매번 같은 방식으로 드러나 애플리케이션이 즉시 알아차릴 문제를 취약점으로 제보하는 사례가 늘고 있다고 지적했다. 이런 문제가 현실에서 발생할 위험이 거의 없다면 CVE 절차를 밟아도 이용자 보호에는 도움이 되지 않고, 프로젝트와 이용자에게 대응 업무만 더할 수 있다는 설명이다. curl 프로젝트는 libcurl의 다양한 옵션과 프로토콜 조합, 유연한 API를 모두 시험하려는 제보 흐름을 지금처럼 감당할 인력과 여력이 없다고 밝혔다.
취약점 등급은 LOW, MEDIUM, HIGH, CRITICAL 네 단계로 나눈다. curl 프로젝트는 최근 처리한 취약점의 판단을 참고하며, 등급별 기본 지침도 공개하고 있다. 프로젝트는 이 지침을 더 명확하게 다듬을 수 있다고 덧붙였다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요