Use when a team needs SBOMs for compliance (US EO 14028, EU CRA, FDA), SBOM-based vulnerability scanning or drift checks between releases. Generates CycloneDX or SPDX SBOMs with Syft from images or folders, scans them with Grype, diffs SBOMs in CI and explains how to choose a format.
90%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Low
Low-risk findings worth noting
Extended reference for the SPDX chapter of sbom-formats.md (see spdx.md). See spdx.dev/specifications for the source spec.
SPDX 3.0 (2024 release) restructures into composable profiles:
| Profile | Use |
|---|---|
core | Minimum BOM model |
software | Software-specific extensions (approx. SPDX 2.3 packages) |
licensing | License identification + expressions |
security | Vulnerability + VEX statements |
ai | AI/ML models, datasets, hyperparameters |
dataset | Dataset-specific metadata |
build | Build provenance (similar to in-toto attestations) |
JSON-LD is the primary encoding; tooling support is growing but less mature than 2.3 as of 2026. For most teams, stay on SPDX 2.3 unless 3.0 features are required - 2.3 has broader tooling.
| Tool | Use |
|---|---|
syft | Generates SPDX 2.3 (JSON / Tag-Value); cross-source |
spdx-tools | Reference impl (Python); validation + conversion |
spdx-tools-java | Java reference impl |
ORT (OSS Review Toolkit) | License compliance scanning + SPDX reporting |
spdx-sbom-generator | Per-language native generation |
tern | Container image SPDX generation |
Trivy | Cross-purpose scanner with SPDX output |