先控制泄露，再解释扫描结果
本篇用虚构的社区活动 API 项目说明仓库自查：开发者误把测试服务令牌写进配置，并准备检查依赖和访问控制。没有扫描任何真实仓库，也没有验证或使用任何凭据。原文中的暴露数量、安装量和匿名故事不作为本篇事实依据。目标是受限范围内的发现记录、可解释修复与实际复核结果，不是“扫过即安全”。
如果真实秘密已经公开，优先按服务商与团队流程撤销或轮换，并更新合法使用方；删除当前文件不能让已复制的值失效。保留不含秘密值的事件时间与影响范围，按权限检查使用日志。不要为了证明密钥有效而拿它调用未知服务，也不要把原值贴进聊天、截图或工单。历史清理是后续独立决策，不能代替撤销。
场景一：区分工作树、历史与其他泄露位置
先约定仓库、分支、提交范围、允许扫描的目录与报告位置。工作树扫描不能说明全部 Git 历史无问题，历史扫描也未必涵盖 Actions 日志、构建产物、发布附件、截图和外部副本。记录实际覆盖范围、工具版本、规则与排除项。浅克隆或不可访问分支应明确写为覆盖缺口。
Gitleaks 是公开的秘密检测参考，支持仓库与文件等检测场景，适合评估已有规则及本地集成方式。当前 README 说明项目已功能完备、后续以安全补丁为主，并转向其他开发重点，采用时需核对维护方向。工具、Action 与托管服务可能有不同许可或收费条件，不能把某个开源组件的许可扩展为全部集成免费。
在隔离副本先用明显无效、专门为测试准备的样例核对报告脱敏与退出行为。只在确定报告不会输出原始秘密后运行授权范围检查。结果保留规则、文件位置、提交标识、严重性依据及处置状态；报告本身也可能敏感，应限制访问和保留期限。不能默认某配置文件里的一个字段就保证全部输出已脱敏，应检查实际版本的受支持参数和产物。
正则与熵可以发现可疑字符串，也会漏掉未知格式或产生误报。确认是否为真实凭据时优先核对上下文和资产负责人，不主动试用。允许列表需要具体原因、范围与复核时间，不能为了让流水线变绿忽略整条目录。发现零项只说明该次范围和规则未检测到匹配，不证明从未泄露。
GitHub 平台秘密检测与本地检查可以互补，平台也有推送保护能力，不能笼统说它只会事后告警。支持范围取决于实际功能、仓库配置和账户条件。确认保护是否实际启用及适用规则，不在文章中替读者改变设置。清理远端历史会影响提交与协作，须协调副本、分支和恢复方案，不能自动强推或要求所有人盲目重拉。
场景二：依赖漏洞审计先识别实际版本
列清项目生态、清单、锁文件、安装环境及构建产物，区分声明版本与最终解析版本、直接与传递依赖、开发与生产用途。使用相应生态的受支持审计工具，记录数据库时间、命令模式和覆盖范围。没有锁文件时明确版本不确定性，不能拿别的机器依赖树作当前发布的事实。
每个告警保留包、版本、公告链接、引入路径和影响条件。严重度是排序线索，不等于本应用中一定可利用；是否可达、如何使用及缓解措施需要复核。反过来，未找到已知公告也不表示代码没有未知漏洞。网络或数据库不可用是审计失败，不能当成零漏洞。
修复先在分支评估最小兼容升级，检查变更说明和测试。自动强制升级可能引入破坏性变化，不能未经评估把所有版本更新到最新。复核锁文件、构建和相关行为，再重新审计确认具体告警状态；记录暂时无法修复的原因、缓解与复查日期。不要承诺所有生态工具都是只报告模式，执行前检查真实命令是否会修改文件或运行脚本。
本例可以把一个虚构的依赖告警作为流程练习，但不能伪造 CVE、受影响版本或升级后通过的记录。演练使用有来源的实际公告时，仍要对应项目真实版本。报告的目标是让维护者知道下一步如何验证，而不是堆叠无法复现的高危标签。
场景三：代码审查围绕数据流与权限
秘密检测与依赖审计不能替代代码逻辑审查。对社区 API，先列入口、身份、信任边界、存储及外部调用，再检查输入如何流向数据库、模板、命令和响应。对注入或 XSS 线索给出具体文件、输入路径和缺少的控制，不因看到字符串拼接就直接断言可利用。
访问控制检查应同时覆盖身份与对象权限。例如登录用户能否读取别人的活动记录，需要验证服务端对象范围，而不只是按钮是否隐藏。使用已授权的测试账户和虚构数据，建立允许与拒绝的最小用例；不探测无关系统，也不使用发现的凭据扩大权限。保留实际观察与待验证假设的区别。
修复应对应根因：参数化数据访问、适当输出编码、服务端权限判断及秘密配置边界，按技术栈选择正确机制。修改后检查原有正常行为与拒绝路径，避免只让扫描规则不再匹配。静态扫描、人工审阅和运行测试各有范围，任何一个绿色结果都不能被描述成全面安全认证。
可匹配 Skill 的具体位置
本次目录中的秘密相关条目包含 Azure 秘密管理，并非原文六个仓库扫描器，因此不猜测它们的安装链接。azure-keyvault-secrets-ts 只适用于已有 Azure/Node.js 项目在整改阶段管理应用秘密的可选步骤。需要对应 SDK、已配置身份、明确库地址和经授权的操作权限；实际服务可能收费。
该技能不能扫描 Git 历史、核实泄露范围或自动撤销外部服务令牌。秘密进入保管库不意味着旧值已经失效。来源示例包含读取、删除和清除等操作，不能整段照跑；尤其不应把秘密值打印到日志。先在允许的测试环境检查读取与失败行为，再按既定流程替换使用方。其固定来源和 MIT 许可有核验证据，运行及安全性仍需各自验证。
实操请求、排错与 FAQ
可请求：“只对指定仓库副本制定秘密、依赖和代码审查计划。报告使用脱敏标识，不显示凭据值。说明工作树与历史覆盖、锁文件版本及代码入口。先列发现与依据，不轮换凭据、不重写历史、不升级依赖或修改生产设置；后续修复按明确授权分步验证。”这把检测、处置与可能有副作用的操作分开。
密钥已经删掉怎么办？仍检查是否需要撤销并评估历史及其他副本。报告又泄露秘密怎么办？停止扩大传播，按团队事件流程限制报告并处理凭据。依赖审计没结果怎么办？确认工具成功、数据库可用和依赖范围。规则误报怎么办？记录具体依据和最小例外，不屏蔽整类风险。能自定义规则吗？按工具当前格式增加无效正反例，检查漏报与误报，不用真实秘密测试。
验收与来源
验收分别确认泄露凭据处置状态、扫描范围、依赖版本与公告对应、代码修复及回归结果，未执行部分标为未知。保存不含秘密值的证据、版本与责任人。参考 GitHub 秘密检测、敏感历史清理文档及 Gitleaks 项目，原文中英文来源配对保留。本例没有实际扫描、轮换、历史重写或漏洞利用，后续变更应按实际授权和协作流程执行。