技能介绍

要解决的问题

企业暴露在公网上的凭据泄露，往往不会主动浮出水面。一个被误提交的 application.yml、一份带私钥的配置文件，可能静静躺在公开 GitHub 仓库里数月无人察觉。传统做法是拿 gitleaks 扫一遍，但这只对已知仓库有效：你不知道该扫哪个仓库，搜什么关键词，扫完的海量告警里哪些才是真实可用的密钥。

本技能要解决的正是这个情报缺失环节：从零关键词起步，帮你定位候选仓库、设计精准命中规则、过滤噪音、做取证核验，最终产出可交付的报告与可跟踪的整改台账。

工作原理：六阶段流水线

Phase 1 · OSINT 情报收集：先摸清目标的域名、子域（尤其 openapi.*、pay.* 这类）、官方组织、SDK 命名风格和凭据字段命名规范。若有开源 SDK，直接 grep 其中的 private_key、appId、merchant 等字段，反推出命名规范。

Phase 2 · GitHub 检索：基于 Phase 1 的字典渲染 58 条 dork，以「至少两个正交关键词」为原则（如 filename:application.yml + 目标标识），覆盖 Java/PHP/Python/Node/.NET 五种以上语言，并处理 Code Search API 的 rate limit。

Phase 3 · 克隆 + 扫描：用 gitleaks --no-git --redact=0 --exit-code 0 只扫工作树、保留原文、不中断流水线。规则文件用非捕获分组 (?:...)，避开 go-re2 不支持的反向引用与断言。

Phase 4 · 智能分级：原始 findings 含 90%+ 噪音，按长度 >300 的 RSA 私钥判 CRITICAL，PEM 密钥块判 HIGH，AppID/商户号判 MEDIUM，测试目录与 example 关键字一律降级为 LOW。

Phase 5 · 深度取证：对 .pfx/.p12 证书爆破密码（同目录配置文件、变量名、弱口令字典三路尝试），用 OpenSSL -legacy 参数兼容老式加密，并从证书 Subject 的 CN 字段反查商户统一社会信用代码。

Phase 6 · 报告输出：从统一的 _REPORT.json 驱动生成 DOCX（完整版/精简整改版）、Excel 台账（状态列下拉验证 + 条件格式自动变色 + 优先级色标）、HTML 与 Markdown 四种格式。

适用边界与合规红线

不适用：内网密钥审计（直接 gitleaks 扫本地仓库即可）、单一仓库审计（gitleaks detect 更快）、单次关键词搜索（GitHub Web UI 更快）。
每次调用前必须确认：是否已获得目标企业的书面授权，授权范围是否覆盖本次目标，证据是否需要脱敏交付。
红线：未授权扫描涉嫌违反《网络安全法》；用泄露证书调用生产 API 涉嫌破坏计算机信息系统罪；证据物公开传播涉嫌侵犯商业秘密。
排查中意外发现其他机构的敏感信息，不得对外泄露，应按行业互信机制与授权方协商处置。