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
- Decompressione dell'immagine. Lo scanner legge i layer dell'immagine senza eseguirli.
-
Elenco dei contenuti. Legge i database dei pacchetti del sistema operativo e i manifest delle
applicazioni, come un
package-lock.jsoncopiato nell'immagine. - Confronto con i dati. Confronta i pacchetti con i dati sulle vulnerabilità provenienti dalle distribuzioni e dai database di advisory.
- 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
curlo 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