Afhængigheder
Container-scanning
Container-scanning undersøger et container-image for kendte sårbarheder, forældede pakker og risikabel konfiguration. Et image samler din applikation med et basisoperativsystem og alt derimellem, så en scanning dækker langt mere end dine egne afhængigheder. Den læser også det færdige image, hvilket begrænser, hvad den kan vide om, hvordan det blev lavet.
Opdateret
Sådan virker container-scanning
- Pak imaget ud. Scanneren læser imagets lag uden at køre dem.
-
Kortlæg indholdet. Den læser operativsystemets pakkedatabaser og applikationsmanifester, for eksempel
en
package-lock.json, der er kopieret ind i imaget. - Match dataene. Den sammenligner pakker med sårbarhedsdata fra distributioner og advisory-databaser.
- Tjek konfigurationen. Nogle værktøjer markerer også ting som kørsel som root eller secrets efterladt i et lag.
Hvor du skal køre en scanning
| Stadie | Hvad du får | Begrænsning |
|---|---|---|
| CI, efter image-buildet | Får buildet til at fejle, før et image bliver pushet | Et øjebliksbillede af den dags advisories |
| Registry | Genscanner gemte images, efterhånden som nye advisories dukker op | Finder problemer, efter imaget er offentliggjort |
| Kubernetes admission | Blokerer uscannede eller fejlende images ved udrulning | Kræver en policy og en måde at håndtere undtagelser på |
| Runtime | Viser, hvilke images der kører nu, og hvad der er indlæst | Kræver en agent på dine clusters |
Værktøjer til container-scanning
- Open source: Trivy og Grype er de almindelige gratis valg, og begge passer nemt ind i CI.
- Indbygget i registries og platforme: Docker Scout og de store cloud-registries tilbyder scanning.
- Kommercielle platforme: Snyk og Anchore tilføjer policy, rapportering og workflow.
Sådan reducerer du antallet af fund
- Start med et mindre base-image. Slim- eller distroless-images indeholder færre pakker, så færre advisories gælder.
- Genbyg regelmæssigt. Base-images bliver patchet, og et image, der var rent i marts, er ikke rent nu.
- Brug multi-stage builds. Compilere og build-værktøjer bør holdes ude af det endelige image.
- Fastlås base-images med digest. Et tag kan ændre sig uden varsel, det kan et digest ikke.
- Prioritér. Mange fund har endnu ingen rettelse eller sidder i pakker, din applikation aldrig bruger. Se sådan prioriterer du sårbarheder.
Hvad en container-scanning ikke kan se
- Kompileret kode. En Go- eller Rust-binærfil i imaget har begrænsede metadata, og en scanner må regne ud, hvad der gik ind.
-
Filer uden pakkeregistrering. Software tilføjet med
curleller kopieret ind i et lag har ingen post i en pakkedatabase. - Det, buildet brugte og efterlod. Multi-stage builds kasserer de værktøjer, der producerede imaget. Hvis et af dem var kompromitteret, siger intet i det endelige image det.
- Hvor det kom fra. En scanning beskriver imaget, ikke det build, der producerede det.
Se hvad en SBOM af et Docker-image overser for et nærmere kig og de bedste SBOM-værktøjer for mulighederne.
Scanning af images og registrering af builds
Scannere er det rigtige værktøj til images, du ikke selv har bygget, samt clusters og konfiguration. Til images, du selv bygger, går CRACI en anden vej. Som din GitHub Actions-runner ser det, hvad der kommer ind i buildet, inklusive base-imaget og dets operativsystemlag, så det registrerer, hvad der gik ind, i stedet for at regne det ud bagefter. Derefter bliver det ved med at tjekke de SBOM'er, efterhånden som nye sårbarheder offentliggøres.
CRACI scanner ikke images, du ikke selv har bygget, clusters, VM-images eller fejlkonfigurationer. Det gør Trivy, så behold det til de ting. Se CRACI vs Trivy.
Container-scanning: ofte stillede spørgsmål
Hvad er container-scanning?
Det er processen med at undersøge et container-image for kendte sårbarheder, forældede pakker og risikabel konfiguration, som regel uden at køre det.
Hvornår skal du scanne container-images?
I CI, efter imaget er bygget, og igen i registryet, når nye advisories dukker op. Scanner du kun én gang, står du tilbage med et øjebliksbillede, der hurtigt forældes.
Hvad er den bedste gratis container-scanner?
Trivy og Grype er de mest brugte gratis muligheder. Begge kører i CI og dækker operativsystem- og applikationspakker.
Hvad er forskellen på image-scanning og en SBOM?
En SBOM viser, hvad der er i et image, mens en scanning tjekker indholdet for kendte problemer. Mange scannere bygger først en SBOM og matcher den derefter mod advisories.
Hvorfor har mit container-image så mange sårbarheder?
Mest på grund af base-imaget, som bringer et operativsystems pakker med. Et mindre base-image og regelmæssige genbygninger fjerner de fleste af dem.
Kan en container-scanner læse kompilerede binærfiler?
Delvist. Go- og Rust-binærfiler kan indeholde nogle afhængighedsmetadata, men meget kompileret kode giver en scanner lidt at gå ud fra, så den må udlede, hvad der gik ind.
Se, hvad der gik ind i dit image
Byg et image på CRACI, og sammenlign den registrerede SBOM med det, din container-scanner rapporterer.
Book en demo