# Sbom Generation

> Use when you need a complete inventory of what's inside a build — every dependency and its version — as an SBOM you can scan, track, and hand to auditors.

- Skill: `jihedbfr-art/sbom-generation` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add jihedbfr-art/sbom-generation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jihedbfr-art/sbom-generation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: jihedbfr-art (https://skillmd.com/u/jihedbfr-art)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/jihedbfr-art/sbom-generation

---




## Prerequisites
- Target system, dependencies and environment configured.

## Usage
### Purpose

You can't defend a supply chain you can't enumerate. A Software Bill of Materials is the ingredient list — every component, version, and licence in an artifact — in a standard format. When the next Log4Shell drops, an SBOM answers "are we affected, and where" in seconds instead of a frantic week. This skill covers generating one and putting it to use.

### When to use it

Generate an SBOM as a build output for anything you ship or run: application artifacts, container images, releases. It underpins vulnerability triage, licence compliance, and incident response, so it's the foundation for most of this domain.

### Procedure

1. Generate the SBOM from the artifact. Syft reads a container image, directory, or archive and lists everything it finds:
   ```
   syft myapp:latest -o cyclonedx-json > sbom.json
   ```
   Prefer a standard format — **CycloneDX** or **SPDX** — so other tools can consume it.
2. Generate it from the **built artifact**, not just the source manifest. A lockfile lists declared deps; scanning the built image/binary captures what actually shipped, including transitive and system packages.
3. Store the SBOM as a versioned build artifact, tied to the exact release it describes. An SBOM that doesn't match a specific build is worthless during an incident.
4. Feed it to a scanner to turn the inventory into a risk view — the SBOM says what's there, the scanner says what's vulnerable:
   ```
   trivy sbom sbom.json
   ```
5. Diff SBOMs across releases to see what changed — a new dependency appearing is a supply-chain event worth noticing.
6. When a new critical CVE lands, query your stored SBOMs for the affected component instead of re-scanning everything from scratch.

### Cheatsheet

```bash
syft myapp:latest -o cyclonedx-json > sbom.json
syft dir:. -o spdx-json > sbom.spdx.json

trivy image --format cyclonedx -o sbom.json myapp:latest

trivy sbom sbom.json
grype sbom:sbom.json

grep -i 'log4j' sbom.json
```

### Reading the output

- **The component count and depth** — a huge transitive tree is a large attack surface; it's worth knowing before an incident, not during one.
- **Unexpected components** you didn't knowingly pull in are the supply-chain signal — a package appearing that no one added deserves a look.
- **Version accuracy** matters most: the SBOM's value is answering "which version of X shipped", so verify it reflects the built artifact, not a stale manifest.
- **Licences** in the SBOM surface compliance risk (a copyleft dependency in a proprietary product) alongside the security view.

### How to make it useful (the "fix")

An SBOM is only worth generating if it's used:

- **Automate it in CI** as a build artifact for every release, in a standard format (CycloneDX/SPDX).
- **Store and index** SBOMs so you can query across your whole estate when a CVE drops — that fast lookup is the entire payoff.
- **Scan continuously**, not once — the inventory is static, but new vulnerabilities against those components appear over time.
- **Diff releases** to catch new or changed dependencies early.
- Combine with signing/provenance (later skills in this domain) so you can also trust the SBOM reflects a build nobody tampered with.

### Pitfalls

- **Generating from source manifests only.** Misses transitive and OS-level components that the built artifact actually contains.
- **A one-off SBOM.** Generated once and never regenerated, it drifts from reality and misleads during an incident.
- **SBOM without scanning.** An inventory nobody checks against vulnerability data is a document, not a control.
- **No version linkage.** An SBOM not tied to a specific build can't answer the one question you'll ask it under pressure.

### References

- CycloneDX and SPDX specifications
- Syft, Trivy, and Grype documentation
- CISA — Software Bill of Materials guidance
- NTIA — Minimum Elements for an SBOM

## Inputs
- Relevant source code, logs, network traces, or system specifications.

## Outputs
- Analysis findings, security audit report, or generated code artifacts.