Skip to content

Generate Dependency Vulnerability Tests from an SBOM

Updated 2026-06-08·advanced·Security Testing

Reads an SBOM (CycloneDX or SPDX) and returns test cases for known-vulnerability presence (CVE lookup against KEV catalog), license compliance (allow/deny list), transitive dependency drift, and prioritized update list based on exploitability and reach.

When to use it

  • Implementing supply-chain security audits as part of SOC 2 / ISO 27001 readiness.
  • Setting up dependency vulnerability gates in CI.
  • Migrating from one dependency scanner to another and need a behavior baseline.
  • Documenting supply-chain security posture for enterprise procurement reviews.

The prompt

XML-tagged — best for Claude 4.x

<role>
You are a supply-chain security analyst. You know the difference between CVSS score and EXPLOITABILITY, and that the CISA KEV catalog (Known Exploited Vulnerabilities) is more actionable than CVSS for prioritization.
</role>

<context>
SBOM = Software Bill of Materials. Two standards: CycloneDX (security focus) and SPDX (legal/license focus). Both list direct and transitive dependencies with versions. Vulnerabilities come from CVE database. Exploitability comes from CISA KEV (known actively exploited) + EPSS scores (probability). License compliance uses allow/deny lists tailored to the org.
</context>

<task>
For the SBOM excerpt below:
1. Identify direct vs transitive dependencies (test verification step).
2. Generate test cases for: known-CVE detection (cross-ref vs CVE DB + KEV catalog), license compliance (against given allow/deny list), transitive drift (versions out of sync with org standard).
3. Produce a prioritized update list — combine exploitability (KEV match), reach (used by N other deps), and CVSS.
4. Identify gaps in the SBOM (missing fields, ambiguous license, etc.).
</task>

<input>
SBOM excerpt (CycloneDX or SPDX JSON): {sbom}
License allow list: {allow_licenses}
License deny list: {deny_licenses}
Org standard versions (key deps): {org_standards}
</input>

<constraints>
- Distinguish DIRECT from TRANSITIVE in every test case.
- KEV match is a higher-priority signal than CVSS — surface KEV matches first.
- License test verifies BOTH allow-list compliance and deny-list non-match.
- Update priority combines: KEV match (P1), high EPSS + critical CVSS (P1), critical CVSS alone (P2), license violations (P2 or P3), etc.
- Identify SBOM gaps (missing license fields, no version, etc.).
</constraints>

<output_format>
Five sections:
1. **Test scenarios table** — Test name | Direct/Transitive | What's checked | Expected result | Tool
2. **Prioritized update list** — Component | Version | Vulnerability | Priority | Rationale
3. **License compliance** — pass/fail per component
4. **SBOM gaps** — bullets
5. **CI integration sketch** — pseudocode for running these checks
</output_format>

Before writing, scan the SBOM for direct dependencies vs transitive — most attack surface is in transitives.

Example

Common pitfalls

  • Model treats CVSS as exploitability — they're different. CVSS measures severity if exploited; EPSS / KEV measure likelihood. Both matter.
  • Direct vs transitive distinction gets lost; most attack surface is in transitives.
  • License check is one-sided — only checks allow list, not deny list. Both are needed (some licenses might not be in either list).
  • SBOM gaps glossed over — missing fields are CRITICAL for evidence trails.

Tips

  • Re-run on every PR; supply chain changes faster than you think.
  • Sign SBOMs with Sigstore for provenance — required for SLSA Level 3+.
  • Cache CVE database lookups between runs — full re-scan adds 5+ min to CI.
  • Pair with `security-test-checklist` (V14.5 Dependencies) for control coverage.

FAQ

CycloneDX has better security tooling support; SPDX has better legal/license tooling. Most security teams target CycloneDX. If your org has only one, generate both (tools exist).

Related prompts