The call comes in late from a threat-intel feed: a library is being exploited in the wild. Before any paperwork starts, somebody has to say whether that library sits inside the firmware image currently shipping on a product sold in the EU, and at which version. Under the CRA the relevant product can be the entire finished good [7], so that answer has to hold across proprietary code, supplier applications, commercial packages, microcontroller software and open-source libraries, with dependencies running several tiers down [5].
That is the work the deadline actually schedules. The Hacker News analysis, as summarised by TNW, puts the hard cases exactly there: companies that cannot quickly establish which software is present in a particular product, or when a vulnerability first became known [11]. The first notice is due in 24 hours and the fuller report in 72 [1][2], which leaves 48 hours for detail and none at all for the lookup [20].
The diagnosis and the product being sold arrive together here, so they are worth separating. FossID sells software composition analysis, and its chief growth officer Aaron Branson says an SBOM is only as useful as the confidence an organisation can place in the information inside it [13], with that confidence requiring an extra layer of examination where supplier information enters the enterprise [14]. The diagnosis stands on its own evidence: supplier files land in different formats and at different levels of detail, and the pile gets harder to reconcile once the underlying software changes after the document was produced [10]. The remedy carries a precondition the article does not test. Scanning finds components, fragments and dependencies that declared package data misses [15], and it does that by reading code. The same article describes manufacturers as maintaining many supplier relationships while having limited insight into the software embedded in individual components [6]. For a signed image from a tier-two supplier, the verification layer is a contract negotiation before it is a scan.
Teams often assume the SBOM programme answers the question, but it typically produces only a record of what a supplier said at a moment in time, while releases, patches, dependency changes and newly identified components move the product underneath it [12]. TNW's framing is that source-code analysis turns SBOM documents into reliable supply-chain intelligence [18]; the operation underneath that phrase is checking whether a document matches a build [16].
The grid worth drawing has coverage on one axis and verification against the shipped artifact on the other. Documented and verified is the only quadrant where a 24-hour notice is a lookup. Undocumented and unverified is at least honest about itself, and it will show up as a missed window. The expensive quadrant is documented and unverified, because the answer goes to the regulator fast and confidently from a record that stopped matching the binary two releases ago.
The cheapest test of where a given product line sits is to take one SKU shipping into the EU, pick a component that never appears in a slide, and measure how long it takes to name its version and the shipped build containing it. Longer than a working day reveals a verification-speed problem hiding behind what looks, on September 11, like a documentation deadline.
