# SBOMit: Making SBOMs Accurate With Attestations (Marco De Vincenzi & Justin Cappos, NYU) > [!info] Ported from an existing 18-section deep-read (Reader doc `01kze55zdxrbb1asp0hhx7tcpn`). Claims below trace to the talk transcript; only `> [!quote]` text is verbatim. > [!question] Lingering Questions > - What is the ground truth for validating SBOMit's extra detections? The talk shows disagreement, not accuracy — "+23 packages" could be genuine finds or build-environment noise. > - What's the source for the cited 95% (academic) and 30% (practitioner) SBOM-inaccuracy figures? Neither is cited. > - Does build-time observation even apply to interpreted ecosystems like PHP/WordPress, which have no compile step to observe? > [!tip] Article Ideas > - Pair with Sustain 292 (Harbuz's compiled-dependency blind-spot finding) — problem and tooling answer, two independent sources, one article. > - "Your SBOM is probably wrong, and now that's a €15M problem" — CRA penalty framing as the forcing function. > [!link] Cross Reference > - [[3. Resources/Permanent Notes/Auditing the Build Not the Install Is What Makes Personal-Scale Coverage Possible]] — already cites SBOMit as a build-is-the-unit-of-truth companion finding > - [[3. Resources/Permanent Notes/Perm · WordPress security is now a supply-chain + dependency risk, not just plugin reviews]] — WordPress has no SBOM story for the plugin/theme directories at all > [!quote] Vocabulary > - **SBOM** — Software Bill of Materials, the "ingredients label" for a software artifact > - **in-toto attestation** — a CNCF-graduated supply-chain evidence format; "a picture of something," contrasted with an SBOM's "ingredient label" > - **eBPF / ptrace** — two syscall-observation mechanisms; eBPF costs ~12% build overhead vs. ptrace's ~600% ## Corpus thesis (as reported) Today's SBOMs are structurally wrong because both common generation methods — scanning a finished artifact and reading a manifest — measure the wrong moment. Post-build scanning infers; manifests record intent. Only observing the build itself, via kernel-level syscall capture, records fact. SBOMit implements this as a build-time "camera" (Witness, via eBPF/ptrace) that produces in-toto attestations and corrects existing scanner output. ## Key arguments (≤3) 1. **The pie analogy**: an SBOM is an ingredients label, and there are three moments to write it — after baking (smell it, i.e. post-build scanning), from the recipe (manifests, which miss what's already in the kitchen and what got borrowed mid-bake), or while it's baking (build-time observation, the only accurate moment). 2. **Regulatory stakes are now real**: the EU Cyber Resilience Act penalizes inaccurate SBOMs at €15M or 2.5% of global turnover, whichever is greater — reframing SBOM accuracy from hygiene to legal exposure. 3. **The evidence gap**: SBOMit demonstrates that Syft and Trivy disagree with each other and that SBOMit finds more packages (+23 on one Go project, +7 on a Python project) — but "more" is never validated as "more accurate" against any ground truth. ## Claim atoms ### Only build-time observation records what a build actually consumed > [!quote] ID:rw_sbomit_01 > this is like labeling a pie after you've baked it based on smelling the pie Where/why: the talk's core structural argument. Post-build scanning infers; manifests describe intent; build-time syscall observation is the only moment ground truth is available, because the OS's response to a file request IS what the build consumed. ### Manifests miss what was already present and what arrived mid-build Where/why: lock/requirements files are "a shopping list" — they omit dependencies already in the build environment (already-in-the-kitchen) and anything fetched during the build (borrowed-mid-bake). Directly corroborates a separate source's finding (Harbuz, Sustain 292) that compiled/binary dependencies never appear in manifests. ### More detections is not the same as more accurate > [!quote] ID:rw_sbomit_02 > we're the camera and you know, we don't have a real opinion of what we've taken a picture of Where/why: SBOMit's demos show +23 and +7 packages over base scanners with zero ground-truth validation, while the presenters concede build-only tooling (test files, transient build dependencies) also gets captured. The accuracy claim is plausible from the structural argument but not demonstrated by the evidence shown. ### eBPF costs ~12% build overhead vs. ptrace's ~600% Where/why: both methods agree on results, so the choice between them is purely a performance question — the one genuinely quantified engineering tradeoff in the talk, against a ~74-second median clean build. ## Permanent candidates - Already captured (linked, not duplicated): the build-is-ground-truth principle extends [[3. Resources/Permanent Notes/Auditing the Build Not the Install Is What Makes Personal-Scale Coverage Possible]], which already cites SBOMit directly. - New candidate created this pass: the "more detections ≠ more accurate" evidentiary gap, generalized past this specific talk. ## Processing checklist - [ ] Verify the 95%/30% inaccuracy figures against a primary source before citing further - [ ] Ground-truth validation of SBOMit's extra detections remains an open question — track if a hand-audited corpus is ever published - [x] Connect into [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] and [[3. Resources/MOCs/Open Source Governance MOC]] ## Links - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] — WordPress has no SBOM/build-provenance story for plugins/themes; this talk describes the shape of what one would look like - [[3. Resources/MOCs/Open Source Governance MOC]] — CRA compliance is a coming governance question for any commercial open-source ecosystem, WordPress included - [[3. Resources/Readwise/Articles/SBOMit Making SBOMs Accurate With Attestations - Marco De Vincenzi & Justin Cappos, NYU]] - [[3. Resources/Literature Notes/What's in Your AI — The Case for AI Bills of Materials (Alan Friedman, RSAC)]] — because applies-in: attestation is how a BOM references an evaluation without embedding it, which is precisely the line Friedman draws against assessment-creep in AI BOMs.