CNAPP: cos'è e quali componenti ha (CSPM, CWPP, CIEM)

La risposta breve: una CNAPP (cloud-native application protection platform) è una piattaforma che riunisce in un solo prodotto i controlli di sicurezza del cloud che prima si compravano separati: le configurazioni (CSPM), i workload (CWPP), i permessi (CIEM), i dati (DSPM), Kubernetes, il codice e il rilevamento delle minacce a runtime. Il valore non sta nella somma dei moduli, ma nel contesto che li lega: una CNAPP ti dice quali rischi sono davvero sfruttabili e in che ordine sistemarli.

Una nota per chi arriva da una ricerca: la sigla somiglia a CNAPPC, quella del Consiglio Nazionale degli Architetti, Pianificatori, Paesaggisti e Conservatori. Qui si parla di cloud. Vediamo da dove viene la categoria, quali pezzi la compongono, come lavora, cosa non fa e quando ha senso per un'azienda mid-market.

Da dove viene il termine CNAPP?

Secondo Wiz, la sigla l'ha introdotta Gartner, la società di analisi, per dare un nome a una convergenza che il mercato stava già vivendo. Nella definizione di Gartner che Wiz riporta nella sua Academy, una CNAPP è un insieme unificato e strettamente integrato di funzioni di sicurezza e compliance, pensato per mettere in sicurezza le applicazioni cloud native dallo sviluppo alla produzione (la resa in italiano è nostra).

Le parole che contano sono due. Integrato: non una suite di prodotti con lo stesso logo, ma un unico modello dati su cui lavorano tutti i controlli. Dallo sviluppo alla produzione: la stessa piattaforma guarda il codice e i template prima del rilascio, e le risorse che girano davvero dopo.

Un elenco ufficiale dei moduli però non esiste, e ogni vendor taglia la categoria a modo suo. Microsoft, per esempio, nella documentazione descrive Defender for Cloud come una CNAPP con tre componenti principali: CSPM, sicurezza DevOps e CWPP. Wiz elenca anche CIEM, KSPM, DSPM, sicurezza del codice e CDR. Quando confronti due offerte, confronta le funzioni, non le sigle.

Quale problema risolve una CNAPP?

Il cloud ha cambiato chi crea l'infrastruttura. Una volta un server si comprava, si installava e finiva in un inventario. Oggi uno sviluppatore apre un bucket, una funzione serverless o un cluster Kubernetes in pochi minuti, e la sicurezza di quella risorsa dipende da come ha compilato un template.

Il modello di responsabilità condivisa dice chi si occupa di cosa: il provider dell'infrastruttura sottostante e della sicurezza fisica, il cliente di configurazioni, identità e dati, con una ripartizione che cambia tra IaaS, PaaS e SaaS. La documentazione di architettura di Google Cloud dedicata a questo modello lo dice senza giri di parole: molte violazioni della sicurezza del cloud sono la conseguenza diretta di una configurazione sbagliata.

Per anni la risposta è stata un tool per ogni problema: uno scanner di vulnerabilità, un controllo delle configurazioni, uno strumento per i permessi, uno per i container. Ognuno produce la sua lista, e nessuno vede il quadro. Lo scanner sa che una macchina ha una vulnerabilità nota, ma non sa che è esposta su internet e che usa un ruolo con accesso al database dei clienti. Presi uno per uno sono tre avvisi di media gravità. Messi insieme sono una strada aperta verso i dati.

La CNAPP nasce per fare quel collegamento. È lo stesso problema dell'alert fatigue nel SOC, spostato sulla postura del cloud: troppi avvisi senza contesto, e il rischio vero sepolto in mezzo.

Quali sono i componenti di una CNAPP?

Le sigle sono tante e in parte si sovrappongono. Ecco cosa fa ciascun pezzo, in parole semplici.

CSPM: la postura delle configurazioni

La cloud security posture management confronta la configurazione di ogni risorsa con un insieme di regole: storage pubblici, porte aperte verso internet, log disattivati, cifratura assente, account senza autenticazione a più fattori. Le regole vengono dalle raccomandazioni dei provider e da standard pubblici come i CIS Benchmark, e i risultati si mappano sui framework di compliance. È il pezzo da cui la categoria è partita.

CWPP: i workload

La cloud workload protection platform guarda dentro ciò che gira: macchine virtuali, container, funzioni serverless. Cerca vulnerabilità nei pacchetti installati, malware, segreti lasciati sul disco (chiavi, token, password) e configurazioni deboli del sistema operativo. Può lavorare senza agenti, analizzando i dischi dall'esterno, oppure con un sensore leggero per vedere cosa succede in tempo reale.

CIEM: identità e permessi

Il cloud infrastructure entitlement management si occupa di chi può fare cosa. Nel cloud le identità non sono solo persone: sono service account, ruoli assegnati alle macchine, chiavi di accesso delle applicazioni. Il CIEM calcola i permessi effettivi di ciascuna identità, trova quelli concessi e mai usati e aiuta ad applicare il principio del minimo privilegio.

DSPM: i dati

La data security posture management cerca dove stanno i dati sensibili (bucket, volumi, database gestiti e ospitati) e li incrocia con il resto: un database con dati personali è un problema diverso se è raggiungibile da internet o se ci accede un ruolo troppo largo. Per chi risponde del GDPR è la parte che collega il registro dei trattamenti a quello che c'è davvero nel cloud. Come funziona, e in cosa si distingue da CSPM e DLP, è spiegato nella guida alla DSPM nel cloud.

KSPM: Kubernetes

La Kubernetes security posture management applica lo stesso ragionamento ai cluster: configurazioni, permessi, segreti, esposizione di rete, vulnerabilità di container e host. Serve se usi Kubernetes, gestito o no; se non lo usi, è un modulo che puoi ignorare.

Sicurezza del codice e dell'infrastructure as code

Qui la CNAPP si sposta a monte, nella pipeline di sviluppo. Analizza i template di infrastructure as code (Terraform, CloudFormation, manifest Kubernetes), il codice sorgente e le pipeline prima del rilascio, così una configurazione sbagliata si ferma nella pull request invece di essere scoperta in produzione. Nel gergo si chiama shift left. Cosa trova uno scanner in quei template, e quali rischi di Terraform restano fuori, lo raccontiamo nella scheda sull'IaC scanning.

CDR: rilevamento e risposta nel cloud

Il cloud detection and response guarda cosa succede adesso: l'attività nel cloud, i log di audit e i segnali a runtime dai workload. Cerca comportamenti come escalation dei privilegi, movimento laterale, cryptomining, fuga da un container, esecuzione di codice da remoto. È il punto in cui la CNAPP tocca il lavoro del SOC.

Wiz aggiunge un'ultima direzione: secondo la sua Academy, le CNAPP stanno assorbendo anche la postura dei servizi di intelligenza artificiale (AI-SPM), cioè modelli, endpoint, dati di addestramento e permessi degli agenti AI. È la stessa logica applicata a una superficie nuova.

Cosa distingue una CNAPP da una somma di tool?

Se una CNAPP fosse solo sette moduli nella stessa console, sarebbe un bundle commerciale. La differenza sta nel modello dati sotto.

• Un inventario unico. Tutte le risorse di tutti gli account e di tutti i cloud nello stesso posto, aggiornate di continuo. È la base di tutto il resto.
• Un grafo delle relazioni. Ogni risorsa è un nodo, ogni relazione è un collegamento: questa macchina usa questo ruolo, questo ruolo legge questo bucket, questo bucket contiene dati personali. Sul grafo si fanno domande che una lista non permette.
• Percorsi di attacco. Dal grafo esce la combinazione che conta: esposizione su internet, più una vulnerabilità sfruttabile, più un permesso che porta ai dati. È quello che trasforma migliaia di segnalazioni in una manciata di priorità.
• Una coda sola. I rischi arrivano già ordinati per impatto, con la risorsa, il suo proprietario e cosa correggere, invece di cinque liste da riconciliare a mano.

Una CNAPP richiede agenti?

Dipende da cosa deve fare. Conviene essere precisi, perché è una delle prime domande che fa chi gestisce gli account cloud.

• Inventario e configurazioni via API. La piattaforma si collega al cloud con un ruolo dedicato con permessi di lettura, e legge dalle API del provider risorse, configurazioni, rete e permessi. Nessun software sulle macchine.
• Analisi dei dischi da snapshot. Per guardare dentro i workload (pacchetti, vulnerabilità, segreti) l'approccio agentless crea snapshot temporanee e cifrate dei dischi e le analizza in un ambiente isolato, fuori dalla produzione. Servono quindi anche i permessi per creare e cancellare quelle snapshot: non è tutto in sola lettura, ed è giusto saperlo prima di parlarne con chi amministra il cloud.
• Sensore a runtime, dove serve. Per vedere processi e comportamenti in tempo reale si aggiunge un agente leggero sui workload più critici. È uno strato in più, non la condizione per partire.

La pagina di Wiz sulla scansione agentless descrive proprio questo schema a due tempi: permessi API in lettura per l'inventario, snapshot temporanee per l'analisi profonda. Il vantaggio pratico è che una prima fotografia del cloud si ottiene senza installare niente e senza toccare i sistemi in produzione.

CNAPP, SIEM e SOC: chi fa cosa?

Una CNAPP non sostituisce il SIEM e non è un SOC. Sono tre cose diverse che lavorano bene insieme.

• La CNAPP lavora soprattutto sulla prevenzione: riduce la superficie d'attacco del cloud prima che qualcuno la usi e, con il CDR, segnala le attività sospette dentro il cloud.
• Il SIEM raccoglie e correla gli eventi di tutto il resto: endpoint, identità, posta, rete, applicazioni. Un attacco raramente resta dentro un solo dominio, e la correlazione serve a seguirlo mentre si sposta.
• Il SOC sono le persone e i processi che leggono i segnali, indagano e rispondono, a ogni ora. Se ti interessa come si incastrano rilevamento sugli endpoint e servizio gestito, trovi il confronto in EDR, XDR e MDR: le differenze.

Il collegamento tra i tre è il punto che Google ha messo al centro quando ha completato l'acquisizione di Wiz. Nel post di Thomas Kurian, CEO di Google Cloud, dell'11 marzo 2026, uno dei benefici annunciati è una piattaforma che unisce Wiz con Google Security Operations per mettere in sicurezza le applicazioni cloud native in ogni fase: sviluppo, build e runtime. Per l'altro lato del discorso c'è il nostro approfondimento su Google SecOps, cos'è e come funziona.

C'è poi un limite pratico da tenere a mente: una CNAPP trova e ordina i problemi, ma la correzione la fanno le persone. Qualcuno deve prendere la coda delle priorità, girarla ai team che possiedono le risorse e verificare che la correzione regga nel tempo. Senza quel lavoro, anche una buona piattaforma diventa un'altra dashboard. Il programma che organizza questo lavoro, dalla scoperta delle esposizioni alla mobilitazione di chi le corregge, è il CTEM, il continuous threat exposure management.

Quando serve una CNAPP?

Non a tutti, e non nello stesso momento. Questi sono i segnali che di solito la rendono sensata.

• Hai workload veri su IaaS o PaaS (macchine virtuali, container, database gestiti, funzioni) su AWS, Google Cloud o Azure, non solo applicazioni SaaS.
• Il cloud è cresciuto più in fretta della squadra: molti account o progetti, più team che creano risorse, un inventario che nessuno può garantire completo.
• Usi Kubernetes o rilasci spesso, e le configurazioni cambiano ogni settimana.
• Lavori su più di un cloud: ogni provider ha la sua console di sicurezza, e il quadro d'insieme non lo dà nessuna di loro.
• Clienti, auditor o investitori chiedono evidenze: questionari di sicurezza, due diligence tecniche, audit ISO 27001 o SOC 2 che entrano nell'ambiente cloud.

Per chi rientra nella NIS2 c'è un aggancio diretto. L'art. 24, comma 2, del D.Lgs. 138/2024 elenca gli elementi che le misure di gestione del rischio devono comprendere almeno, e tra questi ci sono la sicurezza della catena di approvvigionamento (lettera d), la sicurezza dell'acquisizione, dello sviluppo e della manutenzione dei sistemi informativi e di rete, compresa la gestione delle vulnerabilità (lettera e), e le politiche di controllo dell'accesso e di gestione dei beni e degli assetti (lettera i). La legge non chiede una CNAPP, ma sul perimetro cloud una CNAPP produce proprio le evidenze che quelle misure presuppongono: inventario, vulnerabilità, permessi. Il quadro completo degli obblighi è nella nostra guida completa alla NIS2.

Quando invece può aspettare: se il tuo cloud è quasi solo SaaS (Microsoft 365, Google Workspace, un CRM) e hai poche macchine virtuali stabili, il rischio principale sta nelle identità, nella posta e nella configurazione dei tenant. Lì un vulnerability assessment periodico e una gestione degli accessi fatta bene danno di più di una piattaforma nuova.

Come si valuta una CNAPP?

Le schede prodotto si somigliano tutte. Queste sono le domande che separano le piattaforme quando le provi sul tuo ambiente.

1. Copertura. Legge tutti i tuoi cloud e i servizi che usi davvero, compresi Kubernetes gestito, serverless e database gestiti?
2. Tempo per la prima fotografia. Quanto serve per collegarla e vedere l'inventario completo, e con quali permessi esattamente?
3. Qualità delle priorità. Su un tuo account reale, quante delle prime dieci segnalazioni sono cose che correggeresti subito? È il test che dice di più.
4. Percorsi di attacco spiegati. Per ogni rischio critico ti mostra la catena (esposizione, vulnerabilità, permesso, dato) e quale anello rompere per interromperla?
5. Integrazioni. Manda i rischi nei ticket dei team di sviluppo e gli eventi al SIEM, o resta un'isola?
6. Chi ci lavora. Hai le persone per smaltire la coda, o serve un partner che la gestisca con te?

La prova più onesta è un proof of value su un ambiente vero: qualche settimana collegati ai tuoi account dice più di qualunque demo su dati di esempio.

Wiz, un esempio concreto di CNAPP

Wiz è una piattaforma CNAPP: si collega ai cloud via API, senza agenti, costruisce la mappa delle risorse, dei permessi e dei flussi di dati e mette in fila i percorsi di attacco sfruttabili. Google ha completato l'acquisizione di Wiz l'11 marzo 2026: il team è entrato in Google Cloud, il marchio Wiz resta, e secondo lo stesso annuncio i prodotti Wiz continuano a funzionare ed essere disponibili sui principali cloud, compresi AWS, Microsoft Azure e Oracle.

AmagisTech è partner Wiz. Lo usiamo per fare la fotografia del cloud di cui abbiamo parlato: collegarci agli account di un'azienda, vedere cosa è esposto davvero e mettere in ordine cosa sistemare prima.

In sintesi

In sintesi: una CNAPP unisce postura delle configurazioni, workload, permessi, dati, Kubernetes, codice e rilevamento a runtime in un unico modello dati, e il suo valore sta nel collegare questi segnali in pochi percorsi di attacco da chiudere. Non sostituisce SIEM e SOC, e serve davvero quando il cloud ha workload veri ed è cresciuto più in fretta di chi lo governa. Se vuoi vedere cosa troverebbe nel tuo, parti dalla fotografia del cloud con Wiz: via API, senza agenti, con i rischi in ordine di priorità.