Gli strumenti della gamma Kaspersky annoverano una piattaforma dedicata alla protezione degli ambienti containerizzati. In questo post per\u00f2 voglio parlare di Kaspersky Container Security (KCS) non nella mia veste di rappresentante del marchio, bens\u00ec di membro effettivo di un team che usa attivamente questa soluzione nel lavoro di tutti i giorni. Il nostro team per la sicurezza dei prodotti ha il compito di stabilire processi di sviluppo sicuri per ogni aspetto aziendale. Siamo coinvolti in ogni fase del ciclo di vita dello sviluppo del software e la nostra priorit\u00e0 \u00e8 aiutare i team di prodotto a individuare tempestivamente i problemi di sicurezza in modo da rispettare il ciclo di pianificazione delle versioni. A tale scopo abbiamo creato diversi flussi di lavoro, uno dei quali orientato specificamente alla sicurezza dei contenitori. \u00c8d \u00e8 esattamente per questo che ci affidiamo alla piattaforma Kaspersky Container Security.<\/p>\n
Le soluzioni per la protezione dei contenitori sono in genere viste prima di tutto come scanner di immagini per il registro contenitori. In virt\u00f9 della sua integrazione end-to-end nel flusso di lavoro dei contenitori, Kaspersky Container Security (KCS) va per\u00f2 considerata pi\u00f9 come una piattaforma di protezione completa per ambienti di contenitori nella gestione di pi\u00f9 attivit\u00e0. Sebbene includa uno scenario (innegabilmente importante) di scansione delle immagini di contenitori, la nostra esperienza con KCS ha dimostrato che il suo reale valore diventa evidente quando la piattaforma viene integrata in pi\u00f9 punti del flusso di lavoro contemporaneamente:<\/p>\n
Il processo \u00e8 sostanzialmente standard. KCS controlla le immagini per individuare i problemi tipici dei contenitori: vulnerabilit\u00e0 note, malware, segreti con codifica hardware e configurazioni errate. Tuttavia, il risultato della scansione non \u00e8 solamente un singolo verdetto astratto. Il sistema calcola una classificazione del rischio in base ai risultati e fornisce un quadro chiaro dello stato di sicurezza della risorsa. Nella pratica tutto ci\u00f2 si rivela incredibilmente utile perch\u00e9 i team non vedono solo un messaggio di \u201cimmagine errata\u201d ma ottengono un\u2019analisi trasparente di cosa esattamente determina il rischio e cosa debba essere subito corretto.<\/p>\n
Ma non \u00e8 tutto. KCS funziona bene negli scenari in cui non basta trovare un problema, ma lo si deve anche associare al ciclo di vita dell\u2019artefatto. Quando un team gestisce centinaia di build, la scansione periodica del registro non \u00e8 pi\u00f9 sufficiente e richiede quasi sempre interventi manuali. \u00c8 necessario sapere quale pipeline ha introdotto il rischio, quali criteri sono stati attivati e quali sono i passaggi successivi. KCS fornisce questo collegamento essenziale.<\/p>\n
Una funzionalit\u00e0 meno nota di KCS \u00e8 la capacit\u00e0 di scansione completa all\u2019interno delle pipeline CI\/CD. Nel nostro team, questo \u00e8 il modo pi\u00f9 efficace di usare KCS. La logica \u00e8 semplice: si integra lo scanner nella pipeline e i risultati della scansione vengono visualizzati direttamente nei registri di esecuzione. I risultati sono poi inviati alla console centrale della soluzione, dove vengono registrati in una sezione CI\/CD dedicata che li collega al nome dell\u2019elemento, al tempo di scansione, alla pipeline e al livello di gravit\u00e0.<\/p>\n
In un ambiente CI\/CD \u00e8 possibile eseguire la scansione delle immagini da archivi tar o direttamente da archivi Git. Per impostazione predefinita, supporta GitLab, Jenkins, TeamCity e GitHub Actions. In pratica, KCS pu\u00f2 essere integrato in qualsiasi strumento di orchestrazione della pipeline.<\/p>\n
Un altro aspetto critico dell\u2019uso di KCS in CI\/CD riguarda i criteri di protezione. La nostra soluzione usa un modello in cui i criteri consentono non solo di raccogliere i risultati, ma anche di controllare il comportamento della pipeline. Ci\u00f2 risulta utile nelle implementazioni graduali. \u00c8 possibile iniziare in modalit\u00e0 di controllo e passare poi gradualmente alla generazione di errori quando vengono rilevati segreti, configurazioni errate critiche o vulnerabilit\u00e0. Questo approccio evolutivo generalmente funziona meglio di un semplice interruttore che blocca tutto in una volta.<\/p>\n
Gestiamo il nostro sistema di analisi della composizione, quindi non trattiamo KCS come un\u2019unica fonte di verit\u00e0. La piattaforma funge invece da potente livello aggiuntivo nei nostri flussi di lavoro, ed \u00e8 proprio in questa veste che offre il massimo.<\/p>\n
Sebbene il nostro sistema interno di analisi della composizione gestisca tracciamento dei componenti, dipendenze e valutazioni del rischio a livello di codice, KCS eccelle nella protezione del perimetro del contenitore. Si occupa della scansione delle immagini tecniche e della sicurezza CI\/CD aggregando i rapporti sugli artefatti del contenitore. Non \u00e8 in conflitto con la nostra analisi interna, bens\u00ec la rafforza proprio dove i contenitori ricevono carichi di lavoro effettivi.<\/p>\n
E questo ci \u00e8 particolarmente utile in due scenari. In primo luogo, fornisce il controllo degli artefatti nella fase iniziale dello sviluppo. In secondo luogo, funge da gatekeeper durante l\u2019accettazione del rilascio. Non discutiamo pi\u00f9 di rischi a rilascio avvenuto: li intercettiamo nel punto esatto in cui il team pu\u00f2 ancora correggere rapidamente un Dockerfile, un grafico Helm o un set di configurazione senza una lunga catena di approvazione.<\/p>\n
Degno di nota \u00e8 anche il modo in cui gestisce le distinte base software (SBOM). Il nostro sistema si basa principalmente su SBOM pertinenti e aggiornate. KCS offre modalit\u00e0 specifiche per l\u2019elaborazione delle SBOM e pu\u00f2 generare i risultati di scansione nello stesso formato. A questo proposito, KCS si integra perfettamente con i nostri processi interni, consentendoci di inserire la soluzione nei flussi di lavoro esistenti e non il contrario.<\/p>\n
L\u2019altro potente livello \u00e8 la sicurezza dei cluster. In questa fase KCS si eleva oltre un semplice strumento di scansione delle immagini. Presenta criteri di runtime per contenitori e nodi, modalit\u00e0 di controllo e di blocco e un set di profili di protezione. Nella pratica, questo significa che KCS \u00e8 utilizzabile non solo per trovare vulnerabilit\u00e0 all\u2019interno di un\u2019immagine, ma anche per monitorare le operazioni effettivamente eseguite dal contenitore una volta attivato. I criteri possono tenere conto della provenienza delle immagini, delle firme digitali, delle restrizioni su capacit\u00e0 e volumi e persino dei processi e delle connessioni di rete in esecuzione all\u2019interno del contenitori.<\/p>\n
Anzich\u00e9 procedere all\u2019immediato blocco del processo quando viene rilevato un problema, \u00e8 possibile scegliere di registrare i risultati in modalit\u00e0 di controllo. Negli ambienti di produzione, questa \u00e8 sempre la mossa pi\u00f9 intelligente. Un altro aspetto fondamentale \u00e8 garantire l\u2019attendibile provenienza delle immagini. KCS supporta la verifica della firma digitale, che sposta l\u2019attenzione dalla semplice ricerca dei CVE alla protezione dell\u2019intera catena di fornitura del software dell\u2019azienda.<\/p>\n
KCS non si limita a visualizzare i problemi rilevati, ma funge da fonte completa per i rapporti. Pu\u00f2 generare rapporti su immagini, rischi accettati e benchmark Kubernetes.<\/p>\n
I rapporti generati sono disponibili nei formati HTML, PDF, CSV, JSON e XML, con supporto specifico per la creazione di rapporti dettagliati in SARIF, ideale per l\u2019integrazione nei flussi di lavoro AppSec. Come per le SBOM sopra menzionate, gli scenari di scansione possono generare artefatti e risultati nei formati CycloneDX e SPDX, facilitando il collegamento ai processi esistenti.<\/p>\n
In poche parole, KCS integra perfettamente i nostri flussi di lavoro, non perch\u00e9 risolva ogni singolo problema, ma perch\u00e9 si integra cos\u00ec bene negli scenari di progettazione.<\/p>\n
Apprezziamo inoltre il fatto che il team del prodotto ascolti i nostri feedback. Il team KCS incorpora effettivamente nella tabella di marcia di sviluppo le nostre richieste operative pratiche. Ad esempio, un\u2019integrazione approfondita con SBOM e tipi di rapporti specifici sono stati aggiunti a KCS come risultato diretto della nostra esperienza sul campo.<\/p>\n