취약점 보고서는 더 이상 특별하지 않다

15 hours ago 2

오픈소스 유지보수에서 일반 이슈와 PR은 선택적으로 다룰 수 있지만, 과거의 취약점 보고서는 사용자 보호 때문에 별도 대응이 필요한 예외였음
그 예외성은 연구자가 공격자보다 먼저 수정할 기회를 주는 희소한 통찰과 비밀 유지를 제공했고, 프로젝트는 빠른 응답·조사·진행 공유·크레딧으로 보상하는 구조였음
2026년에는 LLM을 유지보수자와 공격자 모두 실행할 수 있어, 병목이 잠재 이슈 발견에서 실제 취약점 선별로 옮겨감
신뢰 관계가 없는 외부 연구자는 선별에 크게 기여하기 어렵고, LLM 출력 검토와 security@ 받은편지함 검토의 신호 대 잡음비가 비슷해짐
유지보수자의 시간은 보고 대응 자체보다 분류, 빠른 수정, 예방에 더 많이 쓰여야 하며, LLM 분석을 CI에서 실행하는 방법도 필요함

취약점 보고가 예외였던 이유

공개적으로 일하는 오픈소스 유지보수자는 이슈, PR, 피드백을 선물처럼 받아들이고, 필요에 따라 수용하거나 무시하거나 일부만 사용할 수 있음
과거의 취약점 보고서는 이 원칙에서 벗어난 특별한 사례였음
- 보안 연구자는 즉시 공개하는 대신 비공개 보고를 선택해 프로젝트가 먼저 수정할 시간을 줬음
- 프로젝트는 보고를 빠르게 확인하고 조사하며, 보고자에게 진행 상황을 공유하고 최종적으로 발견에 대한 크레딧을 주는 것이 일반적 기대였음
이런 기대는 보고자가 버그 수정이나 기능 구현을 요구하는 사람이 아니라, 프로젝트에 서비스를 제공하는 사람이라는 전제에서 나왔음
- 핵심 가치는 공격자가 익스플로잇을 내놓기 전에 수정본을 배포할 수 있게 하는 통찰과 기밀성이었음
- 취약점 보고를 무시하면 사용자 보안을 신경 쓰지 않는 신호로 받아들여졌음

2026년에는 취약점 보고를 특별하게 만들던 전제가 더 이상 유지되기 어려움
- LLM은 거의 모든 보안 연구자만큼 잘하며, 누구나 실행할 수 있음
- 같은 도구를 유지보수자도 실행할 수 있고 공격자도 실행할 수 있음
부족한 것은 잠재 이슈를 찾아내는 능력이 아니라, 그중 무엇이 실제 취약점인지 가려내는 분류 작업임
기존 신뢰 관계가 없는 외부 연구자는 이 분류 과정에 의미 있게 기여하기 어려움
- LLM 출력물을 검토하는 일과 security@ 받은편지함을 훑는 일의 신호 대 잡음비가 거의 같음
비밀 유지, 엠바고, 조율의 중요성도 예전보다 줄어듦
- 공격자는 전체 공개 글을 기다리지 않고 자신의 LLM에 취약점을 물어볼 수 있음
- 다만 공격자 역시 방어자와 같은 분류 병목을 겪을 가능성이 큼

취약점 보고서가 특별했던 시기는 끝났을 수 있음
지금 더 중요한 일은 분류, 빠른 수정, 예방임
LLM 분석을 CI에서 실행하는 방법을 찾아야 함
이 입장은 Go Security 팀의 공식 입장이 아니라, 전 Go Security 팀 리드였던 개인의 견해임
취약점 보고 처리와 Code of Conduct 집행이 충돌할 때는 정답이 없음
- 행동의 심각성, 사적인 문제인지 커뮤니티에 영향을 주는지, security@를 처리하는 팀의 자원에 따라 판단해야 함
공개 관행에는 복잡한 역사가 있음
- 과거에는 선의의 연구자가 법적 위협이나 기소를 당하는 일이 있었음
- 2026년 오픈소스 현실에서는 취약점 보고 때문에 기소를 두려워하는 연구자가 없고, 프로젝트도 문서화된 보고 정책의 대안으로 기소를 암시해서는 안 됨
curl의 한 달간 취약점 보고 채널 중단은 처음에는 지나치다고 느껴졌지만, 사용자 보호를 위해 취약점 보고 대응이 최선의 시간 사용인지 더 이상 분명하지 않음