A vendor ships an appliance as an RPM under its own product name with no component list — what do you do?
answer
- only the vendor can name what is inside
- the fix is procurement, not scanning
- one opaque component, marked as unresolved
- zero findings is not zero risk
- tier the fight by what it holds
basics
~20 sYou cannot compute identity for someone else's build, so the levers are contractual: require a component-level SBOM and a product-keyed advisory channel as purchase terms. Until then, record one opaque component and spend on containment.
solid answer
~50 sRepackaging under a vendor's product name breaks identity in the one direction you cannot fix yourself: only the vendor knows what is inside, and no scan of their RPM reliably recovers it. So the response splits in two. Contractually, make a component-level SBOM a deliverable — supplier, component name, version and other unique identifiers per component, roughly the NTIA minimum-elements bar — and require a product-keyed advisory or VEX channel so the vendor states whether their build is affected. Renewal is the leverage, and obligations like the EU Cyber Resilience Act's on manufacturers make this a normal ask. Operationally, record the appliance as one opaque component with the vendor as supplier and an explicit identity-unresolved marker, then spend on containment: segmentation, scoped credentials for the customer data it holds, and a dated risk acceptance with an owner. Tier that effort by what the appliance holds.
go deeper
Know that a vendor-repackaged product hides its components behind a product name, and that the inventory entry should still exist with the vendor recorded as the supplier.
Explain why scanning the vendor package cannot reliably recover the component list, and what an SBOM from the vendor would have to contain to be useful: per-component supplier, name, version, identifiers and relationships.
Show the containment you run around a box you cannot inspect — segmentation, scoped credentials, independent logging — and how you keep the unresolved identity visible in reporting instead of letting zero findings read as safe.
Own the procurement position and the allocation behind it: which vendors get the hard conversation, what you ask for in contract terms, what residual risk you formally accept, and when the answer is to replace the product.
## Why this one is different Every other identity break in this area is something your own build did to itself and can therefore undo. This one is not. A vendor takes an upstream project, patches it, configures it, packages it under their product name, and ships you a binary. The mapping from their product to the components inside it exists only on their side. You can hash the package, you can note the vendor, the product and the version — and that is the end of what you can assert. Guessing at the upstream project from documentation or from strings in the binary produces confident wrong answers in both directions: claims about components that were replaced, and silence about components you never suspected. That makes this a governance problem wearing a technical costume, which is why the good answer is not a better scanner. ## Lever one: procurement The only durable fix is that the vendor tells you. Ask for it in terms that are specific enough to be testable: - **A component-level SBOM per shipped release**, machine-readable, with supplier name, component name, version and other unique identifiers per component plus the dependency relationships between them — the shape the NTIA minimum elements describe, together with the author and timestamp that make the document itself accountable. - **A product-keyed vulnerability channel.** You need statements about *their* build. A vendor who says "our product is not affected by that defect because the vulnerable code path is not built in" has answered a question you could never answer from outside, and a VEX statement of `not_affected` carries a justification precisely so the claim can be judged rather than trusted. - **A response commitment**: how quickly they will state a status after a defect is published, and how fixes are delivered. The leverage is renewal and initial purchase, not an incident. Regulation is moving in the same direction — the EU Cyber Resilience Act places obligations on manufacturers of products with digital elements, and US federal procurement has pushed SBOM expectations through EO 14028 — so this has stopped being an unusual demand. That matters for the negotiation: you are asking for what the market is converging on, not for a favour. ## Lever two: represent the gap honestly What you must not do is let the appliance vanish from the inventory because it produced no findings. Record it as a component with the vendor as supplier, its product name and version, a hash of what you were shipped, and an explicit marker that identity is unresolved below that boundary. Two things follow from writing it down: - **Zero findings stops reading as safety.** An opaque component with no findings and a fully inspected component with no findings look identical in a dashboard, and they are not remotely the same. The marker is what keeps the difference visible to whoever reads the report next. - **The residual risk becomes ownable.** An accepted-risk entry with a named owner and a review date is a decision. The same situation with no entry is a decision too, taken by nobody, revisited never. ## Lever three: spend on containment instead If you cannot see inside the box, reduce what the box can reach. For an appliance holding customer data, the controls that pay are the ones that do not depend on knowing its contents: network segmentation and egress restriction, credentials scoped to exactly the data it needs and rotated on a schedule you control, authentication in front of its management interface, logging of its access to the data store into somewhere the appliance itself cannot alter, and a tested answer to "what do we do if this product is compromised" that does not require the vendor's cooperation on the day. ## Deciding where to fight The principal-level judgment is allocation. An estate has many vendors and finite negotiating capital. Tier them by what the product holds and what it can reach: an appliance sitting on customer data with broad network access earns a hard contractual conversation and, if that fails, a replacement plan; a self-contained tool touching nothing sensitive earns an inventory entry and no further spend. Applying the same demand to every vendor exhausts the goodwill you need for the ones that matter, and applying it to none is how an unmatched component quietly becomes the least defended thing in the estate. The answer an interviewer is listening for has all three parts: the recognition that you cannot solve it technically, the specific thing you ask the vendor for, and the honest bookkeeping that keeps the gap visible while you wait.
- The vendor offers a top-level-only SBOM. Is that worth taking?Yes, but name what it does and does not do. A top-level list tells you which major components exist and gives you something to ask about; it does not cover transitive components, which is where most defects live. Take it, record the depth of the document as a property of the document, and keep the unresolved marker for everything beneath it rather than letting a partial list read as full coverage.
- How do you handle the vendor claiming their build is unaffected?Ask for the claim in a form that can be judged: which component and version their product contains, and why their build is not affected — the vulnerable code is not present, not built, not reachable in their configuration. A VEX not_affected status exists to carry exactly that justification. An unjustified assurance is not evidence, and you should record it as a vendor assertion rather than as a resolved finding.
- What do you tell your own customers when this appliance is in your data path?That you depend on a supplier whose composition you do not fully see, what compensating controls you run around it, and what you have contractually required of them. You inherit the supplier's opacity and you pass it on, so honesty here is also self-interest: a customer who learns it during an incident will treat the omission as the finding.
saying these in an interview costs you the question
- Assumes deep scanning of the vendor RPM recovers the components
- Guesses the upstream project from documentation and treats it as fact
- Drops the appliance from inventory because it produced no findings
- Treats an unjustified vendor assurance as evidence
- Applies the same contractual demand to every vendor regardless of exposure