The art of knowing what your software is made of
very piece of software is an assembly of countless parts. Open-source libraries, proprietary modules, runtime dependencies, build tools -- hundreds of components woven together into a single functioning whole. An SBOM is the manifest: the complete inventory of every component, every dependency, every origin.
Like a medieval scribe documenting the provenance of each pigment in an illuminated manuscript -- where the lapis lazuli was mined, who ground the gold leaf, which monastery supplied the vellum -- an SBOM traces the lineage of software back to its atomic components.
This is not bureaucracy. This is the ancient practice of knowing what you are made of.
The lineage of borrowed code. Every library your software consumes is a dependency -- a relationship of trust between your project and another's work. Dependencies form a tree that branches deeper than most developers realize: your ten direct dependencies may import a hundred more, each carrying its own history, its own maintainers, its own quiet vulnerabilities.
express@4.18.2 // lodash@4.17.21 // react@18.2.0The covenants that govern usage. Each component carries a license -- a set of permissions, conditions, and limitations written by humans for humans. MIT, Apache, GPL, BSD: these are not mere acronyms but social contracts, each encoding a different philosophy about how code should be shared, attributed, and protected.
MIT // Apache-2.0 // GPL-3.0-only // BSD-2-ClauseThe known weaknesses, the cautionary tales. Every component may harbor vulnerabilities -- flaws in logic, memory, or trust that can be exploited by those who know where to look. An SBOM does not prevent vulnerabilities, but it illuminates them. It transforms the unknown threat into the named adversary.
CVE-2021-44228 // severity: critical // package: log4j-coreKnow your software. Trust your supply chain.
sbom.day
2026