supply-chain-risk-auditor
- Repo stars 5,723
- Forks 499
- Author updated Jun 15, 2026, 04:05 PM
- Author repo skills
- Domain
- AI
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @trailofbits · no license declared
- Token usage
- Lean
- Setup complexity
- Guided setup
- External API key
- Not required
- Operating systems
- Linux
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Shell exec
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools，默认拥有全部工具权限。
---
name: supply-chain-risk-auditor
description: Identifies dependencies at heightened risk of exploitation or takeover. Use when assessing suppl…
category: ai
runtime: no special runtime
---
# supply-chain-risk-auditor output preview
## PART A: Task fit
- Use case: Identifies dependencies at heightened risk of exploitation or takeover. Use when assessing supply chain attack surface, evaluating dependency health, or scoping security engagements..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “When to Use / When NOT to Use / Purpose” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Identifies dependencies at heightened risk of exploitation or takeover. Use when assessing supply chain attack surface, evaluating dependency health, or scoping security engagements.”.
- **02** When the source has headings, the agent prioritizes “When to Use / When NOT to Use / Purpose” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. Choose the trigger
The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Provide inputs and boundaries
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files, run shell commands.
Validate with a small run
Start with a small task and check whether the result follows “When to Use / When NOT to Use / Purpose”. Inspect diffs, logs, previews, or tests before expanding scope.
Review before delivery
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: supply-chain-risk-auditor
description: Identifies dependencies at heightened risk of exploitation or takeover. Use when assessing suppl…
category: ai
source: trailofbits/skills
---
# supply-chain-risk-auditor
## When to use
- Identifies dependencies at heightened risk of exploitation or takeover. Use when assessing supply chain attack surface…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “When to Use / When NOT to Use / Purpose” and keep inference separate from source facts.
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. Evidence boundary and execution chain
The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "supply-chain-risk-auditor" {
input -> user goal + target files + boundaries + acceptance criteria
context -> When to Use / When NOT to Use / Purpose
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files, run shell commands | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
}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
sindresorhusor 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.
Prerequisites
Ensure that the gh tool is available before continuing. Ask the user to install if it is not found.
Workflow (Initial Setup)
You achieve your purpose by:
- Creating a
.supply-chain-risk-auditordirectory for your workspace- Start a
results.mdreport file based onresults-template.mdin this directory
- Start a
- 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.
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
ghtool 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".
- For any criteria that require actions such as counting open GitHub issues, use the
- 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.
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.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review