---
title: "취약점 제보가 더 이상 특별하지 않은 시대가 왔다"
published: 2026-06-23T23:42:46.000Z
canonical: https://jeff.news/article/4350
---
# 취약점 제보가 더 이상 특별하지 않은 시대가 왔다

전 Go 보안팀 리드였던 필리포 발소르다가 LLM 이후 취약점 제보의 의미가 바뀌었다고 주장한다. 예전에는 희소한 통찰과 비공개 제보가 귀했지만, 이제는 잠재 취약점을 찾는 것보다 실제 영향도를 빠르게 가려내는 triage가 병목이라는 얘기다.

- 필리포 발소르다가 꽤 도발적인 얘기를 꺼냄. “취약점 제보는 더 이상 특별하지 않다”는 주장임.
  - 그는 예전에 Go 보안팀을 이끌었던 사람이고, 지금도 Go 유지보수에 관여하는 오픈소스 보안 쪽 인물임.
  - 단, 글 자체는 Go 보안팀의 공식 입장이 아니라 개인 관찰이라고 선을 그음.

- 예전 오픈소스 유지보수 문화에서는 일반 이슈와 취약점 제보를 다르게 봤음.
  - 일반 이슈, 풀 리퀘스트, 피드백은 선물이지 의무가 아니라는 태도가 가능함.
  - 하지만 취약점 제보는 달랐음. 연구자가 공개 폭로 대신 비공개로 알려주는 것이고, 프로젝트는 빠른 응답과 조사, 진행 공유, 크레딧을 제공해야 한다는 암묵적 계약이 있었음.
  - 이유는 간단함. 제보자가 주는 ‘통찰’과 ‘비공개 시간’이 사용자 보호에 직접 도움이 됐기 때문임.

- 그런데 글쓴이는 2026년에는 그 전제가 무너졌다고 봄. 이유는 LLM임.
  - LLM은 이제 웬만한 보안 연구자만큼 잠재 취약점을 찾아낼 수 있고, 누구나 돌릴 수 있음.
  - 유지보수자도 돌릴 수 있고, 공격자도 돌릴 수 있음.
  - 그래서 희소한 건 “취약점 후보를 찾는 능력”이 아니라 “그중 뭐가 진짜 위험한지 판단하는 능력”이 됐다는 얘기.

> [!IMPORTANT]
> 병목이 발견에서 triage로 옮겨갔다는 게 이 글의 핵심임. 취약점 후보는 늘었는데, 실제 영향도와 우선순위를 판별할 사람의 시간은 그대로임.

- 이 변화는 비공개 제보와 엠바고의 가치도 흔든다고 봄.
  - 예전에는 공격자가 공개 글을 보기 전까지 취약점을 모를 가능성이 컸음.
  - 이제는 공격자도 자기 LLM에게 물어보면 비슷한 후보를 얻을 수 있음.
  - 심지어 공격자도 방어자와 똑같이 “이게 진짜 악용 가능한가?”를 판별하는 triage 병목을 겪을 거라고 봄.

- 그래서 앞으로 보안팀의 일은 취약점 제보함을 성실하게 관리하는 것에서 조금 달라질 수 있음.
  - triage를 빠르게 하고, 진짜 위험한 건 빨리 고치고, 애초에 취약점이 들어가지 않게 예방하는 쪽이 더 중요해짐.
  - 글쓴이는 모두가 CI에서 LLM 분석을 돌리는 방법을 찾아야 할 것 같다고 말함.
  - 이건 약간 농담처럼 쓰였지만, 방향성은 꽤 진지함.

```mermaid
sequenceDiagram
    participant 연구자 as 외부 연구자 또는 LLM
    participant 보안함 as 보안 제보함
    participant 유지보수자 as 유지보수자
    participant CI as LLM 기반 CI 분석
    participant 사용자 as 사용자
    연구자->>보안함: 취약점 후보 대량 제보
    CI->>유지보수자: 내부 코드 분석 결과 제공
    유지보수자->>유지보수자: 영향도와 신뢰도 triage
    유지보수자->>사용자: 중요한 취약점 빠른 수정 배포
    유지보수자->>보안함: 낮은 신호 제보는 축소 처리
```

- 물론 모든 제보가 평범해졌다는 뜻은 아님. 글쓴이도 ‘특별한 제보’는 여전히 있다고 인정함.
  - 극도로 심각한 취약점, 신뢰할 수 있는 연구자의 제보, 영향도가 명확한 보고서는 특별하게 다뤄야 함.
  - 다만 새 과제는 모든 제보를 특별 취급하는 게 아니라, 특별한 제보와 그렇지 않은 제보를 빨리 나누는 프로세스를 만드는 것임.

- 댓글 반응에서도 비슷한 뉘앙스가 나옴.
  - 어떤 사람은 모델 성능 향상이 계속되는 동안 이런 흐름이 유지될 거라고 봄.
  - 또 다른 보안 담당자는 매주 12건이 넘는 보고서를 triage하는데, 많은 보고서가 ‘진짜 결함’이긴 해도 일반 사용자에게 미치는 영향이 불명확하다고 말함.
  - 예전엔 연구자를 쉽게 차단하기 어려웠지만, 이제는 낮은 품질의 LLM성 제보를 보내는 사람을 차단해도 더 나은 제보가 또 올 수 있다는 말까지 나옴. 좀 살벌하지만 현실적임.

> [!WARNING]
> 오픈소스 프로젝트가 보안 제보 채널을 열어두기만 하면 안전해지는 시대는 끝나가고 있음. 제보를 받아낼 체계보다, 제보를 빠르게 판별하고 수정할 운영 능력이 더 중요해지고 있음.

---

## 기술 맥락

- 이 글에서 바뀐 선택지는 취약점 제보를 무조건 특별 취급하느냐, 아니면 일반 이슈처럼 triage 중심으로 다루느냐예요. LLM 때문에 후보 제보가 늘어나면 예전 방식으로는 유지보수자 시간이 먼저 터지거든요.

- coordinated disclosure가 약해진다는 주장도 여기서 나와요. 예전에는 비공개 시간이 공격자보다 앞설 수 있는 완충 장치였는데, 이제 공격자도 비슷한 모델로 같은 유형의 버그를 찾을 수 있어요.

- 그렇다고 제보를 무시하자는 얘기는 아니에요. 고위험 취약점이나 신뢰 관계가 있는 연구자의 보고서는 여전히 가치가 크기 때문에, 빠르게 특별 케이스로 승격하는 분류 체계가 필요해요.

- CI에서 LLM 분석을 돌리자는 말은 방어자도 같은 도구를 내부화하자는 뜻이에요. 외부에서 쏟아지는 보고서를 기다리기보다, 코드 변경 시점에 잠재 결함을 먼저 찾아내야 triage 부담을 줄일 수 있어요.

## 핵심 포인트

- LLM이 많은 보안 연구자 수준으로 잠재 취약점을 찾아낼 수 있게 되면서 ‘발견’의 희소성이 줄었다는 주장
- 공격자와 방어자 모두 비슷한 도구를 쓸 수 있어, 비공개 제보와 엠바고의 가치도 예전만큼 크지 않다고 봄
- 오픈소스 유지보수자는 모든 취약점 제보를 특별 대우하기보다 심각도와 신뢰도 기준으로 빠르게 분류해야 함
- 앞으로는 triage, 빠른 수정, 예방, CI 기반 LLM 분석이 더 중요한 업무가 될 수 있음
- 다만 고위험 취약점이나 신뢰할 수 있는 연구자의 제보는 여전히 별도 프로세스가 필요하다고 인정함

## 인사이트

보안 제보 문화가 ‘제보자에게 성실히 응답하는 예절’에서 ‘쏟아지는 후보 중 진짜 위험을 가르는 운영 문제’로 이동하고 있다는 글이다. 한국 오픈소스 프로젝트나 보안팀도 LLM발 제보 폭증을 곧 겪게 될 가능성이 높다.