Containerscanning: hoe het werkt en wat het niet ziet

Hoe containerscanning werkt

De image uitpakken. De scanner leest de lagen van de image zonder ze uit te voeren.
De inhoud inventariseren. Hij leest pakketdatabases van het besturingssysteem en applicatiemanifests, zoals een package-lock.json die in de image is gekopieerd.
De gegevens matchen. Hij vergelijkt pakketten met kwetsbaarheidsgegevens van distributies en advisorydatabases.
De configuratie controleren. Sommige tools markeren ook zaken als draaien als root of secrets die in een laag zijn achtergebleven.

Waar u een scan laat draaien

Fase	Wat het oplevert	Beperking
CI, na de imagebuild	Laat de build mislukken voordat een image wordt gepusht	Een momentopname van de advisories van die dag
Registry	Scant opgeslagen images opnieuw zodra er nieuwe advisories verschijnen	Vindt problemen nadat de image is gepubliceerd
Kubernetes-admission	Blokkeert ongescande of afgekeurde images bij de deployment	Vereist een beleid en een manier om uitzonderingen af te handelen
Runtime	Toont welke images nu draaien, en wat er is geladen	Vereist een agent op uw clusters

Tools voor containerscanning

Open source: Trivy en Grype zijn de gangbare gratis keuzes, en beide passen makkelijk in CI.
Ingebouwd in registries en platforms: Docker Scout en de grote cloudregistries bieden scanning aan.
Commerciële platforms: Snyk en Anchore voegen beleid, rapportage en workflow toe.

Hoe u het aantal bevindingen verlaagt

Begin met een kleinere base image. Slim- of distroless-images bevatten minder pakketten, dus er zijn minder advisories van toepassing.
Bouw regelmatig opnieuw. Base images worden gepatcht, en een image die in maart schoon was, is dat nu niet meer.
Gebruik multi-stage builds. Compilers en buildtools horen niet in de uiteindelijke image.
Pin base images vast op digest. Een tag kan ongemerkt veranderen, een digest niet.
Prioriteer. Veel bevindingen hebben nog geen oplossing of zitten in pakketten die uw applicatie nooit gebruikt. Zie hoe u kwetsbaarheden prioriteert.

Wat een containerscan niet kan zien

Gecompileerde code. Een Go- of Rust-binary in de image bevat beperkte metadata, en een scanner moet afleiden wat erin is gegaan.
Bestanden zonder pakketrecord. Software die met curl is toegevoegd of in een laag is gekopieerd, heeft geen vermelding in een pakketdatabase.
Wat de build heeft gebruikt en achtergelaten. Multi-stage builds gooien de tools weg die de image hebben geproduceerd. Was een daarvan gecompromitteerd, dan blijkt dat nergens uit de uiteindelijke image.
Waar het vandaan kwam. Een scan beschrijft de image, niet de build die hem heeft geproduceerd.

Zie wat een SBOM van een Docker-image mist voor een nadere blik, en de beste SBOM-tools voor de opties.

Images scannen en builds vastleggen

Scanners zijn de juiste tool voor images die u niet zelf hebt gebouwd, en voor clusters en configuratie. Voor images die u wel bouwt, kiest CRACI een andere route. Als uw GitHub Actions-runner ziet het wat er de build binnenkomt, inclusief de base image en de lagen van het besturingssysteem, dus het legt vast wat erin is gegaan in plaats van dat achteraf af te leiden. Daarna blijft het die SBOM's controleren zodra nieuwe kwetsbaarheden worden gepubliceerd.

CRACI scant geen images die u niet zelf hebt gebouwd, geen clusters, geen VM-images en geen misconfiguraties. Trivy doet dat wel, dus houd het daarvoor aan. Zie CRACI vs Trivy.

Containerscanning: veelgestelde vragen

Wat is containerscanning?

Het is het onderzoeken van een containerimage op bekende kwetsbaarheden, verouderde pakketten en riskante configuratie, meestal zonder de image te draaien.

Wanneer moet u containerimages scannen?

In CI nadat de image is gebouwd, en opnieuw in de registry zodra er nieuwe advisories verschijnen. Met één scan houdt u een momentopname over die snel veroudert.

Wat is de beste gratis containerscanner?

Trivy en Grype zijn de meestgebruikte gratis opties. Beide draaien in CI en dekken pakketten van het besturingssysteem en van applicaties.

Wat is het verschil tussen imagescanning en een SBOM?

Een SBOM vermeldt wat er in een image zit, terwijl een scan die inhoud controleert op bekende problemen. Veel scanners stellen eerst een SBOM op en matchen die daarna met advisories.

Waarom heeft mijn containerimage zoveel kwetsbaarheden?

Vooral door de base image, die de pakketten van een besturingssysteem meebrengt. Een kleinere base image en regelmatig opnieuw bouwen nemen de meeste weg.

Kan een containerscanner gecompileerde binaries lezen?

Deels. Go- en Rust-binaries kunnen wat afhankelijkheidsmetadata bevatten, maar veel gecompileerde code geeft een scanner weinig houvast, dus hij moet afleiden wat erin is gegaan.