123% di CVE segnalate in più al giorno nel 2026 rispetto all'anno scorso.

Dipendenze

Scansione dei container

La scansione dei container esamina un'immagine container alla ricerca di vulnerabilità note, pacchetti obsoleti e configurazioni rischiose. Un'immagine riunisce la Sua applicazione, un sistema operativo di base e tutto ciò che sta in mezzo, quindi una scansione copre molto più delle Sue dipendenze. Legge inoltre l'immagine finita, il che limita ciò che può sapere su come è stata creata.

Aggiornato il

Come funziona la scansione dei container

  1. Decompressione dell'immagine. Lo scanner legge i layer dell'immagine senza eseguirli.
  2. Elenco dei contenuti. Legge i database dei pacchetti del sistema operativo e i manifest delle applicazioni, come un package-lock.json copiato nell'immagine.
  3. Confronto con i dati. Confronta i pacchetti con i dati sulle vulnerabilità provenienti dalle distribuzioni e dai database di advisory.
  4. Controllo della configurazione. Alcuni strumenti segnalano anche elementi come l'esecuzione come root o i secret lasciati in un layer.

Dove eseguire una scansione

Fase Che cosa offre Limite
CI, dopo la build dell'immagine Fa fallire la build prima del push di un'immagine Un'istantanea degli advisory di quel giorno
Registry Riscansiona le immagini archiviate man mano che compaiono nuovi advisory Trova i problemi dopo la pubblicazione dell'immagine
Admission di Kubernetes Blocca al deployment le immagini non scansionate o che non superano i controlli Richiede una policy e un modo per gestire le eccezioni
Runtime Mostra quali immagini sono in esecuzione ora e che cosa è caricato Richiede un agente sui Suoi cluster

Strumenti per la scansione dei container

  • Open source: Trivy e Grype sono le scelte gratuite più comuni, ed entrambi si integrano facilmente in CI.
  • Integrati in registry e piattaforme: Docker Scout e i principali registry cloud offrono la scansione.
  • Piattaforme commerciali: Snyk e Anchore aggiungono policy, reportistica e workflow.

Come ridurre i risultati

  • Parta da un'immagine base più piccola. Le immagini slim o distroless contengono meno pacchetti, quindi si applicano meno advisory.
  • Ricompili regolarmente. Le immagini base ricevono patch, e un'immagine pulita a marzo oggi non lo è più.
  • Usi build multi-stage. Compilatori e strumenti di build devono restare fuori dall'immagine finale.
  • Fissi le immagini base per digest. Un tag può cambiare a Sua insaputa, un digest no.
  • Stabilisca le priorità. Molti risultati non hanno ancora una correzione o si trovano in pacchetti che la Sua applicazione non usa mai. Veda come dare priorità alle vulnerabilità.

Che cosa non vede una scansione dei container

  • Il codice compilato. Un binario Go o Rust nell'immagine contiene metadati limitati, e uno scanner deve ricavare che cosa vi è entrato.
  • I file senza record di pacchetto. Il software aggiunto con curl o copiato in un layer non ha alcuna voce in un database di pacchetti.
  • Ciò che la build ha usato e lasciato indietro. Le build multi-stage scartano gli strumenti che hanno prodotto l'immagine. Se uno di questi è stato compromesso, nulla nell'immagine finale lo dice.
  • Da dove proviene. Una scansione descrive l'immagine, non la build che l'ha prodotta.

Veda che cosa manca in una SBOM di un'immagine Docker per un esame più approfondito e i migliori strumenti SBOM per le opzioni disponibili.

Scansionare le immagini e registrare le build

Gli scanner sono lo strumento giusto per le immagini che non ha creato Lei, oltre che per cluster e configurazioni. Per le immagini che crea Lei, CRACI segue una strada diversa. Come Suo runner GitHub Actions, vede ciò che entra nella build, compresi l'immagine base e i suoi layer del sistema operativo, quindi registra ciò che è entrato invece di ricavarlo a posteriori. Poi continua a controllare quelle SBOM man mano che vengono pubblicate nuove vulnerabilità.

CRACI non scansiona immagini che non ha creato Lei, cluster, immagini di VM o configurazioni errate. Trivy sì, quindi lo mantenga per questi casi. Veda CRACI vs Trivy.

Scansione dei container: domande frequenti

Che cos'è la scansione dei container?

È il processo di esame di un'immagine container alla ricerca di vulnerabilità note, pacchetti obsoleti e configurazioni rischiose, di solito senza eseguirla.

Quando vanno scansionate le immagini container?

In CI dopo la build dell'immagine, e di nuovo nel registry man mano che compaiono nuovi advisory. Una sola scansione Le lascia un'istantanea che invecchia in fretta.

Qual è il miglior scanner gratuito per container?

Trivy e Grype sono le opzioni gratuite più usate. Entrambi funzionano in CI e coprono i pacchetti del sistema operativo e delle applicazioni.

Qual è la differenza tra scansione delle immagini e SBOM?

Una SBOM elenca ciò che si trova in un'immagine, mentre una scansione controlla quei contenuti alla ricerca di problemi noti. Molti scanner creano prima una SBOM e poi la confrontano con gli advisory.

Perché la mia immagine container ha così tante vulnerabilità?

Soprattutto a causa dell'immagine base, che introduce i pacchetti di un sistema operativo. Un'immagine base più piccola e ricompilazioni regolari ne eliminano la maggior parte.

Uno scanner per container può leggere i binari compilati?

In parte. I binari Go e Rust possono contenere alcuni metadati sulle dipendenze, ma gran parte del codice compilato offre a uno scanner pochi appigli, quindi deve dedurre che cosa vi è entrato.

Veda ciò che è entrato nella Sua immagine

Crei un'immagine su CRACI e confronti la SBOM registrata con ciò che riporta il Suo scanner per container.

Prenota una demo