supply-chain-risk-auditor

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

Systematically evaluate all dependencies of a project to identify red flags that indicate a high risk of exploitation or takeover, and 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.