Vom SBOM zum Sicherheits-Gate: Syft und Grype in der MSP-CI-Pipeline

Managed Service Provider, die CI-Pipelines für Kunden betreiben, können zwei Open-Source-Tools von Anchore, Syft und Grype, zu einem einzigen Software-Supply-Chain-Gate kombinieren: Syft katalogisiert jedes Paket eines Builds in einer Software-Stückliste (SBOM), und Grype prüft dieses Inventar auf bekannte Schwachstellen, bevor der Build freigegeben wird. Dieser Leitfaden erklärt, was jedes Tool leistet, wie beide zusammenwirken und wo die Kombination allein nicht ausreicht.

Zuerst das Inventar erstellen, mit Syft

Syft, von Anchore unter der Apache-2.0-Lizenz gepflegt, erzeugt aus Container-Images, Dateisystemen und Paketen eine SBOM im SPDX- oder CycloneDX-Format. Anchore veröffentlichte syft v1.52.0 am 17. September und behob dabei zwei Cataloger-Fehler, die ungenaue Inventare erzeugt hatten: Der RPM-Datenbank-Cataloger meldete bei einem einlagigen Rocky-Linux-10-Image eine veraltete Bibliotheksversion, und der Java-Archiv-Cataloger lieferte für Uber-Jars eine unbekannte Version. Das Release bringt zudem Abhängigkeitspflege mit: 52 Änderungen an Abhängigkeiten beheben sechs bekannte Schwachstellen, darunter ein Update der Bibliothek grpc-go, das mehrere veröffentlichte Advisories schließt. Die Cataloger-Korrekturen sind besonders für Teams relevant, die auf RPM-basierten Images oder Java-Uber-Jars setzen, da eine veraltete oder unbekannte Version im SBOM sonst verdecken würde, was ein nachgelagerter Scanner tatsächlich prüft.

Grype macht aus dem Inventar ein Gate

Grype, ebenfalls von Anchore gepflegt, durchsucht Container-Images, Dateisysteme und SBOMs nach bekannten Schwachstellen. Am 23. September 2026 zeigte das GitHub-Repository rund 12.900 Sterne und einen Commit von zwei Tagen zuvor, was auf aktive Pflege hindeutet. Direkt nach der SBOM-Erstellung in eine CI-Pipeline eingebunden, lässt Grype einen Build automatisch fehlschlagen, sobald eine bekannte CVE auftaucht, statt sich darauf zu verlassen, dass jemand später daran denkt zu prüfen. Der übliche Ablauf erzeugt das SBOM während des Builds, meist mit Syft, und führt Grype anschließend gegen dieses SBOM aus, optional auch direkt gegen das gebaute Image, um jede gelistete Komponente mit bekannten Schwachstellendaten abzugleichen. Ein Schweregrad-Schwellenwert entscheidet, ob der Job fehlschlägt: Alles darüber blockiert den Merge, sofern keine benannte, befristete Ausnahme dokumentiert ist.

Ausnahmen sichtbar machen, nicht stillschweigend

Ein fail-closed-Gate ist nur nützlich, wenn Ausnahmen sichtbar sind und einen Verantwortlichen haben. Ohne einen schriftlichen Ausnahmeprozess schalten Teams das Gate entweder beim ersten dringenden Blockadefall ab, oder es sammeln sich stille Umgehungen an, die den Sinn der Prüfung zunichtemachen. Eine Ausnahme sollte einen Verantwortlichen, einen Grund und ein Ablaufdatum nennen, nach dem der Befund neu bewertet wird, statt unbefristet zu gelten.

Was das Gate nicht leistet

Grype zeigt, was in einer bevorstehenden Auslieferung bekanntermaßen verwundbar ist; es installiert keine Patches, erzwingt keine minimalen Berechtigungen und ersetzt kein Laufzeit-Monitoring nach der Bereitstellung einer Workload. Zudem hängt es von der Aktualität seiner Schwachstellendatenbank ab, sodass ein veralteter Feed den Zweck des Scanners untergräbt. Bei der Standardisierung über mehrere Kunden-Pipelines hinweg empfiehlt es sich, Schweregrad-Schwellenwerte zunächst in einer Nicht-Produktionspipeline zu testen, da ein zu aggressiver Schwellenwert Teams nur dazu bringt, das Gate zu umgehen. Die Archivierung jedes SBOM zusammen mit dem zugehörigen Build-Artefakt macht aus demselben Inventar zusätzlich ein Nachweispaket für Kunden oder Versicherer, ohne zusätzlichen Scan-Aufwand. Für externe Unterstützung bei Penetrationstests, Schwachstellenbewertungen, Incident Response oder NIS2-/DORA-/DSGVO-Konformität stehen die Cybersecurity-Services von Altovar zur Verfügung.

Was zu tun ist

• Syft als Build-Schritt ergänzen, der für jedes Image oder Artefakt ein SPDX- oder CycloneDX-SBOM ausgibt, und den Build fehlschlagen lassen, wenn die Erstellung einen Fehler wirft.
• Grype direkt danach gegen dieses SBOM ausführen, optional auch gegen das gebaute Image, mit einem Schweregrad-Schwellenwert, der zuvor in einer Nicht-Produktionspipeline getestet wurde.
• Den Ausnahmeprozess festlegen, bevor das Gate live geht: wer eine Ausnahme gewähren darf, was dokumentiert werden muss und wann sie abläuft.
• Jedes SBOM zusammen mit seinem Build-Artefakt archivieren, damit es später als Nachweispaket für Kunden oder Versicherer dienen kann.
• Die Schwachstellendatenbank von Grype aktuell halten; ein veralteter Feed lässt Builds durch, die das Gate eigentlich hätte blockieren sollen.
• Das Gate mit Patch-Management und Laufzeit-Monitoring kombinieren, da keines der beiden Tools abdeckt, was nach der Bereitstellung passiert.

Quellen: Grype auf GitHub, anchore/syft-Releases.