# Software Bill of Materials A software bill of materials (SBOM) is a structured inventory of software components and their relationships. ## Role in the archive An SBOM strengthens [[Software Supply-Chain Provenance]] by preserving component names, versions, suppliers, dependency relationships, and identifiers alongside package hashes, signers, installation source, and timestamp. ## Evidentiary boundary An SBOM is a declaration, not proof that the running system exactly matches it. Correlate it with signed artifacts, package inventories, build records, vulnerability data, and runtime observation. ## Sources - [[Index - Stages of Interception#Stage 8 — Package, signing, and distribution authority|Stage 8]]. - CISA, “Minimum Elements for a Software Bill of Materials”: https://www.cisa.gov/sites/default/files/2025-08/2025_CISA_SBOM_Minimum_Elements.pdf ## Scanned_20260730-1806 overlay [[Scanned_20260730-1806|Scanned_20260730-1806]] documents a manual precursor to an SBOM. Pages 3 and 18 recover Dagger and JSR 305/GWT attribution from packaged resources; pages 19 and 23–27 connect tools and packages to developer handles, repositories, forks, domains, manifests, privileges, and carrier/ROM lineages. The missing decisive fields are artifact hash, signer, exact version, dependency version, installer, install path, requested and granted permissions, native ABI, target SDK, and comparison against a known-good firmware inventory. ## Scanned_20260730-1230 hardware analogy The notebook's pasted labels form a hardware-side analogue to an SBOM: finished product → model → processor/GPU/memory/storage → OEM/ODM → battery or adapter → PCB/revision → regulatory identity. Examples include the Qisda/Dell display relationship, BYD/LG battery relationship, and component codes for the Mackie Onyx Blackjack. This analogy does not turn a label collection into a complete hardware bill of materials. Subcomponent part numbers, revisions, supplier lots, firmware, replacements, and custody remain incomplete. See [[Hardware Provenance]] and [[Software Supply-Chain Provenance]]. ## Scanned_20260730-1946 overlay PDF pages 2 and 7 manually reconstruct transitive software dependencies across compression, graphics, desktop sessions, audio, documents, and interprocess messaging. PDF page 20 explicitly returns to XZ/Tukaani alongside installer, firmware, and hardware-description formats. The notebook performs SBOM-like reasoning before naming the method. The 2024 XZ backdoor clarifies the strategic importance of obscure foundational dependencies but is hindsight, not a prediction. A defensible SBOM still requires exact versions, hashes, source/build provenance, signatures, and capture time.