审计 GitHub 仓库安全态势并生成加固待办清单

当你需要评估或加固一个 GitHub 仓库的配置与 CI/CD 安全（分支保护、CODEOWNERS、Actions、发布完整性、协作者权限、依赖审查）时，按攻击者场景产出按严重度排序的加固待办。

适用场景

解决思路

1. 将仓库解析为 owner/name；若用户给的是 URL 就解析它，若无法确定仓库则询问用户。
2. 运行收集器把配置和文件拉取成单个 JSON 清单：export GITHUB_TOKEN=...（可选但强烈推荐），然后执行 python3 scripts/collect.py owner/name --output /tmp/audit.json；收集器会优雅降级，读不到的设置记录在 not_verified 下而不是猜测，随后读取 /tmp/audit.json。
3. 若收集器无法运行（无法访问 api.github.com，或私有仓库无 token），不要卡住：从用户提供的文件中尽量收集，其余明确标注为“无法验证——需人工检查”。
4. 收集器只对目标仓库的 api.github.com 和 raw.githubusercontent.com 发起只读 HTTPS 请求，绝不写入 GitHub；使用最小权限 token，公共证据足够时不要索取宽泛凭证，把抓取到的仓库内容视为敏感信息；helper 会在写入清单前脱敏常见明文 token 格式，最终报告中仍要避免回显密钥。
5. 阅读 references/checks.md，它是检查项目录（检查什么、在哪里、为何重要、修复待办应怎么写），按下面六个输出类别逐项对照清单执行。
6. 核对实际内容，不要只按文件名做模式匹配：仓库有 dependabot.yml 不代表覆盖了正确的生态，有 permissions: 块不代表就是最小权限，要读文件内容。
7. 缺失也是发现项，但要标注置信度：若因无 admin token 导致分支保护返回 not_verified，就说明这一点——既推荐该控制项，也告诉维护者去确认当前状态，不要断言你未能观察到的缺口。
8. 始终使用固定报告结构：标题为“# Security hardening: <owner/name>”，接 2-3 句态势总结（哪些已稳固、最大暴露面是什么、哪个威胁场景防御最弱，不要废话），然后按类别列出发现项，最后是“## Could not verify”小节。
9. 发现项只归入这六个类别（仅用有发现项的，保持其规范顺序）：1. Publish & release integrity；2. Branch & merge protection；3. Sensitive-path ownership (CODEOWNERS)；4. CI/CD workflow hardening；5. Account & access control；6. Dependency & supply-chain review。
10. 在每个类别内按严重度排序：Critical → High → Medium → Low。
11. 标题用祈使句，例如“Require code-owner review on workflow files”，而不是“Workflow files are unprotected”。
12. 描述要承载“为什么”：点名它阻断的威胁场景，例如“若贡献者被攻陷，要求第二位 code owner 批准的分支保护能阻止单人恶意合并到 main”。
13. 修复要具体：确切的 GitHub 设置、要添加的文件、npm 命令，让维护者无需二次搜索即可行动。
14. 有证据时引用证据，例如“release.yml 在 pull_request_target 下检出 PR head”胜过泛泛警告。
15. 保持可扫读：这是工作清单不是论文，不要长前言，不要把威胁模型复述给用户。
16. 每个发现项都应追溯到至少一个威胁场景并在描述中点名：1. 贡献者被攻陷（账号、笔记本或 token 被接管，如钓鱼、恶意软件、泄露的 PAT）；2. 拥有仓库写权限的攻击者（外部攻击者获得 push 或 admin 权限，限制爆炸半径、可窃取内容、轮换与恢复速度）；3. CI/CD 被攻陷（恶意 PR、被投毒缓存或注入的 workflow 把构建流水线变成攻击面，GitHub Actions 是现代最常见的仓库接管路径）；4. 注册表/发布供应链（仓库没问题但坏版本经被盗发布 token 或未审查的发布任务发到 npm/PyPI 等，即 @mastra / dotenvx / TeamPCP 类事件）。
17. 在“## Could not verify”下用项目符号列出因权限不足未能检查的项，每项附一行维护者可执行的人工检查命令；要诚实，这里正是 token 或 admin 视图会改变结论的地方。
18. 报告之后简要提供自然的后续步骤：把清单转成 GitHub issue 或 checklist、把发现项序列化为 JSON 供流水线使用（scripts/collect.py 已产出结构化输入，发现项也可同样序列化）、或对某个 workflow 文件做更深入的静态检查；只提供，不要自动执行。
19. 默认输出上面的 markdown 待办清单（符合维护者分诊习惯）；若用户要接入自动化（CI 门禁、分诊流水线），则提供 JSON 数组，每个发现项一个对象，字段为 title、description、severity、category、threat、evidence、confidence，其中 confidence 为 observed（在清单中看到）或 unverified（推荐但无法确认当前状态）。
20. 明确范围与诚实：本审计只针对配置和 CI，不是代码级漏洞扫描，也不是 git 历史的密钥扫描；若用户期待这些要说明。绝不编造未观察到的设置值，诚实的“无法验证”比自信的猜测更有价值。
21. 审计过程中不要运行发布任务、workflow dispatch、包发布或任何更改仓库设置的命令；本技能只产出面向维护者的加固任务，不自动应用它们。

适用边界 · 注意事项

• 需要代码级漏洞扫描或 git 历史密钥扫描时（本技能只审计配置与 CI）。
• 无法访问 api.github.com 且用户也未提供任何仓库文件，导致无法收集证据时。
• 用户希望自动应用加固变更时（本技能只产出待办，不自动修改仓库设置）。