--- title: "CRA: automatizzare il monitoraggio nelle pipeline cloud native" url: "https://www.sparkfabrik.com/it/blog/cra-automatizzare-il-monitoraggio-nelle-pipeline-cloud-native/" lang: "it" type: "blog-post" date: "2026-07-09" lastmod: "2026-07-09" author: "SparkFabrik Team" description: "Il Cyber Resilience Act trasforma la conformità in un processo continuo integrato nelle pipeline. Impara a gestire l'obbligo di notifica delle vulnerabilità entro 24 ore e il supporto quinquennale tramite l'automazione." tags: ["Cloud Native","DevOps","Security"] schema: "@context": "https://schema.org" "@type": "BlogPosting" "headline": "CRA: automatizzare il monitoraggio nelle pipeline cloud native" "description": "Il Cyber Resilience Act trasforma la conformità in un processo continuo integrato nelle pipeline. Impara a gestire l'obbligo di notifica delle vulnerabilità entro 24 ore e il supporto quinquennale tramite l'automazione." "url": "https://www.sparkfabrik.com/it/blog/cra-automatizzare-il-monitoraggio-nelle-pipeline-cloud-native/" "datePublished": "2026-07-09T00:00:00+00:00" "dateModified": "2026-07-09T00:00:00+00:00" "author": "@type": "Person" "name": "SparkFabrik Team" "image": "https://www.sparkfabrik.com/images/blog/cra-automatizzare-il-monitoraggio-nelle-pipeline-cloud-native/featured.webp" "publisher": "@type": "Organization" "name": "SparkFabrik" "url": "https://www.sparkfabrik.com" "logo": "https://www.sparkfabrik.com/images/logo.svg" --- # CRA: automatizzare il monitoraggio nelle pipeline cloud native **Autore:** SparkFabrik Team **Pubblicato:** 9 July 2026 **Tags:** Cloud Native, DevOps, Security --- {{% tldr %}}Con il Cyber Resilience Act la conformità non è più un audit annuale: diventa un processo continuo che vive dentro le pipeline, con obblighi come la notifica delle vulnerabilità sfruttate entro 24 ore e gli aggiornamenti garantiti per cinque anni. Automatizzare scanner e firma degli artefatti non basta, però: la responsabilità legale resta in capo al produttore, con sanzioni fino a 15 milioni di euro. La differenza tra un'automazione che protegge e una che fa solo rumore sta nelle evidenze firmate e versionate.{{% /tldr %}} _La sicurezza della catena di fornitura del software è in cima alle priorità di sicurezza per il 2026, e analisti come Gartner e vendor specializzati come Chainguard convergono su un punto: gli attacchi alla supply chain non sono più un'eventualità remota, ma il vettore d'ingresso preferenziale. Il problema non è più sapere cosa proteggere, ma come renderlo automatico e dimostrabile._ Con il **Cyber Resilience Act**[^1] la conformità smette di essere un audit annuale e diventa un processo continuo che vive dentro le pipeline. Il regolamento UE impone aggiornamenti di sicurezza per almeno cinque anni e la notifica delle vulnerabilità sfruttate entro 24 ore (come previsto dall'articolo 14)[^2], obblighi incompatibili con verifiche manuali sporadiche. Non a caso il legislatore europeo si è mosso dopo che la criminalità informatica ha superato un costo globale di 5,5 trilioni di euro l'anno già nel 2021[^3], con proiezioni che stimano 10,5 trilioni di dollari nel 2025 e 15,63 trilioni nel 2029[^4]. La scala del debito tecnico rende il problema concreto. Il **rapporto OSSRA 2024** rilevava che il 91% dei codebases esaminati conteneva componenti arretrati di dieci versioni o più[^5]. **Nell'edizione 2026 del rapporto OSSRA, il debito resta reale**: il 41% dei componenti nelle codebases è arretrato di dieci versioni o più, il 22% di sei-dieci versioni e il 18% di tre-cinque (solo il 7% è all'ultima versione). Questi dati vanno letti in un contesto in cui la complessità delle codebases aumenta (+35% file count YoY), il numero di componenti aumenta (+30% YoY) ed il numero di vulnerabilità per singola codebase è più che raddoppiato (+107% YoY).[^6] È chiaro quindi che **ripetere una verifica manuale di questo debito tecnico per ogni release, moltiplicata per cinque anni di supporto obbligatorio, è semplicemente insostenibile**. Automatizzare scanner e policy non basta. La responsabilità legale resta in capo al produttore anche quando è una pipeline a eseguire il controllo. Un'automazione architetturalmente corretta e **auditabile** richiede criteri rigorosi di selezione degli strumenti, integrazione nativa nei processi di sviluppo e la consapevolezza che la delega tecnica non trasferisce l'onere legale. ## Cosa significa automatizzare la compliance al Cyber Resilience Act in una pipeline cloud native? Automatizzare la compliance CRA significa trasformare gli obblighi normativi (generazione della SBOM, scansione delle vulnerabilità, firma degli artefatti e blocco dei rilasci non conformi) in controlli eseguiti automaticamente a ogni commit e deployment, integrandoli nel ciclo di vita del software anziché applicarli a valle come verifica documentale. ![Ciclo della Continuous Compliance per il CRA](/images/blog/cra-automatizzare-il-monitoraggio-nelle-pipeline-cloud-native/inline-0.webp) Il fondamento metodologico risiede nell'evoluzione delle pratiche operative, dove **i controlli di sicurezza anticipano la fase di rilascio per integrarsi direttamente nella pipeline**. Questo approccio, noto come **DevSecOps**, traduce in pratica il principio normativo della **security-by-design**. Abbiamo descritto in dettaglio come questo modello integri la sicurezza nel ciclo di vita del software in un'[analisi dedicata al DevSecOps applicato al cloud](/it/blog/cloud-devsecops/), che chiarisce perché i controlli automatizzati aumentino la velocità di rilascio invece di frenarla. Il secondo concetto chiave è la **continuous compliance**. Il CRA impone supporto e aggiornamenti di sicurezza per almeno cinque anni o per la vita utile del prodotto. **La conformità diventa quindi uno stato da mantenere, non un traguardo da raggiungere una volta.** Una libreria sicura oggi può ospitare una CVE critica domani. Le pipeline diventano il braccio operativo che rivaluta la conformità a ogni build, intercettando la deriva prima che raggiunga la produzione. In pratica, quattro obblighi normativi si traducono in meccanismi operativi. La generazione della SBOM avviene a ogni build producendo un formato versionato e leggibile dalle macchine. Parallelamente, la scansione delle vulnerabilità note incrocia i componenti con i database delle CVE. Il processo richiede poi la firma e la verifica della provenienza degli artefatti immessi sul mercato, culminando nell'enforcement delle policy di deployment per bloccare i rilasci che violano i requisiti. L'impatto operativo è misurabile. Secondo la nostra esperienza, un approccio strutturato con integrazione nelle pipeline CI/CD, identificazione delle dipendenze dirette e transitive, incrocio con i database delle vulnerabilità e validazione continua, riduce il tempo medio di risoluzione delle vulnerabilità (MTTR) fino all'80%[^7]. ## Quali strumenti scegliere per il monitoraggio automatico della conformità? Gli strumenti chiave per il monitoraggio CRA in ambiente cloud native sono **Syft** per la generazione della SBOM, **Trivy** o **Grype** per la scansione delle vulnerabilità, **Cosign** e **Sigstore** per la firma e la verifica della provenienza degli artefatti, e **OPA Gatekeeper** o **Kyverno** per bloccare i deployment non conformi su **Kubernetes**. ![Mappa degli strumenti Cloud Native per la conformità CRA](/images/blog/cra-automatizzare-il-monitoraggio-nelle-pipeline-cloud-native/inline-1.webp) La selezione degli strumenti richiede criteri architetturali rigorosi. Adottare una soluzione solo per la sua popolarità genera rapidamente debito operativo. I parametri che valutiamo nei nostri progetti sono cinque: integrazione nativa con la pipeline CI/CD esistente, supporto ai **formati SBOM standard** come **SPDX** e **CycloneDX**, capacità di firma verificabile, modello di enforcement (admission control in produzione contro scanning a build time) e, soprattutto, generazione di evidenze auditabili persistenti. | Categoria | Strumento | Funzione CRA coperta | | ----------------------- | ----------------------- | -------------------------------------------- | | Generazione SBOM | Syft | Inventario componenti in SPDX/CycloneDX | | Scansione vulnerabilità | Trivy, Grype | Incrocio componenti con database CVE | | Firma e provenienza | Cosign, Sigstore | Integrità e catena di custodia artefatti | | Policy enforcement | OPA Gatekeeper, Kyverno | Blocco deployment non conformi su Kubernetes | ### Generazione SBOM e scansione delle vulnerabilità Syft[^8], sviluppato da Anchore, **produce SBOM in formati standard** a partire da immagini container e filesystem, mantenendo separati il momento dell'inventario e quello dell'analisi. La scansione vera e propria spetta a Trivy di Aqua Security[^9] o a Grype, che **incrociano i componenti rilevati con i database delle CVE**. La distinzione operativa rilevante è tra scansione del filesystem, delle immagini container e delle dipendenze transitive. Quest'ultima è spesso la più insidiosa, perché un componente vulnerabile entra tramite una dipendenza di terzo livello che nessuno ha dichiarato esplicitamente. Il trade-off da governare è il rumore: una soglia troppo aggressiva genera falsi positivi che paralizzano la delivery, una troppo permissiva vanifica la copertura. La prioritizzazione per severità e contesto è la leva per mantenere il segnale affidabile. ### Firma degli artefatti e provenienza Cosign, parte del progetto Sigstore[^10], firma le immagini dei container e garantisce integrità e provenienza, con workflow sia key-based sia keyless basati su chiavi effimere e un log di trasparenza a prova di manomissione. Questo allinea la pipeline al framework **SLSA** per l'integrità degli artefatti. Per il CRA **la firma è centrale perché dimostra la catena di custodia degli artefatti immessi sul mercato**. Un'immagine firmata e verificabile è la prova tecnica che il prodotto distribuito è quello costruito dalla pipeline, non un binario alterato a valle. Essendo membri di CNCF e OpenSSF, abbiamo costruito competenza diretta su questi strumenti, condivisa anche in un [evento tecnico verticale sulla software supply chain security](/it/eventi/tomm-supply-chain-security/) dedicato all'uso operativo di Sigstore e Kyverno. ### Policy enforcement su Kubernetes OPA Gatekeeper e Kyverno operano come admission controller. Intercettano le richieste di deployment e **bloccano in tempo reale i container privi di firma valida o con vulnerabilità critiche**, prima che raggiungano il cluster. È il punto in cui la policy smette di essere una raccomandazione e diventa un vincolo applicato. La scelta tra i due dipende da chi gestisce le policy. OPA Gatekeeper usa Rego, un linguaggio espressivo ma con una curva di apprendimento ripida. Kyverno, policy engine CNCF graduated, definisce policy native Kubernetes in YAML, risultando più leggibile per team compliance non specializzati in linguaggi di policy. Il criterio decisionale si basa su quanto le policy debbano restare ispezionabili da chi risponde dell'audit. ## Come integrare i controlli di policy as code nelle pipeline DevSecOps I controlli si integrano definendo **policy as code** versionate nello stesso repository del codice, eseguendole come gate bloccanti nelle pipeline CI/CD e applicandole in produzione tramite admission controller su Kubernetes. Questo approccio **GitOps** rende ogni modifica tracciabile e dimostrabile agli enti certificatori. ![Flusso end-to-end della pipeline GitOps con gate di compliance](/images/blog/cra-automatizzare-il-monitoraggio-nelle-pipeline-cloud-native/inline-2.webp) Il flusso end-to-end attraversa stadi precisi, producendo per ciascuno un'evidenza persistente. Il commit del codice innesca la pipeline, avviando la generazione della SBOM con Syft sull'artefatto appena costruito. Subito dopo, Trivy o Grype eseguono la scansione delle vulnerabilità contro i database CVE. Se i controlli passano, l'immagine viene firmata con Cosign e registrata nel log di trasparenza Sigstore. Un gate di policy in CI valuta i risultati complessivi per decidere se autorizzare il proseguimento, lasciando infine all'admission control al deployment, gestito da Kyverno o OPA Gatekeeper, il compito di verificare firma e conformità prima dell'ingresso effettivo nel cluster. **L'approccio GitOps garantisce che la compliance sia ripetibile.** Le policy vivono in un repository versionato, ogni modifica passa da pull request e review, ogni decisione lascia una traccia firmata. Questo è esattamente il livello di rigore richiesto per i prodotti che il CRA classifica come critici: container runtime e hypervisor rientrano nell'Allegato III come prodotti di Classe II ad alto rischio[^11], soggetta ad audit obbligatorio da enti certificatori indipendenti. Il modello architetturale di riferimento per impostare questi controlli è descritto nel [white paper della CNCF sulla sicurezza cloud native](/it/landing/guida-security-cncf/), che fornisce il framework di alto livello su cui costruire le policy concrete. **Il trade-off operativo più delicato è tra gate bloccanti e gate informativi.** Bloccare ogni singola vulnerabilità ferma la delivery e spinge i team ad aggirare i controlli; informare soltanto, senza bloccare, vanifica la compliance perché nessuno agisce sui report. La strategia che adottiamo è il **blocco selettivo** per severità e contesto: si bloccano le vulnerabilità critiche con exploit noto e gli artefatti non firmati, si segnalano le altre con SLA di remediation. Il platform engineering riduce il carico cognitivo fornendo pipeline pre-configurate che rendono la conformità lo stato di default. ## Perché l'automazione non trasferisce la responsabilità legale del CRA? Automatizzare scanner e policy nelle pipeline non sposta la responsabilità legale dal produttore allo strumento. Il CRA attribuisce la responsabilità a chi immette il prodotto sul mercato: anche se è una pipeline a eseguire il controllo, è l'azienda a rispondere delle vulnerabilità e a rischiare le sanzioni. ![I pilastri dell'automazione auditabile per la due diligence legale](/images/blog/cra-automatizzare-il-monitoraggio-nelle-pipeline-cloud-native/inline-3.webp) Il principio normativo stabilisce che il **produttore resta responsabile** della conformità anche quando il controllo è delegato a un sistema automatico o a un modello di AI. Le sanzioni, definite all'articolo 64, rendono concreto il rischio, fino a 15 milioni di euro o al 2,5% del fatturato annuo globale, a seconda di quale valore sia superiore, oltre alla possibilità per le autorità di imporre il ritiro del prodotto dal mercato[^12]. Comprendere se il proprio software rientra nelle classi di rischio più severe è il prerequisito di qualsiasi strategia di automazione. Abbiamo dedicato un'analisi alle [classi di rischio del CRA e alle responsabilità dei produttori](/it/blog/come-capire-se-il-tuo-prodotto-software-rientra-nel-cyber-resilience-act/) che inquadra dove cade ciascun prodotto. La conseguenza architetturale impone che **l'automazione sia** **auditabile**. Non basta che la pipeline esegua i controlli, deve **produrre evidenze immutabili e tracciabili** che dimostrino la due diligence in caso di incidente o audit. Nei progetti enterprise questo significa conservare: * **SBOM versionate** per ogni release, riconducibili al commit che le ha generate. * **Report di scansione archiviati** con timestamp e database CVE di riferimento. * **Firme e log di trasparenza** Sigstore che attestano la provenienza degli artefatti. * **Log delle decisioni di policy**, firmati, che documentano cosa è stato bloccato e perché. **Queste evidenze permettono di rispondere agli obblighi CRA di notifica** delle vulnerabilità sfruttate entro i tempi stretti previsti dal regolamento, dimostrando di aver agito con diligenza. Esiste inoltre il tema della **responsabilità condivisa** in ambiente cloud native, dove convivono chi sviluppa il codice, chi gestisce la piattaforma e chi opera in produzione. Policy as code e admission control definiscono confini espliciti tra questi ruoli e riducono l'errore umano, perché il vincolo è codificato e non affidato alla disciplina del singolo. Il nostro CTO, Paolo Mainardi[^13], è Advisory Member della Linux Foundation Europe e ha contribuito all'iniziativa #FixTheCRA, nata per conciliare i requisiti di sicurezza del regolamento con la sostenibilità dell'ecosistema open source[^14]. ## Conclusione La compliance CRA automatizzata non è un costo, ma un acceleratore di qualità che riduce il debito tecnico e abbassa il tempo medio di risoluzione delle vulnerabilità. Il filo conduttore richiede strumenti adeguati, integrazione nativa nelle pipeline ed evidenze auditabili. Sganciare uno di questi tre elementi compromette l'intero impianto. **Se la tua pipeline esegue scanner ma non conserva evidenze firmate e versionate, non sei pronto per un audit CRA**, indipendentemente da quanti tool hai integrato. La differenza tra un'automazione che protegge l'azienda e una che genera solo rumore risiede nella tracciabilità persistente di ogni decisione. Tradurre questi criteri in una strategia tecnica affidabile richiede competenze trasversali tra cloud native, sicurezza e compliance, un profilo che abbiamo sintetizzato nei [requisiti per scegliere un partner tecnologico nella transizione cloud native](/it/blog/i-4-requisiti-del-partner-tecnologico-per-la-transizione-verso-il-cloud-native/). Se vuoi valutare la maturità della tua pipeline rispetto agli obblighi CRA, il team SparkFabrik può aiutarti a identificare i gap architetturali prima delle scadenze del 2027: scopri i nostri servizi di [supply chain security](/it/servizi/cloud-native-services/supply-chain-security/) o [contatta i nostri esperti](/it/contatti/). Nel prossimo articolo della serie, dedicato alla distinzione tra contributori open source e produttori commerciali secondo il CRA, analizzeremo come si ripartisce la responsabilità lungo la catena dei componenti e perché la differenza tra contribuire e immettere sul mercato cambia radicalmente gli obblighi: dal 90% stimato di prodotti in autovalutazione fino agli scenari in cui un singolo contributor upstream rischia di essere chiamato a rispondere di un uso del tutto inatteso del proprio codice[^15]. ## Note e fonti [^1]: **Cyber Resilience Act**, The EU Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, establishes mandatory cybersecurity requirements for hardware and software products with digital elements placed on the EU market. (fonte: ) [^2]: **la notifica delle vulnerabilità sfruttate entro 24 ore (come previsto dall'articolo 14)**, Testo ufficiale: l'articolo 14 conferma l'allerta precoce entro 24 ore. (fonte: ) [^3]: **la criminalità informatica ha superato un costo globale di 5,5 trilioni di euro l'anno già nel 2021**, La documentazione CRA conferma esplicitamente il costo di 5,5 trilioni di euro raggiunto nel 2021. (fonte: ) [^4]: **proiezioni che stimano 10,5 trilioni di dollari nel 2025 e 15,63 trilioni di dollari nel 2029**, confermano il trend di aumento del costo dei crimini informatici. (fonte: ) [^5]: Il rapporto OSSRA 2024 rivela che il 91% dei repository di codice esaminati include componenti arretrati di 10 versioni o più, evidenziando la profondità del debito tecnico accumulato nella gestione delle dipendenze software. (fonte: [SBOM e Cyber Resilience Act: mappare i rischi delle dipendenze](/it/blog/sbom-e-cyber-resilience-act-mappare-i-rischi-delle-dipendenze/)) [^6]: **Open Source Security and Risk Analysis (OSSRA)**, Il report annuale Black Duck Open Source Security and Risk Analysis analizza i rischi di sicurezza, licenza e operatività dei componenti open source nelle codebase commerciali esaminate. (fonte: ) [^7]: L'approccio strutturato alla gestione delle SBOM con integrazione nelle pipeline CI/CD, che include identificazione diretta e transitiva delle dipendenze, incrocio con database delle vulnerabilità e validazione continua con blocco selettivo, consente secondo SparkFabrik di ridurre il tempo medio di risoluzione delle vulnerabilità fino all'80%. (fonte: [SBOM e Cyber Resilience Act: mappare i rischi delle dipendenze](/it/blog/sbom-e-cyber-resilience-act-mappare-i-rischi-delle-dipendenze/)) [^8]: **Syft**, Syft is an open-source CLI tool and Go library by Anchore used to generate a Software Bill of Materials (SBOM) from container images and filesystems. (fonte: ) [^9]: **Trivy**, Trivy is an open-source vulnerability and misconfiguration scanner by Aqua Security. It analyzes container images, filesystems, repositories, and Kubernetes clusters for security issues. (fonte: ) [^10]: **Sigstore**, Sigstore is an open-source framework by the OpenSSF that enables developers to securely sign and verify software artifacts using ephemeral keys and a tamper-resistant public transparency log. (fonte: ) [^11]: Il Cyber Resilience Act classifica tecnologie open source fondamentali come sistemi operativi per server, desktop e dispositivi mobili, hypervisor e runtime dei container nella classe II dei prodotti critici, quella soggetta ai requisiti di sicurezza informatica più severi. (fonte: [Il Cyber Resilience Act, la competitività Europea e la sovranità digitale dell'UE](/it/blog/cyber-resilience-act-competitivit%C3%A0-europea-sovranit%C3%A0-digitale-ue/)) [^12]: Il CRA (articolo 64) prevede sanzioni fino a milioni di euro o a una percentuale del fatturato globale annuo per le violazioni più gravi, con la possibilità per le autorità nazionali di imporre ritiro o richiamo di prodotti, divieto di immissione sul mercato e obbligo di notificare vulnerabilità o incidenti entro tempi molto stretti. (fonte: [Cyber Resilience Act (CRA)](/it/risorse/hot-topics/cra-cyber-resilience-act/)) [^13]: **Paolo Mainardi, Linux Foundation Europe**, Paolo Mainardi is the CTO and co-founder of SparkFabrik and serves on the Advisory Board of Linux Foundation Europe. He specializes in cloud-native technologies and open-source advocacy. (fonte: ) [^14]: Il CTO di SparkFabrik, Paolo Mainardi, è Advisory Member della Linux Foundation Europe e contribuisce all'iniziativa #FixTheCRA, nata per conciliare i requisiti di sicurezza del Cyber Resilience Act con la sostenibilità dell'ecosistema open source. (fonte: [Cyber Resilience Act (CRA)](/it/risorse/hot-topics/cra-cyber-resilience-act/)) [^15]: Il Cyber Resilience Act non distingue tra sviluppo collaborativo a monte e introduzione sul mercato, e non limita la responsabilità all'uso previsto dal produttore: questo rischia di rendere i contributori open source upstream responsabili delle vulnerabilità anche in contesti d'uso del tutto inaspettati, come illustrato da Mirko Boehm della Linux Foundation Europe con l'esempio di un contributor che diventerebbe responsabile se il suo codice venisse usato a valle per controllare una centrale nucleare. (fonte: [Il Cyber Resilience Act e le Preoccupazioni per l'Open Source](/it/blog/cra-e-open-source/)) [^16]: **Il CRA attribuisce la responsabilità a chi immette il prodotto sul mercato, con sanzioni fino a 15 milioni di…**, Testo ufficiale del regolamento che conferma sanzioni e responsabilità dei fabbricanti. (fonte: ) --- ## Domande Frequenti ### Cosa significa DevSecOps nel contesto del Cyber Resilience Act? DevSecOps significa integrare i controlli di sicurezza come gate automatici nelle pipeline CI/CD, spostandoli a sinistra (shift-left) nel ciclo di sviluppo. Nel contesto del CRA è il modello operativo che soddisfa il requisito di security-by-design, perché verifica SBOM, vulnerabilità e firma a ogni commit invece che con un'ispezione finale. ### Quali strumenti servono per automatizzare la compliance CRA in ambiente cloud native? Gli strumenti principali sono Syft per generare la SBOM, Trivy o Grype per la scansione delle vulnerabilità, Cosign con Sigstore per firmare e verificare la provenienza degli artefatti, e OPA Gatekeeper o Kyverno come admission controller su Kubernetes per bloccare i deployment non conformi. Insieme coprono i quattro obblighi CRA automatizzabili. ### L'automazione dei controlli di sicurezza trasferisce la responsabilità legale del CRA? No. Il produttore resta responsabile della conformità anche quando il controllo è eseguito da una pipeline o da un modello di AI. Il CRA attribuisce la responsabilità a chi immette il prodotto sul mercato, con sanzioni fino a 15 milioni di euro o al 2,5% del fatturato annuo globale.[^16] L'automazione deve quindi essere auditabile. ### Qual è la differenza tra OPA Gatekeeper e Kyverno per l'enforcement delle policy? OPA Gatekeeper usa Rego, un linguaggio espressivo ma con una curva di apprendimento ripida. Kyverno definisce policy native Kubernetes in YAML, più leggibili per i team compliance. Il criterio di scelta dipende da chi gestisce le policy e da quanto devono restare ispezionabili da chi risponde dell'audit. ### Il Cyber Resilience Act richiede la SBOM in modo continuo o una tantum? In modo continuo. La SBOM va generata e aggiornata automaticamente a ogni build, perché il CRA impone supporto e aggiornamenti di sicurezza per almeno cinque anni o per la vita utile del prodotto. Una SBOM statica redatta a fine progetto non copre le vulnerabilità che emergono durante l'intero ciclo di supporto. --- ## Articoli Correlati - [AgentOps: governare e monitorare gli agenti AI in produzione](https://www.sparkfabrik.com/it/blog/agentops-governare-e-monitorare-gli-agenti-ai-in-produzione/) - I sistemi basati su modelli probabilistici richiedono un cambio di paradigma rispetto al … - [Harness per agenti AI: la grande divergenza del pricing](https://www.sparkfabrik.com/it/blog/harness-per-agenti-ai-la-grande-divergenza-del-pricing/) - Il valore reale dell'intelligenza artificiale non risiede più solo nel modello, ma … - [Perché i CTO scelgono Drupal: AI, sovranità e platform engineering](https://www.sparkfabrik.com/it/blog/perche-i-cto-scelgono-drupal-ai-sovranita-e-platform-engineering/) - Le architetture enterprise moderne richiedono basi solide per gestire dati critici e integrazioni … --- *Questa è una versione in Markdown dell'articolo per facilitare la lettura da parte di AI e crawler.* *Visita [https://www.sparkfabrik.com/it/blog/cra-automatizzare-il-monitoraggio-nelle-pipeline-cloud-native/](https://www.sparkfabrik.com/it/blog/cra-automatizzare-il-monitoraggio-nelle-pipeline-cloud-native/) per la versione completa con immagini e formattazione.*