Re: Frage zu Containerregistry

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=C3=B6chte 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=C3=BCft und
> SBOMs
> als quasi Zutatenliste vorgehalten werden k=C3=B6nnen. Vom Komplexit=C3=
=A4tsgrad
> gehts eher um Docker/ Podman -Build und -Compose und nicht um ein
> ausgewachsenes Kubernetes.

Wir nehmen daf=C3=BCr Trivy. <https://github.com/aquasecurity/trivy>

Das macht grunds=C3=A4tzlich 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=
=C3=B6chtest.
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=C3=A4le reinzubringen. Aber man kann's auch einfach lokal auf der
CLI ausf=C3=BChren. 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=C3=A4tzlich, habe ich aber noch keine Erfahrung damit. Haben wir im
Backlog, aber bis jetzt machen wir Filtering nur im Frontend.

Wir hatten fr=C3=BCher 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=C3=B6ne Gr=C3=BC=C3=9Fe
Stefan