Hallo,
da ich gerade auf der Suche nach Best Practice zu Container-Tooling bin, möchte ich fragen, wie so eure Erfahrungen mit Container-Registries sind. Im Sinne einer guten Softwarelieferkette sollen Containerimages automatisiert auf bekannte Schwachstellen (CVEs & Co.) geprüft und SBOMs als quasi Zutatenliste vorgehalten werden können. Vom Komplexitätsgrad gehts eher um Docker/ Podman -Build und -Compose und nicht um ein ausgewachsenes Kubernetes.
Grüße Norman
On Sun Mar 2, 2025 at 12:43 PM CET, N. Schwirz wrote:
da ich gerade auf der Suche nach Best Practice zu Container-Tooling bin, möchte ich fragen, wie so eure Erfahrungen mit Container-Registries sind.
Ich betreibe auf Arbeit eine nach internen Anforderungen in-house entwickelte Container-Registry. https://github.com/sapcc/keppel
Im Sinne einer guten Softwarelieferkette sollen Containerimages automatisiert auf bekannte Schwachstellen (CVEs & Co.) geprüft und SBOMs als quasi Zutatenliste vorgehalten werden können. Vom Komplexitätsgrad gehts eher um Docker/ Podman -Build und -Compose und nicht um ein ausgewachsenes Kubernetes.
Wir nehmen dafür Trivy. https://github.com/aquasecurity/trivy
Das macht grundsätzlich genau die beiden Sachen, die du willst: SBOM generieren und darauf basierend CVE etc. abgleichen. Kommt dann halt drauf an, ob du besondere Anforderungen hast, welche Arten von Assets und welche Schwachstellendatenbanken du angebunden haben möchtest. Bei uns ist ersteres neben Systempaketen Go und Python und letzteres Alpine/Ubuntu-Advisories und GHSA. Das ist dort abgedeckt.
Wir betreiben das als Server-Komponente, die von unserer Registry aktiv gepollt wird, um Vulnerabilities bei Auftreten in die entsprechenden Meldekanäle reinzubringen. Aber man kann's auch einfach lokal auf der CLI ausführen. Als Server-Prozess gibt es da im Wesentlichen den Vorteil, dass man SBOMs in Redis cachen kann.
Falls du False Positives mit VEX wegfiltern willst: Das kann's grundsätzlich, habe ich aber noch keine Erfahrung damit. Haben wir im Backlog, aber bis jetzt machen wir Filtering nur im Frontend.
Wir hatten früher auch mal Clair, aber das war damals (vor 2 Jahren) deutlich schlechter in der Erkennungsrate, und zudem auch ressourcenhungriger. Da bin ich sehr froh, davon weg zu sein.
Schöne Grüße Stefan
Hallo Stefan,
vielen Dank für die Antwort. Trivy probiere ich bereits aus und bin bisher auch recht zufrieden damit. Weißt du vielleicht wie man damit Vulnerabilities & Co. vom CERT-Bund nutzen kann?
Viele Grüße, Norman
On 02.03.25 17:47, Stefan Majewsky wrote:
On Sun Mar 2, 2025 at 12:43 PM CET, N. Schwirz wrote:
da ich gerade auf der Suche nach Best Practice zu Container-Tooling bin, möchte ich fragen, wie so eure Erfahrungen mit Container-Registries sind.
Ich betreibe auf Arbeit eine nach internen Anforderungen in-house entwickelte Container-Registry. https://github.com/sapcc/keppel
Im Sinne einer guten Softwarelieferkette sollen Containerimages automatisiert auf bekannte Schwachstellen (CVEs & Co.) geprüft und SBOMs als quasi Zutatenliste vorgehalten werden können. Vom Komplexitätsgrad gehts eher um Docker/ Podman -Build und -Compose und nicht um ein ausgewachsenes Kubernetes.
Wir nehmen dafür Trivy. https://github.com/aquasecurity/trivy
Das macht grundsätzlich genau die beiden Sachen, die du willst: SBOM generieren und darauf basierend CVE etc. abgleichen. Kommt dann halt drauf an, ob du besondere Anforderungen hast, welche Arten von Assets und welche Schwachstellendatenbanken du angebunden haben möchtest. Bei uns ist ersteres neben Systempaketen Go und Python und letzteres Alpine/Ubuntu-Advisories und GHSA. Das ist dort abgedeckt.
Wir betreiben das als Server-Komponente, die von unserer Registry aktiv gepollt wird, um Vulnerabilities bei Auftreten in die entsprechenden Meldekanäle reinzubringen. Aber man kann's auch einfach lokal auf der CLI ausführen. Als Server-Prozess gibt es da im Wesentlichen den Vorteil, dass man SBOMs in Redis cachen kann.
Falls du False Positives mit VEX wegfiltern willst: Das kann's grundsätzlich, habe ich aber noch keine Erfahrung damit. Haben wir im Backlog, aber bis jetzt machen wir Filtering nur im Frontend.
Wir hatten früher auch mal Clair, aber das war damals (vor 2 Jahren) deutlich schlechter in der Erkennungsrate, und zudem auch ressourcenhungriger. Da bin ich sehr froh, davon weg zu sein.
Schöne Grüße Stefan
lug-dd@mailman.schlittermann.de
-
N. Schwirz -
Stefan Majewsky