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

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

---

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

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

2026년에 무너진 전제

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

유지보수자의 우선순위 변화

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

[GN⁺]

Lobste.rs 의견들

• 성급한 취약점 공개는 여전히 방어자보다 공격자에게 훨씬 더 도움이 된다고 봄. 직접 겪고 본 바로는 최전선 모델을 써도 오탐률이 90%에 가까울 때가 있음
  덧붙이면, “오픈소스 암호 프로토콜의 지속 가능한 유지보수와 개발이 블록체인 기술의 폭넓은 채택에 중요하다”는 문구가 보이는데, 아직도 블록체인 기술을 믿는 사람이 있다는 게 놀라움

  • 그 문구가 왜 들어갔는지 헷갈렸는데, 알고 보니 Fillippo의 후원사 중 하나가 보낸 메시지였음
    지금 시점에서 블록체인 기술이 세상에 기여한 가장 가치 있는 건, 정말 안전한 암호 프로토콜 구현을 만들도록 강한 금전적 유인을 제공한 것일 수 있음. 그중 일부는 다른 모두에게도 유용해질 가능성이 있음
  • 여기서 오탐이 무슨 뜻인지 궁금함. 모델이 취약점을 찾았다고 주장했는데 확인해 보면 문제가 아니었다는 뜻인가?
    지금쯤이면 취약점 찾기와 코드 이해 전반이 LLM이 잘하는 일로 꽤 확립됐다고 생각했는데, 실제로 그런지 궁금함. 직접 겪은 내용을 좀 더 설명해 주거나 참고할 만한 자료를 알려주면 좋겠음. LLM을 쓰지 않아서 요즘 어느 정도인지 감을 잡기 어려워, 가정을 바꿔야 할지 진심으로 궁금함

• 특별한 취약점 보고는 특별하게 취급해야 하고, 방어자 쪽에서 더 나은 검증 방식과 공개된 위협 모델을 마련해야 함. 그래야 훌륭한 보고로 인정받기 위한 더 높은 기준을 사람들이 충족하고 검증할 수 있음

  • 결국 그렇게 정리될 수도 있음. 취약점 보고가 일반적으로 특별한 건 아니지만, 심각도가 높거나 신뢰도가 높은 일부 보고는 특별한 취약점 보고로 봐야 함

• 보안 이슈를 찾기가 쉬워졌고 진입 장벽이 낮아져서 보안 메일링 리스트에 예전보다 잡음이 많아졌을 거라는 데 동의함. 그래도 Trail of Bits나 Zellic 같은 평판 있는 보안 컨설팅 회사의 버그 보고는 여전히 확실히 우선순위에 둘 것임
  그들이 허술한 보고를 내지 않을 거라고 믿어서만이 아니라, LLM을 CI에서 그냥 돌리는 것보다 상위 보안 연구자와 LLM의 조합이 더 낫다고 보기 때문임

  • 최근에 그런 벤더들과 일해 봤는데, 허술한 보고는 여전히 들어옴. 보고서 품질이 더 높을 뿐임
    LLM은 누가 조종하든 위협 모델을 오해할 수 있고, “익스플로잇”을 입증하는 방식에서 게으르게 굴 수 있음. 보안 연구자가 이런 실수를 놓치면 결국 유지보수자인 우리에게 전달됨. containerd는 이런 벤더들, LLM 연구 회사들, 이미 알려진 기반 모델 회사들, 그리고 인터넷의 J Random User에게서도 허술한 보고를 받았음
    Filippo가 여기서 충분히 말하지 않은 또 다른 어려움은 중복 보고임. containerd의 최근 advisories를 보면, triage와 주의 배분에서 또 다른 큰 문제가 중복이라는 걸 볼 수 있음. 예를 들어 9 separate researchers/groups에 크레딧을 줬고, 그 안에는 앞서 말한 것 같은 평판 있는 그룹도 포함됨. 이건 (a) LLM이 누가 쓰든 같은 이슈를 많이 찾아낸다는 것, (b) 알려진 보고자의 보고라고 해서 반드시 특별한 건 아니라는 것을 보여줌. 반대로 this one은 실제로 중복 보고가 없어서 한 명에게만 크레딧을 줬고, 그 보고자는 우리가 사전에 알거나 관계가 있던 사람도 아니었음