An SBOM-Based Image Admission Gate with Syft and Grype

The most common reflex in container security is to run an image through a vulnerability scanner before pushing it to the registry, and to halt the release if there are critical findings. This baseline approach is necessary but not sufficient on its own. Because most teams actually decide based on a momentary CVE output without knowing which components their image is carrying. An SBOM-based admission gate, on the other hand, places the decision on more solid ground: first it makes the image’s content visible, then it applies the policy across the combination of inventory and vulnerabilities.

Why is a scan score alone not enough?

An image may look clean today and become risky tomorrow with a new CVE. Also, the same image may carry unnecessary shell tools, forgotten language runtimes, or packages banned organization-wide. These do not always reflect directly in CVE scores. SBOM enables two things here:

• Recording the image’s content at the version level
• Being able to discuss policy violations beyond vulnerabilities

Syft offers practical tools to produce this inventory, and Grype is practical for matching this inventory and the image with vulnerability data.

How is the simple flow set up?

The leanest pipeline is made up of these steps:

1. Build the image
2. Produce an SBOM with Syft in SPDX or CycloneDX format
3. Scan the image or the produced SBOM with Grype
4. Interpret the output against a policy threshold
5. Sign the accepted image and push it to the registry

Sample Syft command:

syft registry.example.com/platform/api:1.4.2 -o cyclonedx-json > sbom.json

Then you can scan the same image or the file with Grype:

grype sbom:sbom.json --fail-on high

This command is only the starting point. The real value emerges when you tune the --fail-on level to your business context.

Don’t reduce policy to a CVE threshold

At the enterprise gate, the following rules give healthier outcomes:

• Zero tolerance for critical vulnerabilities in production images
• For high-severity vulnerabilities, passage only with an exception record
• Automatic rejection for unsupported base images
• Rejection for banned packages or shell tools
• Direct rejection for builds without an SBOM file

This way the admission gate stops being a reactive scanning step and becomes a supply chain control.

How does it tie into CI?

Whether GitHub Actions, GitLab CI, or your own Jenkins pipeline, the core logic is the same. After the build, first produce the SBOM, then scan, and finally store the result as an artifact. A simple example:

docker build -t app:${GIT_SHA} .
syft app:${GIT_SHA} -o spdx-json > artifacts/sbom.spdx.json
grype sbom:artifacts/sbom.spdx.json --fail-on high --output json > artifacts/grype.json

In the next step, you can interpret the JSON output against your policy file. For instance, you can ban specific package families, weight the CVE score by runtime profile, or apply a stricter threshold only on internet-facing services.

Which records should be kept?

In practice, storing the following artifacts makes a notable difference:

• The image digest
• The SBOM file
• The Grype report
• The accept or reject decision
• If there is an exception, the approval record and its expiration date

This way, three months later, you can give a defensible answer to the question “why did this image pass?”

Common mistake

The most common mistake is blocking all red findings instantly and breaking team trust in the system. If base images are already dirty at the start, the policy must not be hardened overnight. A better approach is to set up first visibility, then a mandatory threshold, and finally an exception management layer.

Conclusion

An SBOM-based image admission gate with Syft and Grype lifts container security out of the momentary scanning reflex and turns it into a repeatable supply chain control. When producing an SBOM, scanning for vulnerabilities, and evaluating the result against a recorded policy work together, both security quality rises and teams see more clearly why a given image passed. A strong gate is not the one that fires the most alarms; it is the one that produces the most consistent admission decision.