# SBOM checklist for SMEs (A1.6)

What to capture in a Software Bill of Materials, and when. An SBOM supports transparency and traceability for products using FOSS components, and SBOM practices can be adopted progressively.

## What to capture — Minimum

- [ ] Product name + version (release identifier)
- [ ] Component name + version
- [ ] Direct and transitive dependencies (as available)
- [ ] License information (where feasible)
- [ ] Unique identifiers (when available, e.g., package URL / hashes)

## When to generate or update the SBOM

Minimum:

- [ ] For major releases (e.g., version 1.0, 1.1, 2.0)

Recommended:

- [ ] For every release that changes dependencies

Always update when:

- [ ] A security patch requires a dependency upgrade
- [ ] A critical / high exposure component changes version
- [ ] A vulnerability remediation is implemented

## SBOM maturity levels

### Level 1 — Foundational

- Structured dependency list
- Major release updates
- Linked to release documentation

### Level 2 — Structured

- Automated SBOM generation (where possible)
- Direct + transitive dependencies
- License capture
- SBOM stored with release artifacts

### Level 3 — Advanced

- CI/CD-integrated SBOM generation
- Continuous dependency monitoring
- Hash verification
- Historical SBOM version tracking
- Rapid impact analysis for CVEs

---

_Based on OCCTET deliverable D2.3 – CRA Adoption Best Practice Document (v1.0, March 2026), licensed under CC BY 4.0._

<https://occtet.eu/best-practices/checklists-and-templates/>