每日扫描GitHub Actions供应链风险

原文要点

vijay kireeti varma发布的模板，每天7点运行：先创建并加载n8n Data Table基线（记录已扫描工作流文件及SHA），用GitHub REST/Contents API列出组织仓库并枚举.github/workflows下的YAML文件；与基线比对SHA，只处理新增或变更文件；规则检测常见Actions攻击模式，对未固定的uses引用通过GitHub GraphQL解析commit SHA给出可粘贴的固定建议；高风险文件（数量受max_ai_reviews限制）送Google Gemini做结构化安全判定，判定malicious/suspicious或有critical规则发现即在Slack发即时告警；结果回写Data Table，Gemini生成当日摘要发Slack，严重发现可在私有仓库自动开issue。

这次做成什么

在n8n搭好这条「基线比对→规则检测→AI复核→Slack告警」的每日扫描，并用一个含未固定actions和可疑模式的虚构工作流文件，先手动验证检测与告警分支，再交给调度自动跑。

准备什么

• n8n实例（需支持Data Table功能）
• GitHub个人访问令牌：Contents/Metadata读权限；如启用自动开issue另需Issues写权限
• Google Gemini API密钥（aistudio.google.com申请）
• Slack凭据及目标频道（默认#security-alerts，可自建测试频道）
• 对目标组织或用户账号的仓库列表访问权

具体怎么做

1. 填Settings并建基线

   打开Settings节点，至少填github_owner（组织或用户名）和owner_type（org或user），可选repo_name_filter、max_repositories、max_ai_reviews先设小值（如5和2）控制首跑范围。手动执行一次，工作流会自动创建gha_security_inventory数据表并写入首批文件SHA基线，本轮不告警属正常。

2. 验证增量扫描逻辑

   向某个测试仓库提交一次工作流文件改动，再次手动执行。确认只有该文件进入下载与检测分支，其余文件因SHA不变被跳过并保留旧结果。这是控制API调用量和AI费用的核心机制。

3. 配置规则+GraphQL固定建议

   规则检测节点对下载的YAML做模式匹配（如curl管道bash、可疑环境变量外发等）；对uses: xxx@main这类未固定引用，GraphQL节点把分支/tag解析成具体commit SHA，输出形如uses: actions/checkout@<sha> # v4的可粘贴建议。用下方测试文件确认两类输出都出现。

4. 接Gemini复核与Slack

   两个Gemini节点分别粘贴「文件安全判定提示词」和「每日摘要提示词」。文件判定要求输出结构化verdict；当verdict为malicious/suspicious或规则含critical时，Slack节点立即发告警到测试频道。摘要节点汇总当日统计（扫描文件数、变更数、高中低危数）生成简报。

5. 回写与可选开issue

   扫描结果upsert回gha_security_inventory表。如要给严重发现自动开issue，确认令牌有Issues写权限并仅在私有仓库开启；测试期建议先关掉该节点。全部跑通后激活Schedule（每日07:00）。

可直接复制的材料

你是GitHub Actions供应链安全审计员。下面是待审的workflow YAML全文和规则引擎命中的条目：\n文件：{{$json.filePath}}\n规则命中：{{$json.ruleFindings}}\nYAML内容：\n{{$json.content}}\n只输出一个JSON对象：\n{\n  \"verdict\": \"safe | suspicious | malicious\",\n  \"riskLevel\": \"low | medium | high | critical\",\n  \"reasons\": [\"判定依据，引用具体行内容\"],\n  \"fixes\": [\"可执行的修复建议，未固定引用给出完整uses固定写法\"]\n}\n判定malicious/suspicious的典型信号：向外部域名发送secrets、curl|bash执行远程脚本、base64混淆命令、异常的自托管runner调用。仅版本未固定而无其他信号时最高只能判suspicious。

name: demo-insecure\non: [push]\njobs:\n  build:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@main\n      - name: setup\n        run: curl -sSL https://install.example-tools.dev/setup.sh | bash\n      - name: deploy\n        run: echo deploy\n        env:\n          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

github_owner: your-test-org\nowner_type: org\nrepo_name_filter: （留空=全部仓库）\nmax_repositories: 10\nmax_ai_reviews: 3\nslack_channel: #security-alerts-test\n说明：测试期用小max_repositories和max_ai_reviews控制GitHub API与Gemini调用量，稳定后再放大。

输入与输出示例

本站虚构演示，SHA与判定内容为示意，未实际调用GitHub或Gemini。

输入

对上面的测试文件demo-insecure执行一次手动扫描（基线中无该文件，视为新增）。

对应输出

规则引擎命中2条：「uses: actions/checkout@main 未固定到commit SHA（medium）」「curl远程脚本管道bash执行（critical）」；GraphQL解析返回固定建议 uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2；Gemini判定JSON：verdict=malicious、riskLevel=critical、reasons含「curl|bash执行外部脚本」；Slack测试频道收到即时告警，gha_security_inventory新增一行记录该文件SHA与结果。

做完检查这些

• 首跑后gha_security_inventory表存在且每个工作流文件有一行SHA记录
• 改动单个文件重跑，只有该文件进入下载/检测分支，其余文件结果保留
• 测试文件触发critical规则命中且Slack即时告警在几分钟内到达测试频道
• 未固定引用的告警文本中含可直接粘贴的uses: ...@<40位sha>建议
• 当日摘要消息中的统计数（扫描/变更/高危）与Data Table实际记录一致

容易卡住的地方

• 令牌缺Contents读权限会在枚举仓库阶段直接401；开issue需单独加Issues写权限
• owner_type填错（org/user不匹配）会列不到仓库
• 首次全量扫描大组织会消耗较多GitHub API配额，务必先小范围测试
• Gemini免费层有每日限额，max_ai_reviews过大时可能被截断；具体限额以Google官方为准
• YAML解析对非标准写法可能漏检，规则引擎是初筛不等于完整审计
• 自动开issue务必只用于自有私有仓库，避免对外部仓库造成骚扰