The three way check compares the declared inventory (manifests and lockfiles), the built inventory (what the build produced) and the running inventory (what production actually executes). Where the three agree, trust is high. Where they differ, find out why before relying on any of them.
Three views of one product
Each view answers a different question.
| View | Source | Answers |
|---|---|---|
| Declared | Manifests, lockfiles | What did developers ask for? |
| Built | Image or package scan, build output | What was assembled? |
| Running | Deployed workloads, runtime inventory | What is live right now? |
The NTIA minimum elements report notes that an SBOM must be refreshed when a new build or release changes the software, which is why the built view matters: it is the one tied to a specific release.
How to run it
- Pick one production service.
- Take the lockfile from the commit that was deployed.
- Take the built artifact for that commit and generate its inventory.
- Take the image or package that is running and read its digest.
- Confirm the digest matches the built artifact. If not, stop: the running software is not what the repository says.
- Diff the three lists.
Reading the differences
- Declared and built differ. The build pulled in layers, tools or unlocked versions. Common cause: operating system packages and unpinned build steps.
- Built and running differ. Someone deployed something other than the build record, or configuration downloads code at start. Serious: ask for the deployment history.
- All three agree. Good. You still need to check scope, since agreement among three incomplete views is still incomplete.
Typical causes and fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| Many OS packages in built, none in declared | Base image | Inventory images, update the base |
| Newer versions in built than declared | Version ranges, no lockfile | Commit lockfile |
| Running image has no matching build | Manual deploy or old artifact | Rebuild and redeploy from source |
| Extra package at runtime | Plugin download at startup | Bake it into the build or inventory it |
How long it takes
One service takes an hour or two once access exists. Do three or four services of different types rather than all of them. If the same cause shows up each time, you have found a process gap and can describe it in one line.
Why this is a good diligence question
It tests the seller's release process without asking for opinions. A team that can show matching digests, tied to a commit, has a controlled path from code to production. A team that cannot has an undocumented one, and the inventory inherits that uncertainty.
Safeguard's continuous monitoring keeps rescanning after the first review, so the running view does not go stale. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how findings change over time without a new build.
Quick check
What is a digest?
A content hash of a container image. Two images with the same digest are byte identical, which is how you prove the running image is the one that was built.
Sources
Last reviewed: 19 October 2026.
