It's 2 AM and a critical CVE just dropped. Which of your releases ship the affected library?

It's November 2025, and the Shai-Hulud 2.0 worm has just backdoored 796 npm packages across 1,092 versions. May 2026 brings the "Mini" wave with 170+ more. I tracked those malicious packages and faced the only question leadership asks in these moments: are we shipping any of these and where? For most organizations that have spent two years diligently generating SBOMs, the answer still involves grepping a bucket of JSON files and frantically asking around on Slack.

The uncomfortable truth: SBOM generation is a solved problem, but SBOM queryability across hundreds of products and thousands of releases is not. With the EU CRA and CERT-In's SBOM guidance making coverage table stakes, the real work now is consuming SBOMs under incident pressure. Coverage without queryability is compliance theater.

This talk walks through the four queries every incident-response team needs when the clock is ticking, in escalating order of difficulty:

1. Single-package lookup: "Which releases ship log4j-core 2.x?" Sounds simple; PURL normalization and version-range matching make it harder than it looks.

2. Batch lookup: Shai-Hulud's advisory listed ~800 packages, each with specific malicious versions. You can't run 800 manual searches at 2 AM.

3. Bundle propagation: if the vulnerable library sits three levels deep, does your query surface the top-level product the customer actually received?

4. Historical: what did we ship to customer X in March, not just what's deployed today?

For each query: why file-per-SBOM blob storage fails, and what your storage layer needs instead - normalized component stores, PURL indexing, release-to-BOM binding, clear product/component hierarchies.

Live demo on ReARM, a FOSS (AGPL-3.0) release governance platform: paste a PURL, get every affected release across a multi-component portfolio in seconds. Queries 1 and 3 run live; 2 and 4 via prepared walkthrough to respect time. The concepts are tool-agnostic; ReARM is the vehicle because it's browsable OSS.

Takeaway: a checklist to assess whether your org could answer the 2 AM question today.

A practical checklist to assess whether your org can answer "which releases ship the affected package, and where?" today

The storage-layer blueprint that makes SBOM portfolios queryable: PURL indexing, release-to-BOM binding, product/component hierarchies

How to handle batch advisories (hundreds of packages at once) and transitive bundled exposure not just single-CVE lookups

A browsable FOSS codebase implementing all four query types