Yes, if you can act on it. A gate that requires a signed SBOM or attestation proves that the artifact came with the claims your process produces. It does not prove those claims are complete or that the software is safe. Require presence first, then add checks on what the attestation says.
Definitions
An SBOM is a list of the components inside software. An attestation is a signed statement about an artifact, such as who built it or what it contains. A deploy gate is a check that runs before a workload is admitted, and refuses it if a rule fails.
Policy engines already support this idea. Kyverno's documentation describes verifyImages rules that check image signatures, and says that rules can check attestations too, with conditions applied to the JSON data inside an attestation. The attestors setting names who is trusted to have signed it.
What a presence check buys you
| Check | What it tells you | What it does not tell you |
|---|---|---|
| SBOM exists | The pipeline produced an inventory | That the inventory is complete or current |
| SBOM is signed by a trusted identity | It came from your pipeline | That the build itself was clean |
| SBOM is tied to the image digest | It describes this exact image | Whether listed components are vulnerable today |
| Attestation conditions pass | A specific claim holds, such as a scan result field | That the scan covered everything that matters |
An SBOM is a snapshot. A component list is only useful if you also compare it to advisories over time, which is a monitoring job, not a gate job.
Rolling the rule out
- Generate an SBOM in every build and attach it to the image by digest.
- Sign it with an identity tied to your pipeline.
- Add an audit mode rule at admission that reports images without a verified SBOM.
- Review the list. Common gaps are third party images, base images and old jobs.
- Decide an exception path for third party images, such as an internal mirror where you attach your own attestation after scanning.
- Move to enforce for production namespaces first.
What to check inside the attestation
Presence is the floor. Once it is stable, use conditions that matter to you:
- The SBOM timestamp is recent enough, so a stale list does not pass.
- The format is one your tools can read.
- A scan attestation shows no unaddressed findings above your threshold.
Keep conditions few and explainable. Every condition you add is one a developer must understand when it fails.
Pitfalls
Signing a wrong or empty SBOM gives false comfort. Spot check generated SBOMs against what is actually in the image. Also keep in mind that deploy time is late. Findings that appear here should already have been caught at pull request time, so use the gate as a backstop, not the first line.
Where Safeguard fits
Safeguard's SBOM and dependency scanning generates and reads component inventories, reachability analysis helps separate findings that matter from noise, and its policies and gates enforce your rules before release. A free scan shows what an inventory looks like for your project.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how direct and transitive components are listed.
Quick check
Does having an SBOM mean the image is safe?
No. It tells you what is inside. You still need to compare it with advisories and act on the results.
Where should the first SBOM check run?
In the pipeline, so developers see it early. The deploy gate is a backstop.
Sources
Last reviewed: 19 October 2026.
