A vendor's SBOM for a payment terminal image lists 41 components; your own inspection of that image finds around 300. What do you do?

## Why the number is not the finding 41 against 300 looks damning, and candidates who lead with "their document is wrong" have skipped the two checks that decide the case. Two inventories of the same product routinely differ by an order of magnitude for entirely legitimate reasons, and the reviewer's job is to find out *which* differences are legitimate before escalating anything. ## Step one: are these even the same artefact? An inventory is a statement about a specific thing. The first question is whether the document identifies its subject by content digest, and whether that digest is the image you inspected. If the document names a tag rather than a digest, or names a version string with no digest at all, you may be comparing this month's build against last quarter's — and a tag is a mutable name, not a pin. This check is cheap and it resolves a meaningful share of these disputes without anyone being at fault. ## Step two: what does the document say it covers? Many supplier inventories are deliberately narrower than the artefact. Common declared scopes: - Application components only, base operating system explicitly excluded. - Runtime dependencies only, with build and test dependencies out of scope. - The vendor's own code and its direct suppliers, with the platform treated as the customer's responsibility. A stated exclusion is a **scope decision**, not a defect. It may still be an unacceptable scope for your purposes, which is a different conversation, but it is not evidence of a broken process. What you are hunting for is the gap that is *undeclared* — the components the document neither lists nor admits to omitting. ## Step three: bucket the difference Walk the 259 extras and sort them. The buckets carry different meanings: | Bucket | Reading | |---|---| | Base-layer OS packages | Usually the bulk of the delta; benign if declared out of scope, serious if not | | Build-only or test-only components present in the image | Both an inventory question and a hardening question — why are they shipped at all? | | Vendored or statically linked code | The hardest class: real code with no package identity, so it appears in neither view reliably | | Duplicate entries and different naming for the same component | Not a gap at all; an artefact of how you counted | That last row matters: your own count of ~300 is also a claim, produced by a method with its own blind spots, and part of the reconciliation is finding out that a chunk of the difference is you double-counting. ## Step four: decide what it means for this product Context decides the severity. This is a payment terminal: an attacker can be someone standing in front of the device with physical access and time, and money is the asset. The excluded base layer — the TLS stack, the card-reader drivers, the update client — is exactly what such an attacker probes, and exactly what an advisory will land on. So a scope that stops at the vendor's application code, however honestly declared, does not cover the risk you are carrying. Contrast that with a back-office batch service on an internal network, where the same scope might be perfectly adequate. ## Step five: what you actually change - **Adopt your own derived inventory as the operational one** for vulnerability triage on this device. Do not run response off a document you have just proved is a subset. - **Record the vendor document as a claim, not an inventory** — it is still evidence about what the vendor believes it shipped, which has value when the two disagree later. - **Raise the undeclared portion as the finding.** "Your document omits 200 base-layer packages and does not state that the base layer is out of scope" is a specific, fixable observation. "You listed 41 and we found 300" invites an argument about counting methods. - **Ask for a declared known unknown** where enumeration is genuinely impractical. "The base layer is not enumerated in this document" is worth far more to a consumer than silence, because it converts an invisible gap into a bounded one you can plan around. ## The judgement being tested The interviewer is watching for three things: that you reconcile the subject before the contents, that you can tell a scope decision from a defect, and that you translate the delta into consequence for *this* product's threat picture rather than into an abstract complaint about document quality. The weak answer is a count-based escalation; the strong answer ends with a specific undeclared gap, a decision about which inventory you will operate from, and a reason grounded in what an attacker can reach.