| name | supply-chain-risk-auditor |
| description | Identifies dependencies at heightened risk of exploitation or takeover. Use when assessing supply chain attack surface, evaluating dependency health, or scoping security engagements. |
| type | skill |
| created | 2026-02-27T00:00:00.000Z |
| domain | security |
| category | compliance |
| risk | unknown |
| source | community |
| tags | ["skill","security","compliance","supply","chain","risk"] |
Supply Chain Risk Auditor
Activates when the user says "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
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.
