What is SBOM
A Software Bill of Materials is an inventory. Like the ingredients list on the side of a cereal box, but for software. Every library, every framework, every dependency — catalogued, versioned, accounted for.
In an age where a single application may contain thousands of components written by hundreds of authors across dozens of countries, knowing what you have is no longer optional. It is the foundation of trust.
Component Registry
Format: SPDX 2.3 / CycloneDX 1.5
Coverage: direct + transitive dependencies
Update frequency: per-build
Anatomy
An SBOM contains metadata about each component: its name, version, supplier, unique identifier, and the relationships between components. Think of it as a genealogy chart for code.
Each node is a decision someone made. Each edge is a trust relationship. The tree is only as strong as its weakest branch.
Practice
Creating an SBOM is not a single act but a discipline. Like maintaining a library card catalog, it requires attention at every acquisition, every update, every retirement.
Generation
Integrate SBOM generation into your CI/CD pipeline. Every build produces a fresh inventory. Automation removes the temptation to skip.
Analysis
Cross-reference your SBOM against vulnerability databases. What you don't know about your dependencies can hurt your users.
Sharing
Transparency requires distribution. An SBOM locked in a drawer serves no one. Publish, share, and normalize the practice of openness.
Culture
Software transparency is not merely a technical practice. It is a cultural value. The decision to document what your software contains is a decision to respect the people who use it.
We believe that documentation is craftsmanship. That every catalogued component is an act of care. That the field guide approach — patient, thorough, beautiful — is the right way to approach the work of knowing what we build.