intermediate 2 min answer

Your pipeline now generates an SBOM for every build. A critical vulnerability is announced in a transitive dependency. Can you answer the question that matters?

sbomvulnerabilityresponse
Show the full answer Hide the answer

What the interviewer is testing

Whether you know that generating SBOMs and being able to use them are different capabilities — the gap most organisations have.

The question that matters

"Which of our services ship this library, at what version, which are internet-facing, and which handle regulated data?" — answered in minutes, not a fortnight.

Why generation alone does not answer it

An SBOM sitting beside its artifact answers a question about one build. The query you need is across every version currently deployed, which requires:

Central storage and indexing. SBOMs collected into a queryable store, keyed by artifact digest.

A link to what is deployed. The store must know which digests are running where, which means a runtime inventory feeding it — otherwise you can answer "which builds contained this" and not "which running systems contain this", and only the second matters.

Context per service: internet exposure, data classification, owner. Without it you get a list of 400 services with no way to prioritise, which is only marginally better than not knowing.

Two further gaps to name

Generated at build, from the resolved dependency graph. An SBOM produced by scanning a manifest afterwards lists declared ranges rather than what was actually resolved, and the version that matters is the resolved one.

Presence is not exploitability. An SBOM tells you the library is included, not whether the vulnerable code path is reachable, whether the affected function is called, or whether the configuration exposes it. Vulnerability counts drawn from SBOMs consistently overstate real risk, and teams that treat every finding as urgent exhaust their capacity on the majority that are not. Reachability analysis is what turns the list into a work queue.

What a strong answer adds

The response playbook, which is what makes this operational: query the store, rank by exposure and data sensitivity, identify the fixed version, use fleet-wide automated dependency updates to raise pull requests across affected repositories, and track remediation to closure with an SLA per severity tier.

And note the second-order benefit: the same infrastructure answers licence compliance questions, which is usually what funds it.

Common weak answers

Treating SBOM generation as the deliverable. Assuming the security scanner's dashboard covers this — it typically covers what it scanned, not what is deployed.