LOADING STUDY MODULE
000%
> initializing core modules ...... OK
> mounting dependency graph ..... OK
> validating signatures ......... OK
> connecting to vulnerability db OK
> loading leaf-vein renderer .... OK
SBOM.STUDY // FIELD MANUAL v3.14.7 00:00:00
STUDY TERMINAL ACTIVE

sbom.study

Field manual for software bill of materials — cadet training module

CLEARANCE: STUDENT // SECTOR: SUPPLY-CHAIN-7 // STATUS: NOMINAL
// SECTION 01

Core Study Modules

6 modules · ~45 min study time
M-01 Dependency Trees ACTIVE

An SBOM is a nested inventory. Direct dependencies sit at the top of the tree, transitive ones fan out beneath them, and every branch is a potential ingress point. Studying the shape of the tree is the first step in understanding what your software actually is.

  • Direct deps are declared; transitive deps are inherited.
  • Depth matters — deep trees conceal risk.
  • Every node needs a name, version, and hash.
0
avg deps per project
M-02 Vulnerability Mapping ACTIVE

With an SBOM in hand, a single CVE lookup can surface every asset affected by a new disclosure. Without one, the same lookup becomes an archaeological expedition across build systems, dockerfiles, and tribal knowledge.

  • Match components to the CVE feed continuously.
  • Track remediation windows by severity.
  • Record exploitability, not just presence.
0
cves published last year
M-03 License Inventory ACTIVE

Every component carries a license, and every license carries obligations. An SBOM makes license compliance a query instead of a quest — you can answer "does our product ship GPL code?" in seconds.

  • Permissive, copyleft, proprietary — know the mix.
  • Flag license changes across versions.
  • Reconcile with your distribution policy.
0
osi-approved licenses
M-04 v Version Pinning ACTIVE

"Latest" is a moving target. An SBOM captures the exact versions — not ranges — that shipped in a given build. Pinning turns reproducibility from an aspiration into a receipt.

  • Semver is a promise, not a guarantee.
  • Hashes defeat typosquatting.
  • Reproducible builds need reproducible inputs.
0
avg versions per month
M-05 Supply Chain Integrity CRITICAL

The software supply chain is only as strong as its weakest signed commit. SBOMs transform opaque build pipelines into auditable provenance records: who built what, from which source, on which machine, and which artifacts were produced as a result. Combined with attestations (SLSA, in-toto), an SBOM becomes the ledger of trust that lets a defender answer "how do I know this binary is what you say it is?"

SOURCE
git-verified commit at HEAD
BUILD
hermetic · reproducible
ARTIFACT
sha256 · signed
DEPLOY
policy-gated release
0
supply-chain attacks 2023
0
percent preventable w/ sbom
M-06 Compliance Formats ACTIVE

SPDX and CycloneDX are the two dominant SBOM formats. Both capture components, relationships, and metadata; both are machine-readable; both are necessary reading for the informed student. Learn one deeply, then learn to translate.

  • SPDX — governance-first, ISO-standardized.
  • CycloneDX — security-first, lightweight.
  • Both render as JSON, XML, and tag-value.
0
standards to master
// SECTION 02

Ecosystem Diagram

leaf-vein projection · live nutrient flow
midrib · root project
secondary vein · direct dep
tertiary vein · transitive dep
nutrient flow · update signal
root tip
Each vein is a dependency path. Nutrients flow from root to tip, the way a security advisory propagates through a tree of imports. Watch the flow: that is what your CI pipeline should feel like.
// SECTION 03

Study Summary

key takeaways · committed to memory

Inventory is knowledge

You cannot secure what you cannot name. An SBOM is the roll call.

0% coverage goal

Formats converge

SPDX and CycloneDX overlap more than they diverge. Learn the concepts once.

0% shared fields

Freshness matters

A stale SBOM is a lie told about yesterday. Generate on every build.

0hours max drift

Provenance is power

Pair your SBOM with signed attestations. Ledger plus proof equals trust.

0layers of proof