Container-Images scannen
kunnus sbom container erzeugt eine SBOM für ein Container-Image und hält für jede Komponente fest, welcher Image-Layer sie eingebracht hat. Alias: kunnus sbom image.
kunnus sbom container alpine:3.20 --output alpine.cdx.json # Registry-Pull
kunnus sbom container ./image.tar --output image.cdx.json # docker save / OCI-Tarball
kunnus sbom container myapp:dev --source docker # lokaler Docker-DaemonImage-Quellen
--source steuert, woher das Image kommt: auto (Standard — kunnus entscheidet anhand des Arguments), remote (Registry-Pull), tarball (docker-save- oder OCI-Archiv auf der Platte) oder docker (der lokale Daemon). Ein Tarball-Scan ist vollständig offline; eine Remote-Referenz ist der einzige Fall, in dem dieser Modus das Netzwerk nutzt.
Layer-Zuordnung
Jede Komponente trägt kunnus:layer:*-Properties: Index und DiffID des einbringenden Layers, die Dockerfile-Anweisung, die diesen Layer erzeugt hat, und ob er zu einem erkannten Base-Image gehört. Ein Paket in mehreren Layern listet alle auf. Das beantwortet die zwei Fragen, die Auditoren tatsächlich stellen: kam das aus unserem Build oder aus dem Base-Image — und welcher Build-Schritt hat es hinzugefügt?
Was Container-Scans erfassen
Container-Scans führen die Installed-State-Extraktoren aus — OS-Pakete jeder unterstützten Linux-Familie, installierte Sprachpakete (Wheels, Gems, JARs, node_modules, Go-/.NET-Binaries) und den Klassifikator für nicht-paketierte Binaries. Reine Deklarationsdateien wie ein zurückgebliebenes package.json gelten bewusst nicht als installierte Software. Die Kernel-Extraktoren sind Host-only und laufen hier nie: Ein Container nutzt den Kernel des Hosts — ihn in dessen SBOM zu behaupten wäre falsch.
Distroless- und chiselled-Images
Chiselled-Ubuntu-Images (Canonicals Distroless-Variante) haben keine dpkg-Datenbank — ihr Paketverzeichnis ist das chisel-Manifest unter var/lib/chisel/manifest.wall, das kunnus als eigene Distro-Familie liest. Zusätzlich zu den Paketen selbst werden die SHA-256-Digests pro Paket aus dem Manifest zurückgewonnen und als Komponenten-Hashes angehängt; die DEP-5-Copyright-Dateien aus dem Copyright-Slice jedes Pakets liefern die Lizenzen. Ein Distroless-Image ergibt so eine vollständig befüllte SBOM statt einer leeren.
Eine Registry-Referenz bringt außerdem ihre eigene Identität mit: ghcr.io/acme/app:v1.2.3 schlüsselt die Seriennummer der SBOM über den Repository-Pfad, der Tag wird die Komponentenversion. Aufeinanderfolgende Builds auf demselben Tag bilden damit ohne weitere Flags eine Dokumentenserie. Tarball-Scans haben keine solche Identität — siehe den Guide zur SBOM-Identität.