Container-Scanning: Funktionsweise und was es nicht sieht

So funktioniert Container-Scanning

Das Image entpacken. Der Scanner liest die Layer des Images, ohne sie auszuführen.
Den Inhalt auflisten. Er liest die Paketdatenbanken des Betriebssystems und Anwendungsmanifeste, etwa eine in das Image kopierte package-lock.json.
Die Daten abgleichen. Er vergleicht Pakete mit Schwachstellendaten von Distributionen und aus Advisory-Datenbanken.
Die Konfiguration prüfen. Manche Tools markieren außerdem Dinge wie die Ausführung als root oder in einem Layer zurückgelassene Secrets.

Wo ein Scan laufen sollte

Stufe	Was er bringt	Grenze
CI, nach dem Image-Build	Lässt den Build fehlschlagen, bevor ein Image gepusht wird	Eine Momentaufnahme der Advisories dieses Tages
Registry	Scannt gespeicherte Images erneut, sobald neue Advisories erscheinen	Findet Probleme erst, nachdem das Image veröffentlicht wurde
Kubernetes-Admission	Blockiert ungescannte oder durchgefallene Images beim Deployment	Braucht eine Policy und einen Umgang mit Ausnahmen
Laufzeit	Zeigt, welche Images gerade laufen und was geladen ist	Braucht einen Agenten auf Ihren Clustern

Tools für Container-Scanning

Open Source: Trivy und Grype sind die gängigen kostenlosen Optionen, und beide lassen sich leicht ins CI einbinden.
In Registries und Plattformen integriert: Docker Scout und die großen Cloud-Registries bieten Scanning an.
Kommerzielle Plattformen: Snyk und Anchore ergänzen Policy, Reporting und Workflows.

So reduzieren Sie die Befunde

Beginnen Sie mit einem kleineren Basis-Image. Slim- oder Distroless-Images enthalten weniger Pakete, sodass weniger Advisories zutreffen.
Bauen Sie regelmäßig neu. Basis-Images werden gepatcht, und ein Image, das im März sauber war, ist es jetzt nicht mehr.
Nutzen Sie Multi-Stage-Builds. Compiler und Build-Tools sollten nicht im finalen Image landen.
Pinnen Sie Basis-Images per Digest. Ein Tag kann sich unbemerkt ändern, ein Digest nicht.
Priorisieren Sie. Für viele Befunde gibt es noch keinen Fix, oder sie liegen in Paketen, die Ihre Anwendung nie nutzt. Siehe so priorisieren Sie Schwachstellen.

Was ein Container-Scan nicht sehen kann

Kompilierten Code. Ein Go- oder Rust-Binary im Image trägt nur begrenzt Metadaten, und ein Scanner muss herleiten, was eingeflossen ist.
Dateien ohne Paketeintrag. Software, die mit curl hinzugefügt oder in einen Layer kopiert wurde, hat keinen Eintrag in einer Paketdatenbank.
Was der Build genutzt und zurückgelassen hat. Multi-Stage-Builds verwerfen die Tools, die das Image erzeugt haben. Wurde eines davon kompromittiert, deutet im finalen Image nichts darauf hin.
Woher es stammt. Ein Scan beschreibt das Image, nicht den Build, der es erzeugt hat.

Genauer lesen Sie das unter was eine Docker-Image-SBOM übersieht, und die Optionen finden Sie unter die besten SBOM-Tools.

Images scannen und Builds aufzeichnen

Scanner sind das richtige Tool für Images, die Sie nicht selbst gebaut haben, sowie für Cluster und Konfiguration. Bei Images, die Sie selbst bauen, geht CRACI einen anderen Weg. Als Ihr GitHub-Actions-Runner sieht es, was in den Build hineinkommt, einschließlich des Basis-Images und seiner Betriebssystem-Layer. So zeichnet es auf, was eingeflossen ist, statt es nachträglich herzuleiten. Anschließend prüft es diese SBOMs laufend weiter, sobald neue Schwachstellen veröffentlicht werden.

CRACI scannt keine Images, die Sie nicht selbst gebaut haben, keine Cluster, keine VM-Images und keine Fehlkonfigurationen. Trivy schon, behalten Sie es also dafür. Siehe CRACI vs. Trivy.

Container-Scanning: häufig gestellte Fragen

Was ist Container-Scanning?

Dabei wird ein Container-Image auf bekannte Schwachstellen, veraltete Pakete und riskante Konfiguration untersucht, meist ohne es auszuführen.

Wann sollten Sie Container-Images scannen?

Im CI nach dem Image-Build und erneut in der Registry, sobald neue Advisories erscheinen. Ein einmaliger Scan hinterlässt nur eine Momentaufnahme, die schnell veraltet.

Was ist der beste kostenlose Container-Scanner?

Trivy und Grype sind die am weitesten verbreiteten kostenlosen Optionen. Beide laufen im CI und decken Betriebssystem- und Anwendungspakete ab.

Was ist der Unterschied zwischen Image-Scanning und einer SBOM?

Eine SBOM listet auf, was in einem Image steckt, während ein Scan diesen Inhalt auf bekannte Probleme prüft. Viele Scanner erstellen zuerst eine SBOM und gleichen sie dann mit Advisories ab.

Warum hat mein Container-Image so viele Schwachstellen?

Vor allem wegen des Basis-Images, das die Pakete eines Betriebssystems mitbringt. Ein kleineres Basis-Image und regelmäßige Rebuilds beseitigen die meisten davon.

Kann ein Container-Scanner kompilierte Binaries lesen?

Teilweise. Go- und Rust-Binaries können einige Abhängigkeits-Metadaten tragen, aber viel kompilierter Code gibt einem Scanner wenig Anhaltspunkte, sodass er herleiten muss, was eingeflossen ist.