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-Daemon

Image-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.