curl, LOW·MEDIUM 취약점 제보는 GitHub 공개 처리…HIGH·CRITICAL은 비공개

curl 프로젝트는 2026년 10월 26일부터 자체 심각도 판정에서 LOW·MEDIUM인 취약점 제보를 GitHub 공개 이슈로 처리합니다. HIGH·CRITICAL 제보는 수정이 포함된 릴리스를 낼 때까지 HackerOne에서 비공개로 다룹니다. 공개 경로에서는 커뮤니티가 제보와 수정안을 검토할 수 있지만, 패치 전 취약점 정보가 공격자에게도 공개됩니다.

Open Source Security에 10월 27일 글을 쓴 Josh Bressers는 curl의 변경을 계기로 취약점 제보 처리 방식을 바꿀 필요가 있다고 주장했습니다. 그는 모든 제보에 엠바고를 적용하는 관행 대신, 낮은 심각도의 제보에 공개 협업을 적용하는 정책을 다른 오픈소스 프로젝트에도 권장하자고 제안했습니다. 공개 처리의 효과에 관한 뒤이은 논의는 자신의 경험에 바탕을 둔 전망이라고 밝혔습니다.

엠바고는 취약점을 발견한 사람이 프로젝트에 비공개로 알리고 수정할 시간을 주는 절차입니다. 수정 전 세부 정보가 공개되면 공격자가 이를 악용할 수 있어 공개 시점을 늦춥니다. curl의 새 정책은 이 경로를 심각도별로 나눕니다.

심각도에 따라 제보와 수정 경로를 나눕니다

제보자가 심각도를 판단하기 어렵다면 HackerOne에 접수할 수 있습니다. curl 보안팀이 LOW·MEDIUM으로 판정하면 제보자에게 GitHub 이슈나 풀 리퀘스트로 다시 제출하도록 요청합니다. HackerOne 접수 건은 정보 제공용으로 종결하고, 공개 이관은 대화를 공개 공간에서 이어가자는 요청입니다. GitHub 이슈에는 취약점 제보뿐 아니라 일반 버그도 올라올 수 있습니다.

LOW·MEDIUM 제보의 수정은 공개 저장소에서 일반 풀 리퀘스트로 진행합니다. HIGH·CRITICAL은 제보자와 curl 보안팀만 접근할 수 있는 비공개 브랜치에서 수정하고, 패치가 포함된 릴리스가 나올 때까지 HackerOne에서 비공개로 처리합니다.

공개 저장소에서 다루면 커뮤니티가 제보의 주장과 영향을 살피고, 수정안과 보안 권고문을 검토하며, 문제가 도입된 시점을 찾는 데 참여할 수 있습니다. curl 정책을 발표한 Daniel Stenberg는 외부 검토자가 수정이 문제를 제대로 해결했는지, 주변의 유사한 문제를 놓치지 않았는지 릴리스 전에 살필 수 있기를 기대한다고 밝혔습니다.

Stenberg는 10월 20일 정책 발표에서 최근 몇 년간 접수된 전체 제보 가운데 90%가 넘는 건을 HIGH 미만으로 빠르게 판정할 수 있었다고 설명했습니다. 그는 계속 늘어나는 제보로 핵심 유지보수자들이 과부하를 겪고 있다고 밝혔습니다. 공개 처리로 제보 한 건에 필요한 작업량 자체가 줄지는 않지만, 더 많은 사람이 참여해 부담을 나누고 수정 내용을 일찍 살필 수 있다는 게 curl의 기대입니다.

공개 처리에서는 패치 전 정보가 공격자에게도 공개돼 악용 기회가 늘고 curl 이용자의 위험 노출 시간이 길어질 수 있습니다. Stenberg는 이 위험을 인정하면서 적용 대상을 HIGH 미만으로 한정했습니다.

Bressers는 비공개 엠바고가 여러 건 겹치면 제보마다 누가 어떤 정보를 알고 있는지 관리해야 하고, 비밀 유지를 위해 공개 저장소의 CI 시험이나 외부 리뷰·커뮤니티 시험을 활용하기 어렵다고 설명했습니다. 그는 이런 관리 부담을 나누는 방안으로 공개 처리를 제안하며, 다른 오픈소스 프로젝트에도 유사한 정책을 권장하자고 주장했습니다.