“发现一个漏洞需要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年初发布的学术分析，从2019年到2025年，GHSA中注册了约28.8万条建议，其中只有约2.3万条获得了GitHub的官方审查。这意味着，获得官方审查的建议仅占总数的约8%。
审查路径也分为两条：
- Fast Path（快速路径）： 维护者通过GitHub Repository Advisory (GRA) 直接提出的建议。大多数首次审查速度快，审查者也多为该仓库的维护者。
- Slow Path（慢速路径）： 先在NVD注册后流入GHSA的建议。审查延迟较长，倾向于由经验丰富的外部审查者处理。
这些数据向我们传达的信息很明确：帮助维护者直接运营GHSA是最高效的途径。
生态系统的去中心化 — ENISA的出现
还有另一个重大变化。2025年11月，ENISA被提升为CVE Program Root，获得了直接授权欧盟境内新CNA的权力，并且在NIS2指令下，EUVD（欧盟漏洞数据库）也已启动。欧盟政府CNA增加了46%，而美国CNA减少了10%。
此外，欧盟网络弹性法将于2026年9月11日生效，要求所有在欧盟销售包含数字元素产品的制造商，必须在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.md），仅仅遵循其中的“参与规则”就能大大提高问题被迅速且私密处理的可能性。安全策略通常位于根目录、docs或.github文件夹中。
如果忽视这一点，贸然开启issue或在Twitter上发布PoC，信任度将瞬间归零。
2. 从一开始就使用Private Advisory (GRA)
公开的issue或PR会使项目成为N-day漏洞利用的目标。因为攻击者会盯上补丁合并但建议尚未公开的短暂窗口期。
GHSA最强大的功能是草稿建议 + 临时私有分支。这使得您可以与维护者在私密环境中共同创建补丁。作为安全专家，您应该能够熟练地引导这一工作流程。
3. 验证以避免“AI糟粕”
从挽救cURL的案例中可以学到一点。研究员Joshua Rogers使用ZeroPath等AI工具分析了cURL代码库，但只在用自己的专业知识过滤所有结果后才提交。这促成了100多个在多年模糊测试和静态分析中幸存下来的bug修复。
这并不是说不要使用AI。它的意思是用人工验证来终结AI产生的疑虑。
4. 附上可重现的最小PoC
一份好的报告包含以下四点：
- 受影响的准确版本范围
- 5行以内的最小重现代码或命令
- 预期的影响（impact）和威胁模型
- 环境信息（操作系统、运行时、依赖版本）
一个维护者能在5分钟内在其环境中重现的PoC，比冗长的解释价值高100倍。
5. 同时提出补丁建议或缓解措施
维护者非常欢迎像贡献者一样行事的报告者。来自安全研究背景的洞察力往往能带来更强大的修复方案。
如果可能，请将补丁候选方案作为PR上传到私有分支。这是为维护者节省一半以上时间的最佳途径。
6. 将禁运期和公开时间交给维护者
协调披露（coordinated disclosure）是报告者和供应商合作，在公开之前私下解决漏洞的做法。只有在修复或缓解方案到位后才公开。
虽然有90天规则等一般性指导方针，但尊重维护者的资源状况是首要的。对于自愿无偿的维护者来说，90天可能很短。
7. 坚持到底
GHSA发布并获得CVE编号并非终点。后续问题、下游分发（Debian、Ubuntu、Alpine等）的向后移植、纠正错误的影响范围——安全专家的责任在建议公开后仍将继续。良好的维护者关系将成为下次报告的信任资产。
实战 — 优秀的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(‘
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分数。 维护者更了解实际的威胁模型。将其作为讨论对象。
- 不要滥用“critical”一词。 这是AI糟粕报告的共同特征。
- 绝不要将PoC上传到公开issue。 一次失误就可能导致N-day。
- 不要将维护者的沉默解读为忽视。 他们有本职工作，GHSA通常是无偿志愿服务。
- 不要执着于署名。 真正的安全专家是靠结果来评价的，而不是靠名字。
✅ 总结 — GHSA不是数据库，而是信任的基础设施
2026年的GHSA不仅仅是一个CVE存储库。它是一个巨大的信任网络，连接着140万开源维护者和数万名安全研究人员。
随着AI时代的到来，这个网络正面临最大的考验。我们是要用糟粕报告耗尽维护者，还是通过精心协作积累信任？这个选择最终将决定我们整个开源生态系统的安全。
衡量安全专家真正实力的时代已经到来，不再是看“获得了多少个CVE”，而是看“有多少维护者愿意再次与他合作”。
下次撰写GHSA时，请记住屏幕另一端坐着一位夜不能寐的维护者。那个人是我们的同事。
发表回复