Your SBOM Is Fan Fiction

Build-time SBOMs report what was installed, not what a running system actually has loaded: deleted-but-still-mapped libraries, hand-deployed binaries, dlopened plugins, or statically linked code can all be absent from manifest-based inventories. The kernel keeps accurate receipts in /proc (exe, maps, fd, net, cgroup), but parsing that data is messy, kernel-dialect dependent, and risky to run directly in a page. The described approach builds a runtime bill of materials by exposing /proc and related sources through a GraphQL sys_graph, performing the heavy /proc walk inside a Worker isolate so the UI never blocks, and restricting any host-level operations to three explicit airlocked functions (enrich, advisories, hostIdentity). Isolates cannot open files or make network requests, which prevents scanners from exfiltrating data.

Runtime inspection goes further: a symbol Inspector opens ELF objects to check whether advisory-named functions are actually present in mapped binaries, correlating CVE feeds to memory. On real machines this uncovered multiple high-severity advisories, processes holding patched-but-not-restarted libraries, and statically linked OpenSSL inside Node binaries that package databases don’t attribute to any package. A hub manifest aggregates per-node inventories into a fleet view. The upshot is that build SBOMs remain useful recordkeeping, but only a kernel-driven runtime BOM shows true exposure and drives actionable remediation.