From SBOM to vulnerability gate: Syft and Grype in MSP CI pipelines

Managed service providers running CI pipelines for customers can combine two open-source Anchore tools, Syft and Grype, into a single software-supply-chain gate: Syft catalogs every package in a build as a software bill of materials, and Grype checks that inventory against known vulnerabilities before the build is allowed to pass. This guide covers what each tool does, how they fit together, and where the combination stops short of full protection.

Generate the inventory first, with Syft

Syft, maintained by Anchore under an Apache-2.0 license, generates an SPDX or CycloneDX software bill of materials from container images, filesystems and packages. Anchore shipped syft v1.52.0 on 17 September, fixing two cataloger bugs that had been producing inaccurate inventories: the RPM database cataloger was reporting a stale library version from a single-layer Rocky Linux 10 image, and the Java archive cataloger was returning an unknown version for uber-jars. The release also carries dependency maintenance: 52 dependency changes remediating six known vulnerabilities, including an update to the grpc-go library that closed several published advisories. The cataloger fixes matter most for teams relying on RPM-based images or Java uber-jars, where a stale or unknown version in the SBOM would otherwise mask what a downstream scanner is actually checking.

Grype turns the inventory into a gate

Grype, also maintained by Anchore, scans container images, filesystems and SBOMs for known vulnerabilities. As of 23 September 2026, its GitHub repository showed roughly 12,900 stars and a commit from two days earlier, which points to active maintenance. Wired into a CI pipeline right after SBOM generation, Grype lets a provider fail a build automatically when a known CVE shows up, instead of relying on someone remembering to check later. The standard flow generates the SBOM during the build, commonly with Syft, then runs Grype against that SBOM and, optionally, against the built image directly, checking every listed component against known-vulnerability data. A severity threshold decides whether the job fails: anything above it blocks the merge unless a named, time-boxed exception is on record.

Make exceptions visible, not silent

A fail-closed gate is only useful if exceptions are visible and owned. Without a written exception process, teams either turn the gate off the first time it blocks something urgent, or accumulate silent overrides that erase the point of scanning in the first place. An exception should name an owner, a reason and an expiry date after which the finding is re-evaluated, not waived indefinitely.

What the gate does not do

Grype tells a team what is known to be vulnerable in what it is about to ship; it does not patch anything, enforce least privilege, or replace runtime monitoring once a workload is deployed. It also depends on the freshness of its vulnerability database, so pinning the scanner to a stale feed defeats the purpose. For MSPs standardizing this across customer pipelines, the practical move is to test severity thresholds in a non-production pipeline first, since a threshold set too aggressively will simply train teams to route around the gate. Archiving each SBOM alongside its build artifact also turns the same inventory into a customer- or insurer-facing evidence pack, at no extra scanning cost. Providers that need outside help with penetration testing, vulnerability assessment, incident response or NIS2/DORA/GDPR compliance work can bring in Altovar's cybersecurity services.

What to do

• Add Syft as a build step that emits an SPDX or CycloneDX SBOM for every image or artifact, and fail the build if generation errors out.
• Run Grype against that SBOM, and optionally the built image, immediately afterward, with a severity threshold tuned first in a non-production pipeline.
• Write the exception process down before the gate goes live: who can grant one, what it must record, and when it expires.
• Archive each SBOM with its build artifact so it can support a customer- or insurer-facing evidence pack later.
• Keep Grype's vulnerability database current; a stale feed lets the gate pass builds it should have blocked.
• Pair the gate with patching and runtime monitoring, since neither tool covers what happens after deployment.

Sources: Grype on GitHub, anchore/syft releases.