| name | devsecops-supply-chain |
| description | Generate SBOM (CycloneDX/SPDX), verify SLSA provenance, audit dependency chains, and detect supply chain attack patterns. |
| version | 1.0.0 |
| last-updated | 2026-04-17 |
| model_tested | claude-sonnet-4-6 |
| category | devsecops |
| platforms | ["claude-code","codex","gemini-cli","cursor","copilot","windsurf","cline"] |
| language | en |
| geo_relevance | ["global"] |
| priority | high |
| dependencies | {"mcp":[],"skills":[],"apis":[],"data":[]} |
| update_sources | [{"url":"https://slsa.dev/spec/v1.0/","check_frequency":"quarterly","last_checked":"2026-04-17"}] |
| license | MIT |
DevSecOps Supply Chain Security
When to Use
- Setting up dependency security for a new project
- Generating SBOM for compliance or audit
- Investigating a suspicious dependency
- Responding to a supply chain incident
- Configuring CI/CD security gates
SBOM Generation
Formats
| Format | Standard | Best For |
|---|
| CycloneDX | OWASP | Security-focused, VEX support |
| SPDX | Linux Foundation | License compliance, legal |
Generation Commands
If a terminal is available, use these commands. Otherwise, describe what fields to include manually.
Node.js/npm:
npx @cyclonedx/cyclonedx-npm --output-file sbom.json
Python/pip:
pip install cyclonedx-bom
cyclonedx-py requirements -i requirements.txt -o sbom.json
Go:
cyclonedx-gomod mod -json -output sbom.json
SLSA Compliance Levels
| Level | Requirement | How |
|---|
| SLSA 1 | Documentation of build process | Document build steps |
| SLSA 2 | Hosted build platform, signed provenance | Use GitHub Actions, sign with Sigstore |
| SLSA 3 | Hardened build platform, non-falsifiable provenance | Isolated builders, hermetic builds |
Supply Chain Attack Patterns
| Pattern | Detection | Prevention |
|---|
| Typosquatting | Compare package name to known packages | Pin exact versions |
| Dependency confusion | Check if internal name exists on public registry | Scope packages, configure registry priority |
| Compromised maintainer | Monitor for unusual releases, new maintainers | Pin versions + hashes, delayed adoption |
| Malicious post-install | Audit install scripts | --ignore-scripts flag, review before install |
| Star-jacking | Verify GitHub URL matches npm/PyPI metadata | Cross-reference package metadata |
Dependency Audit Checklist
- Are all dependencies pinned to exact versions?
- Are lockfiles committed and reviewed in PRs?
- Are dependency hashes verified (pip
--require-hashes, npm --package-lock-only)?
- Is there a delay before adopting new package versions (7+ days)?
- Are transitive dependencies audited (not just direct)?
- Are install scripts reviewed for new dependencies?
- Is there automated vulnerability scanning in CI?
What This Skill Does NOT Do
- Does not patch vulnerabilities automatically
- Does not detect zero-day exploits
- Does not replace tools like Snyk, Dependabot, or pip-audit (complements them)
- Does not manage secrets rotation
