Parses Software Bill of Materials (SBOM) in CycloneDX and SPDX JSON formats to identify supply chain vulnerabilities by correlating components against the NVD CVE database via the NVD 2.0 API. Builds dependency graphs, calculates risk scores, identifies transitive vulnerability paths, and generates compliance reports. Activates for requests involving SBOM analysis, software composition analysis, supply chain security assessment, dependency vulnerability scanning, CycloneDX/SPDX parsing, or CVE correlation.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Parses Software Bill of Materials (SBOM) in CycloneDX and SPDX JSON formats to identify supply chain vulnerabilities by correlating components against the NVD CVE database via the NVD 2.0 API. Builds dependency graphs, calculates risk scores, identifies transitive vulnerability paths, and generates compliance reports. Activates for requests involving SBOM analysis, software composition analysis, supply chain security assessment, dependency vulnerability scanning, CycloneDX/SPDX parsing, or CVE correlation.
A new regulatory requirement (EO 14028, EU CRA) mandates SBOM analysis for software deliveries
Security team needs to assess third-party risk by scanning vendor-provided SBOMs
CI/CD pipeline requires automated vulnerability checks against generated SBOMs
Incident response needs to determine if a newly disclosed CVE affects deployed software
Procurement team requires supply chain risk assessment for a software acquisition
Do not use for runtime vulnerability scanning of live systems; use container scanning tools (Trivy, Grype CLI) or host-based vulnerability scanners (Nessus, Qualys) instead.
Prerequisites
SBOM file in CycloneDX JSON (v1.4+) or SPDX JSON (v2.3+) format
Python 3.9+ with requests, networkx, and packaging libraries installed
Optionally: syft for SBOM generation, grype for cross-validation
Workflow
Step 1: Generate SBOM (if not provided)
Use syft to create an SBOM from a container image or project directory:
# Generate CycloneDX JSON from a container image
syft alpine:latest -o cyclonedx-json > sbom-cyclonedx.json
# Generate SPDX JSON from a project directory
syft dir:/path/to/project -o spdx-json > sbom-spdx.json
# Generate from a running container
syft docker:my-app-container -o cyclonedx-json > sbom.json
Syft supports over 30 package ecosystems including npm, PyPI, Maven, Go modules, apt, apk, and RPM. The generated SBOM includes package names, versions, licenses, CPE identifiers, and PURL (Package URL) references.
Step 2: Parse SBOM and Extract Components
Parse the SBOM to extract all software components with their identifiers:
The NVD API supports searching by CPE name (most precise), keyword, CVE ID, and date ranges. Rate limits: 5 requests/30 seconds without API key, 50 requests/30 seconds with key.
Step 4: Build Dependency Graph and Identify Transitive Risks
Construct a directed graph of dependencies to trace vulnerability propagation:
import networkx as nx
defbuild_dependency_graph(sbom):
G = nx.DiGraph()
# Add nodes for each componentfor comp in sbom["components"]:
G.add_node(comp["purl"], name=comp["name"], version=comp["version"])
# Add edges from dependency relationshipsfor dep in sbom.get("dependencies", []):
for child in dep.get("dependsOn", []):
G.add_edge(dep["ref"], child)
return G
Transitive dependency analysis identifies components that are not directly included but are pulled in through dependency chains. A vulnerability in a deeply nested transitive dependency (e.g., 4 levels deep) still represents risk but may be harder to remediate.
Key graph metrics for risk assessment:
In-degree: How many components depend on this one (high in-degree = high blast radius)
Shortest path to root: Distance from application entry point (closer = more exploitable)
Betweenness centrality: Components that sit on many dependency paths (bottleneck risk)
Step 5: Calculate Risk Scores
Aggregate vulnerability data into component and overall risk scores:
Risk Score Calculation:
━━━━━━━━━━━━━━━━━━━━━━
Component Risk = max(CVSS scores of all CVEs affecting the component)
Weighted Risk = Component Risk * Dependency Factor
where Dependency Factor = 1.0 + (0.1 * in_degree)
(more dependents = higher organizational impact)
Overall SBOM Risk = weighted average of all component risks
weighted by dependency centrality
Risk Levels:
CRITICAL: CVSS >= 9.0 or known exploited (CISA KEV)
HIGH: CVSS >= 7.0
MEDIUM: CVSS >= 4.0
LOW: CVSS < 4.0
Step 6: Cross-Validate with Grype
Use grype to independently scan the SBOM and compare findings:
Grype pulls vulnerability data from NVD, GitHub Security Advisories, Alpine SecDB, Red Hat, Debian, Ubuntu, Amazon Linux, and Oracle security databases, providing broader coverage than NVD alone.
Step 7: Generate Compliance Report
Produce a structured report suitable for regulatory compliance:
grype (Anchore): Vulnerability scanner that accepts SBOMs as input and correlates against multiple advisory databases
cyclonedx-python-lib: Python library for creating, parsing, and validating CycloneDX SBOMs programmatically
lib4sbom: Python library for parsing both SPDX and CycloneDX format SBOMs
nvdlib: Python wrapper for the NVD 2.0 API supporting CVE and CPE queries with rate limit management
OWASP Dependency-Track: Platform for continuous SBOM analysis, vulnerability tracking, and policy enforcement
Common Scenarios
Scenario: Assessing Vendor Software After Log4Shell Disclosure
Context: After the Log4Shell (CVE-2021-44228) disclosure, the security team needs to determine which vendor-supplied applications contain vulnerable versions of log4j. Several vendors have provided SBOMs per contractual requirements.
Approach:
Collect all vendor SBOMs (CycloneDX or SPDX JSON format)
Parse each SBOM and search for log4j-core components with versions < 2.17.1
Query NVD API for the specific CVEs (CVE-2021-44228, CVE-2021-45046, CVE-2021-45105)
Build dependency graphs to identify which application components depend on log4j
Calculate blast radius: how many services and endpoints are exposed
Generate prioritized remediation report sorted by exposure and business criticality
Cross-validate findings with grype scan of the same SBOMs
Pitfalls:
Vendor SBOMs may be incomplete, missing shaded/bundled JAR files that embed log4j
SPDX and CycloneDX version differences may affect parser compatibility
NVD API rate limits can slow analysis when scanning hundreds of components without an API key
CPE names in SBOMs may not exactly match NVD entries, requiring fuzzy matching
Transitive dependencies may include log4j even when it is not a direct dependency
