🛡️ GHSA, 데이터베이스가 아닌 "대화"였다 — 2026년, 보안 전문가가 새로 배워야 할 메인테이너 소통의 기술
by gasbugs2026. 5. 12.
"취약점을 찾는 것은 30분, 그것을 책임 있게 전달하는 것은 30일이 걸린다." — 어느 익명 메인테이너의 말 중에서
🎯 이 글에서 다루는 것
2026년 현재 GHSA(GitHub Security Advisory)의 실제 운영 현황과 통계
왜 지금이 GHSA 역사상 가장 어려운 시기인가 — "AI 슬롭"의 시대
보안 전문가가 GHSA 제보 시 반드시 지켜야 할 7가지 태도
메인테이너와의 소통이 곧 보안의 품질을 결정하는 이유
📌 도입 — GHSA를 처음 제출하던 그날의 깨달음
처음 GHSA(GitHub Security Advisory)를 제보했을 때, 솔직히 "취약점만 잘 정리하면 끝"이라고 생각했습니다. CVE 번호 받고, CVSS 점수 매기고, 패치 PR 던지면 메인테이너가 알아서 처리해 줄 거라고 말이지요.
그런데 실제로는 그렇지 않았습니다. 메인테이너의 응답이 늦어지면 답답함이 밀려오고, 제보한 내용이 잘못 해석되면 다시 설명해야 했고, 패치가 머지될 때까지 매일같이 GHSA 코멘트 창을 새로 고치고 있었습니다.
문득 깨달았습니다. GHSA는 데이터베이스가 아니라, 사람과 사람의 협업 공간이라는 사실을요. 그리고 지금 이 시점, 메인테이너들이 처한 현실을 알게 되면 우리 보안 전문가의 태도도 완전히 달라져야 한다는 것을 말입니다.
🔍 GHSA의 현재 — 숫자로 보는 2026년의 풍경
먼저 GHSA가 어떤 규모로 돌아가고 있는지부터 정리해 보겠습니다.
폭증하는 권고문, 한계에 부딪힌 리뷰 파이프라인
2026년 초 발표된 학술 분석에 따르면, GHSA에는 2019년부터 2025년까지 약 28만 8천여 건의 권고문이 등록되었고, 그중 GitHub의 공식 리뷰를 받은 건은 약 2만 3천여 건에 불과합니다. 즉, 공식 리뷰가 붙은 advisory는 전체의 약 8% 수준이라는 뜻입니다.
리뷰 경로도 두 갈래로 나뉩니다.
Fast Path (빠른 경로): 메인테이너가 GitHub Repository Advisory(GRA)를 통해 직접 제기한 권고문. 대부분 첫 리뷰가 빠르고, 리뷰어도 해당 저장소의 메인테이너인 경우가 많습니다.
Slow Path (느린 경로): NVD에서 먼저 등록된 후 GHSA로 흘러 들어오는 권고문. 리뷰 지연이 길고, 경험 많은 외부 리뷰어가 처리하는 경향이 있습니다.
이 데이터가 우리에게 말해주는 바는 명확합니다. 메인테이너가 직접 GHSA를 운영하도록 돕는 것이 가장 빠른 길입니다.
생태계의 탈중앙화 — ENISA의 등장
또 하나의 큰 변화가 있습니다. 2025년 11월 ENISA가 CVE Program Root로 승격되어 EU 내 신규 CNA를 직접 인가할 권한을 갖게 되었고, NIS2 지침 하에 EUVD(EU Vulnerability Database)도 출범했습니다. EU 정부 CNA는 46% 증가한 반면, 미국 CNA는 10% 감소했습니다.
게다가 EU Cyber Resilience Act가 2026년 9월 11일부터 시행되어, 디지털 요소가 포함된 제품을 EU에 판매하는 모든 제조사는 적극적으로 악용되는 취약점을 24시간 이내에 ENISA에 보고해야 합니다.
GHSA는 더 이상 GitHub 단독 무대가 아닙니다. 다층적이고 국제적인 취약점 생태계의 한 축으로 자리 잡았고, 그만큼 보안 전문가의 책임도 무거워졌습니다.
⚠️ GHSA 역사상 가장 어려운 시기 — "AI 슬롭" 위기
여기서부터가 본론입니다. 왜 지금 메인테이너와의 소통이 그 어느 때보다 중요한가?
curl 사건이 보여준 임계점
2026년 1월, 오픈소스 세계에 큰 사건이 있었습니다.
curl의 창립자이자 리드 개발자인 Daniel Stenberg는 HackerOne을 통해 운영해 온 버그 바운티 프로그램을 종료한다고 발표했습니다. 2019년부터 운영해 온 프로그램이지만, 저품질·무효 보고서가 폭증했고 상당수가 AI 생성 "슬롭"으로 보였기 때문입니다.
2025년 이전에는 진짜 취약점 비율이 15%를 넘었던 것이, 2025년부터 5% 미만으로 추락했습니다. 메인테이너 경제학의 붕괴입니다.
메인테이너의 심리적 한계
더 충격적인 통계가 있습니다. 메인테이너의 60%가 그만뒀거나 그만둘 것을 고려한 적이 있으며, 44%가 그 이유로 번아웃을 꼽았습니다.
Node.js는 주요 휴일 기간에 30건 이상의 AI 슬롭 보고를 받았다는 점을 HackerOne Signal 요구 강화의 핵심 근거로 들었습니다. 그리고 Apache httpd 메인테이너는 최근 글에서 "두 명의 보안 연구자가 같은 취약점을 독립적으로 발견했다 — 이는 더 이상 악의적 행위자를 어둠 속에 둘 수 없다는 뜻이며, 조정된 공개(coordinated disclosure)는 더 이상 작동하지 않는다"고 토로했습니다.
이 풍경을 한 줄로 정리하면 이렇습니다. "메인테이너는 이제 보안 보고서를 의심부터 한다."
그렇기에 우리가 보내는 한 통의 GHSA가 어떤 첫인상을 주느냐가, 그 보고서의 운명을 결정짓는 시대가 된 것입니다.
✅ 보안 전문가가 갖춰야 할 7가지 GHSA 태도
자, 그렇다면 우리는 어떻게 해야 하는가? 메인테이너에게 환영받는 보안 전문가가 되는 7가지 원칙을 정리합니다.
1. SECURITY.md를 가장 먼저 읽는다
GitHub Security Lab의 연구에 따르면, 프로젝트의 보안 정책(SECURITY.md)이 있다면 그 안의 "engagement 규칙"을 따르는 것만으로도 이슈가 신속하고 비공개적으로 처리될 확률이 크게 높아집니다. 보안 정책은 보통 루트, docs, 또는 .github 폴더에 있습니다.
이걸 무시하고 무작정 issue를 열거나 트위터에 PoC를 던지는 순간, 신뢰는 0이 됩니다.
2. 처음부터 Private Advisory(GRA)를 사용한다
공개 issue나 PR은 프로젝트를 N-day 취약점 악용의 표적으로 만듭니다. 패치가 머지되었지만 advisory가 공개되지 않은 그 짧은 창을 노리는 공격자들이 있기 때문입니다.
GHSA의 가장 강력한 기능은 draft advisory + temporary private fork입니다. 메인테이너와 함께 비공개 환경에서 패치를 만들어 나갈 수 있게 해 줍니다. 보안 전문가라면 이 워크플로우를 능숙하게 안내할 수 있어야 합니다.
3. "AI 슬롭"이 되지 않도록 검증한다
cURL을 다시 살린 사례에서 배울 점이 있습니다. 연구자 Joshua Rogers는 ZeroPath 같은 AI 도구를 사용해 cURL 코드베이스를 분석했지만, 모든 결과를 자신의 전문성으로 필터링한 후에만 제출했습니다. 그 결과 수년간의 fuzzing과 정적 분석에서 살아남은 100개 이상의 버그 수정에 기여했습니다.
AI를 쓰지 말라는 게 아닙니다. AI가 만든 의심을 사람의 검증으로 끝내라는 뜻입니다.
4. 재현 가능한 최소 PoC를 첨부한다
좋은 보고는 다음 4가지를 포함합니다.
영향받는 정확한 버전 범위
5줄 이내의 최소 재현 코드 또는 명령
예상되는 영향(impact)과 위협 모델
환경 정보(OS, 런타임, 의존성 버전)
장황한 설명보다 메인테이너가 5분 안에 자기 환경에서 재현할 수 있는 PoC가 100배 가치 있습니다.
5. 패치 제안 또는 mitigation을 함께 낸다
메인테이너들은 기여자처럼 행동하는 보고자를 매우 환영합니다. 보안 연구 배경에서 나오는 통찰이 더 강력한 remediation으로 이어지는 경우가 많기 때문입니다.
가능하면 patch 후보를 private fork에 PR로 올려 주세요. 메인테이너의 시간을 절반 이상 아껴 주는 길입니다.
6. Embargo와 공개 시점을 메인테이너에게 맡긴다
조정된 공개(coordinated disclosure)는 보고자와 벤더가 협력하여 공개 전에 취약점을 비공개로 해결하는 관행입니다. 수정 또는 완화 방안이 마련된 이후에만 공개합니다.
90일 룰 같은 일반적 가이드라인이 있지만, 메인테이너의 리소스 상황을 존중하는 게 우선입니다. 자발적 무급 메인테이너에게 90일은 짧을 수 있습니다.
7. 끝까지 함께한다
GHSA가 published 되어 CVE가 발급되고 끝이 아닙니다. 후속 질문, downstream 배포(데비안, 우분투, 알파인 등)의 백포트, 잘못된 영향 범위 정정 — 보안 전문가의 책임은 advisory 공개 이후에도 계속됩니다. 좋은 메인테이너 관계는 다음 번 제보의 신뢰 자산이 됩니다.
💻 실전 — 좋은 GHSA 보고 템플릿
다음은 메인테이너가 30초 안에 사안의 본질을 파악할 수 있도록 정리한 템플릿 예시입니다.
## Summary
[한 문장으로 취약점의 종류와 영향]
예: Path traversal in `extractFile()` allows arbitrary file write outside target directory.
## Affected Versions
- 영향: < 1.4.3
- 확인된 fix: 1.4.4 (제안 패치 첨부)
## CVSS 4.0 (제안)
Vector: AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N
Score: 9.3 (Critical) — 메인테이너 검토 부탁드립니다.
## Reproduction
1. `npm install <pkg>@1.4.2`
2. 다음 코드 실행:
```js
const x = require('<pkg>');
x.extractFile('../../../etc/passwd', '/tmp/out');
```
3. /etc/passwd 가 /tmp/out 으로 복사됨
## Suggested Fix
- private fork PR #1 에 patch 첨부
- 핵심: path normalization 후 target dir 내부 검증 추가
## Threat Model
- 공격자: 신뢰할 수 없는 archive 입력을 처리하는 환경
- 전제: 외부 입력이 extractFile()에 전달되어야 함
## Disclosure
- 메인테이너 일정에 맞춰 진행 가능
- AI 도구(ZeroPath) 사용 후 수동 검증 완료
이 정도 정성이 들어간 보고는 메인테이너에게 "이 사람과는 일하고 싶다"는 신호가 됩니다.
⚠️ 흔히 빠지는 함정
CVSS 점수를 일방적으로 통보하지 마세요. 메인테이너가 실제 threat model을 더 잘 압니다. 협의 대상으로 두세요.
"critical"이라는 단어를 남발하지 마세요. AI 슬롭 보고서의 공통 특징입니다.
공개 issue에 PoC를 절대 올리지 마세요. 단 한 번의 실수로 N-day가 됩니다.
메인테이너의 침묵을 무시로 해석하지 마세요. 그들은 본업이 있고, GHSA는 보통 무급 봉사입니다.
Credit에 집착하지 마세요. 진짜 보안 전문가는 결과로 평가받지, 이름으로 평가받지 않습니다.
✅ 정리 — GHSA는 데이터베이스가 아니라 신뢰의 인프라
2026년의 GHSA는 단순한 CVE 저장소가 아닙니다. 1.4백만 명의 오픈소스 메인테이너와 수만 명의 보안 연구자가 만나는 거대한 신뢰 네트워크입니다.
AI 시대에 진입하면서 이 네트워크는 가장 큰 시험대에 올랐습니다. 슬롭 보고로 메인테이너를 지치게 할 것인가, 아니면 정성스러운 협업으로 신뢰를 누적할 것인가 — 이 선택이 결국 우리 모두의 오픈소스 생태계 보안을 좌우합니다.
보안 전문가의 진짜 실력은 "몇 개의 CVE를 받았는가"가 아니라, "몇 명의 메인테이너가 다시 일하고 싶어 하는 사람인가"로 측정되는 시대가 왔습니다.
다음 번 GHSA를 작성하실 때, 화면 너머에 잠 못 이루는 메인테이너 한 사람이 앉아 있다는 사실을 떠올려 보시기 바랍니다. 그 사람이 우리의 동료입니다.
