Folio I · § 1
Of Manifests & the Catalogue of Components
A Software Bill of Materials — or SBOM, in the abbreviated tongue of practitioners — is, at its plainest, a manifest. It is the tally a craftsman might once have inscribed inside the rear cover of a leather-bound ledger, listing every plank, every nail, every brass fitting that constitutes the finished object. In our present age, the object is software, and the components are libraries, modules, and transitive dependencies, but the spirit of the inventory is unchanged: to know, with certainty, what one has built, and from what.
The motivation is older than the technology. Mediaeval scribes annotated their margins with provenance — this passage from Boethius, that gloss from Augustine — not from pedantry, but from the conviction that a text without lineage is a text one cannot defend. So too with software: a binary without an SBOM is a fortress whose gatekeepers have forgotten which stones came from which quarry, and which mason laid them.
Consider the modest application that, on its surface, performs a single function. Beneath that surface, modern tooling will reveal a forest: hundreds, sometimes thousands, of named packages, each with its own version, its own license, its own chain of authorship reaching back to volunteers in cities the original author has never visited. The SBOM is the cartographer's contribution to this terrain.
It enumerates each package@version with discipline. It records the SPDX license identifier, the cryptographic hash of the artefact, the upstream origin, and — where the format permits — the precise relationship: this component depends upon that one; that one was bundled at compile time; this one is invoked only when the optional plugin is loaded.
From this enumeration, three powers emerge. First, the power of recall: one may answer, in seconds, the question “does my product contain the offending library?” Second, the power of audit: one may demonstrate to a regulator, customer, or auditor, the lineage of every byte. Third, the power of repair: when a vulnerability is announced, one knows precisely where to apply the remedy.
“
To know one's components is to know one's exposure; to know one's exposure is the beginning of stewardship.
”
The reader unfamiliar with the form may ask: why now? The honest answer is that software has, in our generation, become infrastructure, and infrastructure must be accountable. A bridge is signed and stamped; a pharmaceutical lists its ingredients; a foodstuff declares its allergens. Software, until recently, declared nothing. The SBOM is the long-overdue correction.
Folio II · § 2
On Provenance, Signature, & the Chain of Trust
An inventory, however meticulously kept, is only as trustworthy as the hand that signed it. The mediaeval guild understood this. A barrel of wine bore the cooper's mark; a cloth, the weaver's selvage; a manuscript, the scribe's colophon. To know the maker is to know whom to commend, and whom, when the work is found wanting, to summon for explanation.
In the practice of SBOM, provenance is not metaphor but mathematics. The cryptographic signature — an ed25519 seal, a cosign attestation, an in-toto statement — binds the manifest to its origin with the same finality as a notary's wax. Tampering becomes detectable; substitution, declarable; silent corruption, archaeologically traceable.
¶ Cautionary Marginalia
A signature attests only to what the signer declared, never to what the signer could not see. An SBOM that omits a transitive dependency is signed faithfully and yet remains a partial truth. The discipline of completeness is the discipline that distinguishes the careful steward from the merely punctual one.
The chain of trust, then, is not a single seal but a series of seals, each verifying the previous: the source repository attests to the commit; the build system attests to the artefact produced from that commit; the publisher attests to the artefact distributed; the consumer verifies, at the moment of installation, that the seal received matches the seal expected. Where any link is forged or absent, the chain is broken, and the steward is bound to declare it so.
The reader will recognise here a pattern as old as accountancy: the doctrine of double-entry. Every component asserted on one side of the ledger must correspond to an artefact attested on the other. The SBOM, properly maintained, is the architecture's audit-book; the signature, its notary's seal; the verification routine, the inspector's quarterly visit.
Modern formats — SPDX 2.3, CycloneDX 1.5, the older SWID tags — differ in their dialects but agree in their substance. Each accommodates the full apparatus of provenance: the supplier, the originator, the download location, the checksum, the signature. Each, applied with rigour, suffices.
Folio III · § 3
Of Vulnerabilities & the Anatomy of Exposure
When a vulnerability is published — assigned its CVE identifier, its severity scored, its exploitability characterised — a great alarm rings, in our age, across the operations of every responsible institution. The question that follows is invariably the same, and invariably urgent: are we exposed?
Without an SBOM, this question is met with a forensic excavation: developers summoned, repositories grepped, build logs sifted. Hours pass. Sometimes days. Meanwhile the adversary, whose curiosity does not pause for office hours, advances. With an SBOM, the question is answered in the time it takes a machine to perform a lookup: yes, we ship version 1.4.2 of the affected library in three products, and we shipped them on these dates, to these customers.
Vulnerability
n. A weakness in a software component which, by intention or accident, may be exercised by an adversary to subvert the component's proper function. From the Latin vulnerare, to wound. The wound is in the code; the bleeding, in the systems that run it.
The taxonomy of exposure has its own bestiary. There is the direct dependency, vulnerable in the very package one chose to install. There is the transitive dependency, vulnerable in something one's chosen package quietly bundled. There is the build-time dependency, present in the kitchen but not the meal. There is the optional dependency, lurking in the cellar, summoned only when a particular feature is enabled. Each demands a different remedy, and the SBOM is the index that makes the distinction legible.
A complementary instrument has emerged, called VEX — Vulnerability Exploitability eXchange — which permits the steward to declare, with respect to a given vulnerability, whether the affected code is actually reachable in the steward's deployment. A library may be present and the function never invoked; the wound is dressed before it bleeds. VEX is the marginal annotation to the SBOM's principal text: a refinement, a clarification, a courtesy to the reader.
Folio IV · § 4
A Glossary of Standards & Customary Terms
The reader who has come this far deserves a lexicon — not exhaustive, for exhaustion is the enemy of the encyclopaedist's craft, but sufficient to permit further independent reading. What follows is a register of terms one will encounter in the principal documents of the field, set down in the manner of a scholarly glossary.
SPDX- The Software Package Data Exchange, an open specification, stewarded by the Linux Foundation, for expressing the full apparatus of an SBOM in machine-readable form. Now in its 2.3 revision, with a 3.0 revision in advanced gestation. Its strength is exactness; its dialect, formal.
CycloneDX- A complementary specification, born of the OWASP project, with strong affinities for security tooling. Where SPDX is the registrar's instrument, CycloneDX is the watchman's. Both are widely supported and mutually translatable.
PURL- The Package URL, a compact expression of the form
pkg:type/namespace/name@version, designed to identify a component unambiguously across registries and ecosystems. The lingua franca of cross-format reference.
CPE- The Common Platform Enumeration, an older naming scheme maintained by NIST. Cumbersome, but indispensable for reconciliation with the National Vulnerability Database.
VEX- The Vulnerability Exploitability eXchange. An attestation, attached to or referenced from an SBOM, declaring whether a known vulnerability is in fact exploitable in a given deployment. The marginalia of the security ledger.
in-toto- A framework for end-to-end attestation of the software supply chain, permitting cryptographic verification of every step from source to artefact. The notary's complete book.
¶
Thus concludes the principal exposition. The diligent reader is encouraged to consult the cross-references in the margin, to follow the footnotes to their attendant glosses, and to return to these folios as questions arise. Knowledge, like the manuscripts that preserved it, is best kept by being often consulted.
Set in Libre Baskerville & Playfair Display.
Bound in Mahogany & Parchment.
❧ sbom.wiki ❧