AI-powered software supply chain security auditing skill for agentic platforms. Performs comprehensive dependency vulnerability scanning across npm, PyPI, Maven, Go modules, Cargo, and container images. Generates SBOMs (Software Bill of Materials) in SPDX and CycloneDX formats using Syft and Grype. Validates license compliance against organizational policies and detects copyleft risks. Verifies cryptographic provenance and SLSA framework attestations using cosign and slsa-verifier. Executes a structured audit methodology—Scan → Analyze → Report → Remediate—producing machine-readable vulnerability reports with CVSS scores, exploitability assessments, and actionable fix recommendations aligned with OWASP Agentic Skills Top 10 guidance. Integrates with ecosystem vulnerability databases including NVD (National Vulnerability Database), GitHub Advisory Database (GHSA), and Open Source Vulnerabilities (OSV). Covers software composition analysis (SCA) workflows, dependency confusion detection, typosquatting checks, a
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
This skill activates when a user requests a supply chain security action.
Primary Triggers (activate)
"scan my project for vulnerable dependencies"
"generate an SBOM for this repository"
"check if our npm packages have known CVEs"
"audit our software supply chain"
"verify the provenance of this container image"
"run a dependency vulnerability scan"
"check license compliance of our dependencies"
"generate a CycloneDX SBOM"
"verify SLSA provenance for this build artifact"
"scan this Docker image for vulnerabilities"
"run software composition analysis on this codebase"
"check for dependency confusion attacks"
"audit pip packages for security issues"
"generate SPDX bill of materials"
Near-Miss Negatives (do NOT activate)
"explain what SBOM means" — informational request, no action needed
"how do I secure my npm packages?" — general security advice, not a scan
"what is SLSA provenance?" — definition/education request, not verification
If a user asks an educational question, answer it directly without launching a scan.
If a user asks for general security advice, provide guidance without running tooling.
Prerequisites
The following CLIs must be available. The scripts in scripts/ perform capability
detection automatically and report which tools are missing before any scan runs.
Parallel scanning — Run all applicable scanners concurrently:
npm audit --json for Node.js projects
pip-audit --format=json for Python projects
owasp-dependency-check --format JSON for JVM projects
grype dir:. --output json for general-purpose scanning
trivy fs . --format json for comprehensive filesystem scan
trivy image <image> for container images
SBOM generation — Produce an SBOM before scanning so results are anchored to
a specific dependency graph snapshot. Default: CycloneDX JSON. Option: SPDX tag-value.
Provenance check — For container images and build artifacts with attached
attestations, verify SLSA provenance and signature chains.
Phase 2: ANALYZE
Goal: Correlate findings, de-duplicate, and prioritize.
De-duplication — Merge findings from multiple scanners by CVE ID. Keep the
highest CVSS score and most detailed advisory for each unique vulnerability.
Strengths: Fast, built-in, understands npm dependency resolution quirks.
Limitations: Only covers the npm registry advisory database. Does not cover
transitive dependencies outside the lockfile. No license or provenance checking.
# Basic scan of current directory
dependency-check --project "MyProject" --scan . --format JSON --out ./reports/
# With NVD API key (required for production use; increases rate limits)
dependency-check --nvdApiKey $NVD_API_KEY --project "MyProject" --scan .
# HTML report for stakeholders
dependency-check --project "MyProject" --scan . --format HTML --out ./reports/
Strengths: Broad language support (Java, .NET, Ruby, Python, Node.js via OSS Index),
NVD integration, CPE matching. Mature and OWASP-backed.
Limitations: Slow on first run (downloads NVD data feed). Java-centric. Large memory
footprint (allocate -Xmx4g for large projects).
Syft + Grype (SBOM-based Scanning)
Syft generates an SBOM. Grype scans the SBOM for vulnerabilities.
This separation is powerful: generate once, scan many times with updated vulnerability data.
# Generate CycloneDX SBOM
syft dir:. --output cyclonedx-json > sbom.cdx.json
# Generate SPDX SBOM
syft dir:. --output spdx-json > sbom.spdx.json
# Scan SBOM with Grype
grype sbom:sbom.cdx.json --output json > vulnerabilities.json
# Fail on critical/high (exit code 1)
grype sbom:sbom.cdx.json --fail-on high
# Only show fixable vulnerabilities
grype sbom:sbom.cdx.json --only-fixed
Strengths: Works across all ecosystems. SBOM is reusable across tools. Fast.
Limitations: Requires both syft and grype. SBOM must be regenerated when dependencies
change.
Strengths: Single binary, covers filesystem + images + repos + K8s, built-in SBOM
generation, fast, actively maintained by Aqua Security.
Limitations: Less granular license detection than dedicated tools. Some false positives
in go.sum scanning.
Strengths: Cryptographic proof of build integrity. SLSA framework compliance.
Limitations: Only works when build system produces attestations (GitHub Actions with
SLSA generator, Google Cloud Build, etc.). Most open-source projects lack attestations today.
SBOM Generation & Management
SBOM Formats
Aspect
SPDX
CycloneDX
Originating body
Linux Foundation
OWASP
Primary use case
License compliance
Security/vulnerability
Mandatory fields
12 fields (SPDX 2.3)
5 fields (CycloneDX 1.5)
JSON schema
Yes
Yes
Tag-value format
Yes (unique to SPDX)
No
NTIA minimum elements
✅
✅
Vulnerability data
Via external ref
Native VEX support
Tool ecosystem
FOSSology, ORT
Syft, Trivy, Grype, Dependency-Track
Recommendation: Generate both. CycloneDX for security tooling (Grype, Dependency-Track);
SPDX for license compliance (FOSSology, ORT). Use Syft with --output to produce either format.
NTIA Minimum Elements for SBOM
Per U.S. Executive Order 14028 and NTIA guidance, every SBOM must include:
Supplier name — Entity creating the component
Component name — Human-readable identifier
Version — Version string of the component
Unique identifier — PURL, CPE, or SWID tag
Dependency relationships — Which components depend on which
Author — SBOM creator
Timestamp — When SBOM was generated
SBOM Lifecycle
Build → Generate SBOM → Sign → Attest → Store → Monitor → Update on change
Generate: At every build, tag, or release
Sign:cosign sign-blob or in-toto attestation
Store: Commit to repo, upload to Dependency-Track, or push to OCI registry
Monitor: Regularly re-scan stored SBOMs against updated vulnerability databases
Update: Regenerate whenever package.json, Cargo.lock, or equivalent changes
Provenance Verification
SLSA Framework Levels
Level
Name
Requirements
0
None
No guarantees. Ad-hoc builds.
1
Build is scripted
Build process documented, build-as-code.
2
Build service + provenance
Hosted build platform (GitHub Actions, Cloud Build), signed provenance attestation.
Running npm audit or pip-audit against package.json or requirements.txt without
lockfiles only scans direct dependencies. Transitive dependencies (which account for
~80% of vulnerabilities) are missed.
✅ Fix: Always use lockfiles. Commit them. Scan the lockfile, not the manifest.
❌ Trusting CVSS Scores Blindly
A CVSS 7.5 vulnerability in a development-only tool (e.g., a test runner) that never
touches production data is less urgent than a CVSS 5.0 vulnerability in a
network-facing production dependency.
✅ Fix: Contextualize CVSS with asset criticality, attack surface, and actual usage.
❌ Ignoring License Compliance
Teams often focus exclusively on CVEs and overlook license violations. Using a
GPL-licensed library in proprietary software can be as damaging as a vulnerability.
✅ Fix: Always run license detection alongside vulnerability scanning.
❌ One-Time Scans
A scan at release time finds vulnerabilities that may have been present (and exploitable)
for weeks. The mean time to detect (MTTD) for supply chain attacks is measured in months.
✅ Fix: Scan on every push, every PR, and nightly on a schedule. Integrate into CI/CD.
❌ Blocking Deployments on Every Finding
Failing CI on every medium-severity finding leads to alert fatigue and teams disabling
the check entirely.
✅ Fix: Fail on Critical/High with known exploits only. Track Medium findings as
tickets. Use grace periods for newly published CVEs without fixes.
❌ Using Outdated Vulnerability Databases
Running grype without updating its database scans against stale data. New CVEs are
published daily. Supply chain attacks appear suddenly.
✅ Fix: Always update databases before scanning (grype db update, trivy image --refresh).
❌ Generating SBOMs Without Storing Them
An SBOM generated and discarded is useless. SBOMs are only valuable when preserved
alongside the artifact they describe.
✅ Fix: Commit SBOMs to the repository, attach to releases, or push to a dedicated
SBOM registry. Treat them as build artifacts with the same retention as binaries.
❌ Assuming Provenance Exists
Currently, the vast majority of open-source projects and container images lack
SLSA provenance attestations. Assuming provenance exists leads to false confidence.
✅ Fix: Distinguish between "provenance verified" and "no provenance available".
Flag the latter as a risk, not a pass. Prefer artifacts with provenance when choosing
between alternatives.
Production scans should use Grype or Trivy, which aggregate all three databases internally.
OWASP Agentic Skills Top 10 Context
The OWASP Agentic Skills Top 10 (AST10:2026) highlights supply chain security as a
critical concern for agentic AI platforms. Key risks relevant to this skill:
AST01:2026 — Prompt Injection via Malicious Dependencies: A compromised
dependency can inject malicious prompts into agent workflows. SBOM verification
and provenance checks are defensive controls.
AST03:2026 — Insecure Skill Design: Skills without supply chain scanning
may themselves contain vulnerable dependencies. Self-audit with this skill.
AST06:2026 — Excessive Agency via Compromised Tools: Vulnerable CLI tools
(scanners themselves) can be attack vectors. Keep scanners updated.
AST08:2026 — Supply Chain Poisoning: Directly the domain of this skill.
Dependency confusion, typosquatting, and compromised registries.
See references/owasp-ast10-summary.md for the full summary.
