Your SBOM estate holds device-supplier documents of wildly different ages. How do queries expose staleness?
answer
- documents age against your deploys
- three timestamps, only one is freshness
- version mismatch beats document age
- absent is not the same as stale
- answers carry an as-of and coverage
basics
~20 sAn inventory document goes stale relative to what you deploy, not with age alone. Compare each record's subject version against the running version, date claims by the producer's stated creation time rather than your ingestion time, and keep no-record distinct from mismatched.
solid answer
~40 sModel three distinct states and never let a query flatten them. First, **no record**: nothing has ever been ingested for that fleet, so silence is ignorance. Second, **version mismatch**: you hold an accurate document for release 4.1 while the fleet now runs 4.3 — the document is not wrong, it simply describes something you no longer run, and that is the dominant staleness case. Third, **aged record**: the subject matches but the document was produced long ago and may since have been revised. Keep the producer's stated creation time separate from your ingestion time, because ingesting a fourteen-month-old file today does not make it fresh. Then have every answer carry its evidence: which fleets matched, which had no record, which records describe a version other than the deployed one.
go deeper
Recall that an inventory document describes one specific version of one artifact, so it stops being useful when you deploy a different version. Know that having no document at all is different from having an old one.
Explain the three timestamps an ingestion pipeline sees and why only the producer's stated creation time measures the age of a claim. Be able to describe subject drift versus document age.
Show that you shape the answer, not just the store: matched, clean, version-mismatch and no-record as separate buckets, and every result reported with its coverage. Explain how you make supplier silence a detectable state.
Be ready to defend what you will and will not assert externally from a partially covered estate, and to decide where investment goes first: broadening coverage or refreshing what you already hold.
## Staleness is relative, not absolute The common mental model — 'documents expire after N months' — is wrong, and getting it right is what separates a senior answer here. An inventory document is a statement about **one specific artifact version**. A document describing release 4.1 of an infusion-pump gateway is exactly as accurate today as it was on the day it was written. It becomes useless the moment the fleet is upgraded to 4.3, and it was already useless if you never ran 4.1. So staleness in an estate is really two different measurements: 1. **Subject drift** — does the record's subject match the artifact version actually deployed? This is the dominant case and the one that silently produces wrong answers, because the query returns rows and looks healthy. 2. **Document age** — for a record whose subject *does* match, how long ago did the producer make the claim? This matters because producers revise documents about an unchanged release, typically after discovering an omission. ## Three timestamps, and only one of them is freshness An ingestion pipeline sees at least three times, and conflating them is the classic estate bug: - **The producer's stated creation time**, carried inside the document. This is the age of the claim. - **Your ingestion time.** This is when you learned it. Ingesting a fourteen-month-old file this morning makes the *row* new and the *claim* old; a dashboard sorted on ingestion time will show a green wall over an estate that knows nothing current. - **The deployment time of the artifact the record is about.** This is what subject drift is measured against. Store all three. Display the first. Never sort freshness by the second. ## Absent, stale and clean are three answers, not one Consider a hospital group ingesting documents from forty medical-device suppliers, each on its own rhythm — some per release, some annually, some only when asked. The freshest document held for one infusion fleet is fourteen months old, and the estate has no way to say whether that is because nothing has changed or because nobody has sent anything. A query for a component then returns a list that looks authoritative and quietly excludes that fleet. The fix is at the level of the answer's shape. A component query should return, at minimum: | Bucket | Meaning | What it licenses you to say | |---|---|---| | matched | a current record for the deployed version lists the component | 'we run it here' | | clean | a current record for the deployed version does not list it | 'evidence says no, for this fleet' | | version-mismatch | a record exists, but for a version other than the one deployed | 'we do not know for what is running' | | no record | nothing ingested for this fleet at all | 'we have no evidence either way' | The last two buckets are the answer's real risk surface, and they are exactly what a bare list deletes. ## Making silence detectable An estate should be able to represent an **expectation** as well as an observation: for each supplier or product line, when did you last receive anything, and how does that compare with their historical rhythm? That turns 'no document since last spring' from an absence you have to notice into a state the store can report. It is a modelling point, not a contractual one — the estate's job is to make silence visible, so that whoever owns the relationship can act on it. The same applies internally. If your own build pipelines are the producer, a fleet whose newest record predates its newest deployment is telling you a pipeline stopped emitting, and that is a monitoring signal in its own right. ## Reporting the answer honestly The practical discipline is that every answer travels with an **as-of and a coverage note**. 'Sixteen services match, out of 900 workloads, of which 42 have no current record and 60 have records describing a version we no longer run.' That sentence is longer than an executive wants and shorter than the retraction that follows a confident 'we are not affected' issued from an estate that had never heard of a third of the estate. One last trap: a record older than an advisory is not automatically obsolete. If the deployed version has not changed, an old document about that version remains the best evidence you have. Age is a prompt to check, not a verdict — subject drift is the verdict.
- Why is ingestion time a misleading freshness signal?It records when you learned something, not when the claim was made. Bulk-loading a backlog of year-old documents makes every row look new, so a dashboard sorted on ingestion time shows a healthy estate that knows nothing current. Store the producer's stated creation time and report freshness from that.
- A record is two years old but the deployed version has not changed. Is it stale?Not in the sense that matters. It still describes exactly what is running, so it remains the best evidence you have. Age is a prompt to check whether the producer has revised the document, not a verdict that the contents are wrong.
- How do you keep the version-mismatch bucket from quietly growing?Drive it from deployment events: when an artifact version appears in an environment with no matching record, the estate should register a gap immediately rather than waiting for a query to expose it. That turns mismatch from something you discover during an incident into a tracked, visible backlog.
A building plan for the third floor stays perfectly correct forever. It becomes dangerous the day someone renovates the third floor and nobody redraws it.
saying these in an interview costs you the question
- Treats ingestion time as the document's freshness
- Says documents simply expire after a fixed period
- Cannot distinguish no record from an aged record
- Returns a bare list with no as-of or coverage
- Assumes supplier silence means nothing has changed