SBOM für Docker- und Container-Images nach dem CRA
Auf dieser Seite
Der Cyber Resilience Act verlangt von jedem Hersteller eine Software-Stückliste in einem gängigen, maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene des Produkts erfasst (Anhang I Teil II Nummer 1). Wenn Sie Ihre Software als Container-Image liefern, ist das Image das, was der Kunde ausführt. Alles darin gehört zu dem, was Sie in Verkehr bringen: Ihr Code und seine Bibliotheken, aber auch die Betriebssystempakete des Basis-Images, die Laufzeitumgebung der Sprache und jedes unterwegs hineinkopierte Binary.
Zur Verordnung selbst siehe SBOM für den Cyber Resilience Act.
Wann das Image zum Produkt gehört
- Sie liefern das Image an Kunden, die es auf eigenen Servern oder Clustern betreiben (selbst gehostete Software, eine On-Premises-Edition, eine Appliance, ein Helm-Chart, das Ihre Images zieht). Das Image ist das Produkt oder ein Teil davon, und seine SBOM muss alles abdecken.
- Sie betreiben das Image selbst, um einen Dienst zu erbringen. Reines SaaS fällt grundsätzlich nicht unter den CRA, es sei denn, es ist die Datenfernverarbeitung eines Produkts (siehe Der CRA und SaaS). Die SBOM des Images bleibt gute Praxis, ist aber kein CRA-Dokument.
- Ein Gerät führt Container aus. Auf einem Gateway oder einem Industrie-PC gehören die Images zur Firmware und damit in die SBOM des Geräts.
Zwei SBOMs, und warum Sie beide wollen
Eine Quell-SBOM, aus Ihren Lock-Dateien erstellt (siehe die Anleitungen für npm, Python, Java, Rust, Go und .NET), kennt Ihre direkten Abhängigkeiten und den Abhängigkeitsgraphen. Das Basis-Image kennt sie nicht.
Eine Image-SBOM, durch Scannen des fertigen Images erstellt, sieht, was tatsächlich installiert ist: Debian-, Alpine- oder Red-Hat-Pakete, die Python- oder Java-Laufzeit, Sprachpakete aus ihren installierten Metadaten, Go-Binaries aus ihren Build-Informationen. Sie weiß nicht, welche davon Ihr Code angefordert hat, und kann übersehen, was keine Metadaten hinterlässt, etwa eine aus dem Quelltext kompilierte C-Bibliothek oder ein im Dockerfile mit curl heruntergeladenes Binary.
Bewahren Sie für jede Version beide auf. Die Image-SBOM beantwortet „steckt dieses verwundbare OpenSSL in dem, was wir ausliefern?“; die Quell-SBOM beantwortet „gehört es zu uns, und warum ist es da?“.
Die Image-SBOM erzeugen
Syft von Anchore scannt ein Image aus einer Registry, dem lokalen Docker-Daemon oder einem Archiv:
syft registry.example.com/acme/gateway:2.4.0 -o cyclonedx-json=sbom.cdx.json
Trivy von Aqua Security tut dasselbe:
trivy image --format cyclonedx --output sbom.cdx.json registry.example.com/acme/gateway:2.4.0
Oder lassen Sie BuildKit die SBOM während des Builds schreiben und als Attestierung an das Image hängen (SPDX, erzeugt von einem Syft-basierten Scanner):
docker buildx build --sbom=true -t registry.example.com/acme/gateway:2.4.0 --push .
Attestierungen brauchen einen Builder, der sie unterstützt (den Treiber docker-container oder den containerd-Image-Store von Docker). Sie reisen mit dem Image in der Registry, und docker buildx imagetools inspect liest sie wieder aus. Für eine einfache SPDX-Datei, wie andere Werkzeuge sie erwarten:
docker buildx imagetools inspect registry.example.com/acme/gateway:2.4.0 --format '{{ json .SBOM.SPDX }}' > sbom.spdx.json
Welches Werkzeug Sie auch wählen: Beschreiben Sie genau das Image, das Sie freigeben, über seinen Digest, nicht über ein Tag, das später auf ein anderes Image zeigen wird.
Basis-Images und was sie mitbringen
- Jedes Paket im Basis-Image müssen Sie behandeln. Eine Debian-Basis bringt rund hundert Pakete mit, von denen Ihre Anwendung die meisten nie nutzt. Jedes kann eine Schwachstelle tragen, und viele Scanner melden sie gegen Ihr Produkt.
- Kleiner ist einfacher. Distroless-, Chainguard- und Alpine-Images oder
scratchfür statische Binaries enthalten weit weniger Komponenten, also weniger zu bewertende Schwachstellen und weniger Fragen von Kunden. - Regelmäßig neu bauen. Ein Basis-Image-Tag wie
debian:12-slimerhält Korrekturen; Ihr Image nicht, bis Sie es neu bauen. Bauen Sie nach Zeitplan neu, und wenn eine ausgenutzte Schwachstelle das Basis-Image betrifft, nicht nur, wenn sich Ihr Code ändert. - Pinnen Sie das Basis-Image über seinen Digest im Dockerfile, damit jede SBOM dem entspricht, was gebaut wurde.
- Multi-Stage-Builds helfen. Compiler und Build-Werkzeuge bleiben in der Build-Stufe und erreichen weder das finale Image noch seine SBOM.
Von der SBOM zu den Schwachstellen
Grype liest die SBOMs von Syft, und trivy sbom sbom.cdx.json prüft eine gespeicherte SBOM gegen die heutigen Sicherheitshinweise, ohne das Image erneut zu ziehen. Rechnen Sie mit vielen Befunden zu OS-Paketen, die Ihre Anwendung nie aufruft. Schauen Sie zuerst auf die in freier Wildbahn ausgenutzten Schwachstellen, die die Meldeuhr starten können, und halten Sie in einer VEX-Aussage fest, warum die übrigen das Produkt nicht betreffen. Auch Distributionen veröffentlichen eigene Bewertungen, etwa die Entscheidungen „nicht betroffen“ oder „wird nicht behoben“ von Debian und Red Hat; es lohnt sich, sie zu prüfen, bevor Sie Ihre eigene schreiben.
Wie Provetry hilft
Laden Sie die SBOM des Images von Syft, Trivy oder BuildKit hoch (CycloneDX- oder SPDX-JSON, SPDX 3 eingeschlossen; bei BuildKit die wie oben extrahierte Datei), oder lassen Sie den CI-Schritt von Provetry das Image selbst lesen (seine Eingabe image nimmt einen Image-Namen oder ein docker save-Archiv; provetry sbom gateway.tar macht dasselbe lokal): Debian-, Ubuntu- und Alpine-Pakete mit ihrer Distributionsversion, Wolfi- und Chainguard-Pakete, opkg-Pakete sowie die im Image installierten Python- und Node.js-Pakete. RPM-basierte Images werden noch nicht gelesen: Die SBOM vermerkt das. Syft und Trivy listen deren RPM-Pakete auf (mit image-tool: syft nutzt der CI-Schritt Syft), doch Provetry gleicht RPM-Pakete noch nicht ab, ebenso wenig opkg-Pakete und Pakete einer Distributionsversion, die keine öffentliche Advisory-Datenbank abdeckt (Debian testing, Alpine edge); eine abgeleitete Distribution wie Raspberry Pi OS wird nur näherungsweise abgeglichen, als die Version, der sie folgt. Die Version zeigt an, welche Komponenten nicht überwacht werden. Eine Version enthält eine SBOM: Beschreibt sie das Image, deckt sie auch die darin installierten Sprachpakete ab, die Erreichbarkeitsanalyse entfällt dann aber, also bewahren Sie die SBOM Ihrer Lock-Dateien bei Ihren Build-Artefakten auf. Provetry bewahrt die SBOM jeder Version auf, überwacht jede Komponente, die es abgleichen kann, OS-Pakete eingeschlossen, auf neue und ausgenutzte Schwachstellen, täglich in den kostenpflichtigen Tarifen und wöchentlich im kostenlosen, und weist in den Tarifen Pro und Consultant, sobald Sie das Ende Ihres Unterstützungszeitraums im Profil des Produkts eintragen, auf Komponenten hin, deren Support vor Ihrem endet, soweit endoflife.date sie kennt (vor allem Laufzeitumgebungen, Frameworks und Datenbanken). Seine Erreichbarkeitsanalyse liest Quellcode und deckt daher die anderen Binaries in einem Image nicht ab: Für diese wird Ihre eigene Bewertung als VEX-Aussage festgehalten.