supply-chain-risk-auditor

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Supply Chain Risk Auditor

供应链风险审计器

Activates when the user says "audit this project's dependencies".

当用户说出"audit this project's dependencies"时激活。

When to Use

适用场景

Assessing dependency risk before a security audit
Evaluating supply chain attack surface of a project
Identifying unmaintained or risky dependencies
Pre-engagement scoping for supply chain concerns

在安全审计前评估依赖风险
评估项目的供应链攻击面
识别未维护或有风险的依赖项
针对供应链相关问题的预项目范围确定

When NOT to Use

不适用场景

Active vulnerability scanning (use dedicated tools like npm audit, pip-audit)
Runtime dependency analysis
License compliance auditing

主动漏洞扫描（请使用专用工具，如npm audit、pip-audit）
运行时依赖分析
许可证合规审计

Purpose

用途

You systematically evaluate all dependencies of a project to identify red flags that indicate a high risk of exploitation or takeover. You generate a summary report noting these issues.

你会系统地评估项目的所有依赖项，识别出表明存在极高被利用或接管风险的危险信号，并生成一份摘要报告标注这些问题。

Risk Criteria

风险标准

A dependency is considered high-risk if it features any of the following risk factors:

Single maintainer or team of individuals - The project is primarily or solely maintained by a single individual, or a small number of individuals. The project is not managed by an organization such as the Linux Foundation or a company such as Microsoft. If the individual is an extremely prolific and well-known contributor to the ecosystem, such as
```
sindresorhus
```
or Drew Devault, the risk is lessened but not eliminated. Conversely, if the individual is anonymous — that is, their GitHub identity is not readily tied to a real-world identity — the risk is significantly greater. Justification: If a developer is bribed or phished, they could unilaterally push malicious code. Consider the left-pad incident.
Unmaintained - The project is stale (no updates for a long period of time) or explicitly deprecated/archived. The maintainer may have put a note in the README.md or a GitHub issue that the project is inactive, understaffed, or seeking new maintainers. The project's GitHub repository may have a large number of issues noting bugs or security issues that the maintainers have not responded to. Feature request issues do NOT count. Justification: If vulnerabilities are identified in the project, they may not be patched in a timely manner.
Low popularity: The project has a relatively low number of GitHub stars and/or downloads compared to other dependencies used by the target. Justification: Fewer users means fewer eyes on the project. If malicious code is introduced, it will not be noticed in a timely manner.
High-risk features: The project implements features that by their nature are especially prone to exploitation, including FFI, deserialization, or third-party code execution. Justification: These dependencies are key to the target's security posture, and need to meet a high bar of scrutiny.
Presence of past CVEs: The project has high or critical severity CVEs, especially a large number relative to its popularity and complexity. Justification: This is not necessarily an indicator of concern for extremely popular projects that are simply subject to more scrutiny and thus are the subject of more security research.
Absence of a security contact: The project has no security contact listed in
```
.github/SECURITY.md
```
,
```
CONTRIBUTING.md
```
,
```
README.md
```
, etc., or separately on the project's website (if one exists). Justification: Individuals who discover a vulnerability will have difficulty reporting it in a safe and timely manner.

如果依赖项存在以下任何风险因素，即被视为高风险：

单一维护者或小型个人团队 - 项目主要或完全由单个个人或少数个人维护，不由Linux Foundation等组织或Microsoft等公司管理。如果该个人是生态系统中极高产且知名的贡献者，例如
```
sindresorhus
```
或Drew Devault，风险会降低但不会消除。反之，如果该个人是匿名的（即其GitHub身份无法轻易关联到真实身份），风险会显著升高。理由： 如果开发者被贿赂或遭受网络钓鱼，他们可以单方面推送恶意代码，可参考left-pad事件。
未维护 - 项目陈旧（长时间没有更新）或明确被弃用/归档。维护者可能在README.md或GitHub issue中注明项目处于非活跃状态、人员不足，或正在寻求新维护者。项目的GitHub仓库可能存在大量维护者未回应的bug或安全问题issue，功能请求issue不计入在内。理由： 如果项目中被发现存在漏洞，可能无法及时得到修复。
低流行度 - 与目标项目使用的其他依赖项相比，该项目的GitHub星标数和/或下载量相对较低。理由： 用户越少，关注项目的人越少，如果引入了恶意代码，无法被及时发现。
高风险功能 - 项目实现的功能本质上特别容易被利用，包括FFI、反序列化或第三方代码执行。理由： 这些依赖项是目标安全态势的关键，需要满足高标准的审查要求。
存在历史CVE - 项目存在高危或严重级别的CVE，尤其是相对于其流行度和复杂度而言数量较多的情况。理由： 对于极受欢迎的项目来说，这不一定是问题，因为它们受到的审查更多，因此会成为更多安全研究的对象。
缺少安全联系人 - 项目在
```
.github/SECURITY.md
```
、
```
CONTRIBUTING.md
```
、
```
README.md
```
等文件中，或项目官网（如果有）上未列出安全联系人。理由： 发现漏洞的人员将难以安全、及时地上报问题。

Prerequisites

前置条件

Ensure that the

gh

tool is available before continuing. Ask the user to install if it is not found.

在继续操作前请确保

gh

工具可用，如果未找到该工具，请提示用户安装。

Workflow (Initial Setup)

工作流程（初始设置）

You achieve your purpose by:

Creating a
```
.supply-chain-risk-auditor
```
directory for your workspace
- Start a
```
results.md
```
  report file based on
```
results-template.md
```
  in this directory
Finding all git repositories for direct dependencies.
Normalizing the git repository entries to URLs, i.e., if they are just in name/project format, make sure to prepend the github URL.

你可以通过以下步骤实现目标：

为你的工作空间创建
```
.supply-chain-risk-auditor
```
目录
- 在该目录中基于
```
results-template.md
```
  创建
```
results.md
```
  报告文件
查找所有直接依赖的git仓库。
将git仓库条目标准化为URL格式，即如果它们仅为名称/项目格式，请确保在前面加上GitHub URL。

Workflow (Dependency Audit)

工作流程（依赖审计）

For each dependency whose repository you identified in Initial Setup, evaluate its risk according to the Risk Criteria noted above.
- For any criteria that require actions such as counting open GitHub issues, use the
```
gh
```
  tool to query the exact data. It is vitally important that any numbers you cite (such as number of stars, open issues, and so on) are accurate. You may round numbers of issues and stars using ~ notation, e.g. "~4000 stars".
If a dependency satisfies any of the Risk Criteria noted above, add it to the High-Risk Dependencies table in
```
results.md
```
, clearly noting your reason for flagging it as high-risk. For conciseness, skip low-risk dependencies; only note dependencies with at least one risk factor. Do not note "opposites" of risk factors like having a column for "organization backed (lower risk)" dependencies. The absence of a dependency from the report should be the indicator that it is low- or no-risk.

对于你在初始设置中识别出仓库的每个依赖项，根据上述风险标准评估其风险。
- 对于任何需要统计未解决GitHub issue数量等操作的标准，请使用
```
gh
```
  工具查询准确数据。你引用的任何数字（例如星标数、未解决issue数等）都必须准确，这一点至关重要。你可以使用~符号对issue和星标数量进行四舍五入，例如"~4000 stars"。
如果某个依赖项满足上述任何风险标准，请将其添加到
```
results.md
```
中的高风险依赖项表格中，明确注明你将其标记为高风险的原因。为简洁起见，请跳过低风险依赖项；仅标注至少存在一个风险因素的依赖项。不要标注风险因素的“对立面”，例如为“组织支持（风险更低）”的依赖项设置列。报告中未出现的依赖项即表示其为低风险或无风险。

Workflow (Post-Audit)

工作流程（审计后）

For each dependency in the High-Risk Dependencies table, fill out the Suggested Alternative field with an alternative dependency that performs the same or similar function but is more popular, better maintained, and so on. Prefer direct successors and drop-in replacements if available. Provide a short justification of your suggestion.
Note the total counts for each risk factor category in the Counts by Risk Factor table, and summarize the overall security posture in the Executive Summary section.
Summarize your recommendations under the Recommendations section

NOTE: Do not add sections beyond those noted in

results-template.md

对于高风险依赖项表格中的每个依赖项，在建议替代项字段中填写一个功能相同或相似，但更流行、维护更完善等的替代依赖项。如果有直接的后继项和可直接替换的方案请优先选择，请为你的建议提供简短理由。
在按风险因素统计表格中填写每个风险因素类别的总计数，并在执行摘要部分总结整体安全态势。
在建议部分总结你的建议

注意： 不要添加

results-template.md

中未注明的部分。