findscripter 何时使用
适用：
- 在正式安全审计前评估依赖风险、为接单做攻击面定级（pre-engagement scoping）
- 梳理项目供应链攻击面，识别无人维护或高危的依赖
- 判断哪些依赖最可能被投毒、接管或长期失修
不该用（负边界）：
- 主动漏洞/CVE 扫描——用
npm audit、pip-audit等专用工具 - 运行时依赖行为分析
- License 合规审计
本技能是定性的"风险面评估"，回答"哪些依赖值得警惕"，不替代自动化漏洞扫描器。
步骤
整体流程：初始化 → 逐个评估 → 汇总成报告。
- 初始化
- 建工作目录
.supply-chain-risk-auditor/，在其中基于模板新建results.md。 - 找出所有直接依赖对应的 git 仓库。
- 把仓库标识统一规范成完整 URL（若只有
owner/repo形式，补全为https://github.com/owner/repo）。
- 建工作目录
- 逐依赖审计：对每个依赖按下方"风险判据"逐条核查；任意命中一条即记入
results.md的高风险表，并写明命中原因。低风险依赖直接跳过——不在报告里列"组织背书/低风险"这类反向条目，"不在报告中"本身即代表低风险。 - 审计后收尾：
- 为每条高风险依赖填"建议替代项"（功能相同/相近、更流行、维护更好，优先直接后继或可平替），附一句理由。
- 在"按风险因素统计"表里汇总各类计数，在"执行摘要"里概述整体安全态势。
- 在"建议"小节给出处置建议。不要新增模板之外的小节。
指令
前置：确认 gh 可用，不可用则请用户先安装 GitHub CLI。
风险判据（命中任意一条即为高风险）：
- 单一维护者/小团队：项目主要由个人或极少数人维护，非 Linux 基金会、微软等组织/公司托管。知名高产作者（如 sindresorhus、Drew Devault）风险降低但不消除；维护者身份匿名（GitHub 身份无法对应真实身份）则风险显著升高。理由：维护者一旦被贿赂或钓鱼即可单方面推恶意代码（参考 left-pad 事件）。
- 无人维护：长期无更新，或显式 deprecated/archived；README 或 issue 中声明项目停滞、缺人、求接手；大量报 bug/安全问题的 issue 长期无响应（功能请求类 issue 不计入）。理由：漏洞难以被及时修复。
- 流行度低：相比目标项目用到的其它依赖，star/下载量明显偏低。理由：用的人少，恶意代码不易被及时发现。
- 高危特性：天然易被利用的能力，如 FFI、反序列化、执行第三方代码。理由：这类依赖对目标安全态势至关重要，需更高审查标准。
- 历史高危 CVE：存在 high/critical 级 CVE，尤其相对其流行度与复杂度数量偏多。理由：但极流行项目因受更多审查而 CVE 偏多，未必代表更危险，需结合判断。
- 缺安全联系人：
.github/SECURITY.md、CONTRIBUTING.md、README.md或官网均无安全上报渠道。理由：漏洞发现者难以安全、及时地上报。
数据准确性（关键约束）：凡涉及计数（star 数、open issue 数等），必须用 gh 查询真实数据，不得臆测。可用 ~ 近似表示，如 "~4000 stars"。
示例
用 gh 拉取仓库元数据用于核查流行度与维护状态：
gh repo view owner/repo --json stargazerCount,pushedAt,isArchived,licenseInfo
统计未关闭 issue（核查"无人维护"判据）：
gh issue list -R owner/repo --state open --limit 1 --json number | jq length
# 或直接看总数
gh api repos/owner/repo --jq '.open_issues_count'
高风险表行示例（写入 results.md）：
| Dependency | Risk Factors | Notes | Suggested Alternative |
|---|---|---|---|
| left-pad | 单一维护者, 流行度低 | 单人维护、匿名背景、可被单方面发布 | String.prototype.padStart - 标准库内置，无需第三方依赖 |
注意事项
- 只记命中风险的依赖，保持报告精简；不要列反向（低风险）条目。
- 不要新增
results-template.md之外的小节。 - 引用的所有数字必须来自
gh实测，可用~近似但不可编造。 - 高产/知名维护者只降低风险、不清零；匿名维护者风险更高。
- CVE 数量需结合流行度解读，避免对热门项目误判。
互见
- dependency-auditor：偏向已知漏洞/版本层面的依赖审计，可与本技能的定性风险面评估互补。
- code-reviewer：审到具体依赖的高危特性（FFI、反序列化等）时，可下钻做代码层审查。
本条采编自 trailofbits/skills（CC-BY-SA-4.0）。