Strumenti e piattaforme per la sicurezza della software supply chain (2026)

A chi è rivolta questa pagina

Lei ha ricevuto il mandato di "mettere in sicurezza la nostra software supply chain" e deve decidere dove destinare il budget. Gli strumenti qui sotto operano in punti diversi: su repository e pipeline, sul runner di build, sul registry dei pacchetti o sull'artefatto finito. Noi sviluppiamo CRACI, che compete direttamente in questa categoria: ne tenga conto. Descriviamo ogni strumento a partire dalla sua documentazione e diciamo dove un altro strumento è più adatto.

Che cos'è la sicurezza della software supply chain?

Per la guida completa, veda che cos'è la sicurezza della software supply chain e la checklist delle best practice.

Il Suo software è il Suo codice più tutto ciò da cui dipende: pacchetti open source, immagini base, strumenti di build, action CI di terze parti e la pipeline che li trasforma in una release. La sicurezza della software supply chain consiste nel sapere quali sono queste parti, controllare da dove provengono e dimostrare che cosa è entrato in ogni release. La sicurezza applicativa cerca difetti nel codice che Lei scrive; la sicurezza della supply chain copre ciò che lo circonda.

Gli attaccanti prendono di mira ogni anello. Tre incidenti recenti mostrano dove:

• Una dipendenza. Nel marzo 2024 è stato trovato codice malevolo nelle versioni 5.6.0 e 5.6.1 di xz utils, una libreria di compressione inclusa nelle distribuzioni Linux (CVE-2024-3094).
• La pipeline CI. Nel marzo 2025 la GitHub Action tj-actions/changed-files è stata compromessa (CVE-2025-30066), esponendo secret come chiavi di accesso, personal access token di GitHub e token npm dei workflow che la usavano.
• Il registry dei pacchetti. Nel settembre 2025 il worm autoreplicante Shai-Hulud ha compromesso più di 500 pacchetti npm. Ha rubato credenziali degli sviluppatori, tra cui token GitHub e chiavi cloud, e le ha usate per pubblicare altri pacchetti infetti.

1:53

Quali tipi di strumenti per la sicurezza della software supply chain esistono?

Nessun singolo prodotto copre ogni anello, e i vendor qui sotto intendono cose diverse con "sicurezza della supply chain". La maggior parte delle soluzioni rientra in uno di sette tipi, definiti dal punto in cui operano.

Come scegliere una piattaforma per la sicurezza della software supply chain?

Parta dalla domanda a cui oggi non sa rispondere, poi scelga lo strumento che opera dove si trova quella risposta. Sei domande distinguono rapidamente le opzioni.

• Le serve ampiezza o profondità? Una piattaforma di application security posture management (ASPM) si collega a repository, pipeline e scanner e dà priorità al rischio su tutti questi elementi. Uno strumento a livello di build va più a fondo su un solo punto: che cosa è successo mentre il software veniva compilato.
• Vuole mantenere i Suoi runner? Agenti come StepSecurity Harden-Runner e Cimon di Cycode aggiungono il monitoraggio ai runner che già usa. CRACI sostituisce il runner per GitHub Actions.
• Il rischio è nei Suoi input? Se La preoccupano soprattutto i pacchetti malevoli o le immagini base piene di CVE, gli strumenti che controllano o rafforzano gli input vanno dritti al punto.
• Distribuisce software che non ha compilato? Solo l'analisi dei binari può guardare dentro un pacchetto senza la sua build.
• Quali sistemi CI usa? La maggior parte degli strumenti qui presenti ne copre diversi. Oggi CRACI supporta solo GitHub Actions, con GitLab CI e Jenkins in roadmap.
• Che cosa dovrà dimostrare, e a chi? Clienti, auditor e normative come il Cyber Resilience Act dell'UE chiedono sempre più spesso una SBOM per release e un registro di come sono state gestite le vulnerabilità. Una dashboard di risultati non equivale a un'evidenza di ciò che è stato distribuito.

Poi faccia a ogni vendor della Sua shortlist le stesse domande:

• Da dove proviene il vostro elenco di componenti: manifest, analisi dei sorgenti, build o binario finito?
• La SBOM mi dice quando è incompleta, e si esporta in CycloneDX o SPDX?
• Potete impedire a una build di raggiungere un host inatteso, o solo segnalarlo in seguito?
• Posso verificare in seguito che l'artefatto che distribuisco sia quello che è stato compilato?
• Quali sistemi di controllo del codice e CI supportate oggi, e quali sono in roadmap?
• Qual è l'unità di prezzo: sviluppatori, contributor, immagini, build o preventivo?

Come si confrontano gli strumenti?

Gli strumenti si dividono in due forme, quindi le tabelle sono due. La prima confronta piattaforme e strumenti per la sicurezza della build in base a come vedono e controllano la pipeline. La seconda confronta gli strumenti che operano su input e output. "Non dichiarato" significa che le pagine dei vendor che citiamo non lo dicono né in un senso né nell'altro.

Piattaforme e sicurezza della build

Input e output

Quanto costano gli strumenti per la sicurezza della software supply chain?

Cinque dei nove strumenti qui sotto applicano un prezzo per sviluppatore, e la maggior parte vende i piani a pagamento tramite il reparto vendite. CRACI addebita invece solo i minuti di build, quindi il costo segue quanto Lei compila e non quante persone eseguono commit. I prezzi sono quelli pubblicati da ciascun vendor a settembre 2026; Apiiro e Legit Security sono esclusi perché le loro pagine non indicano prezzi.

Il prezzo per sviluppatore cresce con il Suo team; il prezzo per minuto di build cresce con le Sue pipeline. Il prezzo di CRACI include i minuti dei runner, che sostituiscono ciò che paga per i runner ospitati da GitHub. Veda i prezzi di CRACI e i prezzi dei runner a confronto. Per i grafici dei prezzi pubblicati per dimensione del team, con il runner incluso, veda i prezzi della sicurezza della software supply chain a confronto.

CRACI

CRACI è un runner per GitHub Actions. Lei cambia runs-on in craci e, mentre ogni job è in esecuzione, un proxy che riconosce i pacchetti registra ciò che ha scaricato, compresi i pacchetti ripristinati dalle cache CI. Ogni SBOM riporta uno stato di completezza per job e per cache, una policy di egress viene validata prima dell'avvio del job e opera in modalità fail closed, e CRACI continua a rivalutare le SBOM di ciò che è stato distribuito. Ideale per i team che distribuiscono software e devono mostrare che cosa è entrato in ogni release. Attenzione: niente scansione SAST, di secret o IaC, controlli di postura né analisi dei binari, e oggi solo GitHub Actions (GitLab CI e Jenkins sono in roadmap). Generazione di SBOM in fase di build

Piattaforme e ASPM

Apiiro

Apiiro è una piattaforma ASPM. Deep Code Analysis mappa la Sua architettura dal codice al runtime, e il Risk Graph correla i risultati degli scanner di Apiiro e degli strumenti di terze parti in "toxic combinations". Il suo modulo supply chain censisce repository e pipeline, comprese le shadow pipeline, e segnala protezioni dei branch deboli e commit anomali. Si collega tramite API e non richiede modifiche alla CI. Ideale per i grandi programmi AppSec che vogliono il contesto architetturale su molti sistemi di controllo del codice. Attenzione: il suo inventario deriva dall'analisi del codice, non dall'osservazione delle build, e non controlla che cosa può raggiungere una build. CRACI vs Apiiro

Cycode

Cycode è una piattaforma ASPM con scansione SAST, SCA, di secret, container e IaC, postura CI/CD e più di 100 connettori. La sua componente per la build, Cimon, è un agente eBPF che gira dentro i Suoi job CI. Monitora i processi, l'egress di rete e l'accesso ai file, apprende il comportamento normale di una pipeline prima di applicarlo, produce una SBOM osservata a runtime e firma la provenance SLSA. Cycode afferma che Cimon è gratuito e open source. Ideale per una sola piattaforma su codice e molti sistemi CI, con protezione runtime della build sui runner che mantiene. Attenzione: Cimon è un agente aggiunto ai Suoi runner, non il runner stesso. CRACI vs Cycode

OX Security

OX Security è una piattaforma ASPM con scanner propri, aggregazione dei risultati di terze parti da strumenti come Checkmarx, Snyk e Black Duck, e policy di postura CI/CD che segnalano action non fissate, permessi eccessivi dei workflow e webhook rischiosi. La sua Pipeline Bill of Materials (PBOM) è un registro firmato per ogni build con le definizioni della pipeline, l'identità del runner, gli argomenti di build e le firme degli artefatti. Ideale per policy di postura e gating delle pull request su GitHub Actions, GitLab, Jenkins, Azure Pipelines e CircleCI. Attenzione: la sua SBOM viene raccolta dalle fonti collegate, e le sue policy controllano la configurazione della pipeline invece di limitare ciò che un job in esecuzione può raggiungere. CRACI vs OX Security e Alternative a OX Security

Legit Security

Legit Security mappa l'intero ciclo di sviluppo: un inventario aggiornato di continuo di sistemi SDLC e pipeline e dei relativi controlli di sicurezza, con centinaia di policy su controllo del codice, CI e registry. Orchestra scanner come Snyk, Checkmarx e GitHub Advanced Security, aggiunge SAST e SCA nativi, trova secret nei log di build, in Slack e in Confluence oltre che nel codice, e crea SBOM e attestazioni firmate. Ideale per un team di sicurezza che ha ereditato molti repository e diversi sistemi CI e ha bisogno di un unico livello di governance. Attenzione: legge configurazione e output degli scanner tramite API, quindi non vede il traffico di rete di un job durante l'esecuzione. CRACI vs Legit Security e Alternative a Legit Security

Kusari

Kusari nasce dal team che ha co-creato GUAC, il grafo OpenSSF per i metadati della supply chain. La sua piattaforma costruisce un knowledge graph dalle Sue SBOM, dai documenti VEX e dall'output degli scanner, mostra il raggio d'impatto di una nuova vulnerabilità, analizza la raggiungibilità e apre pull request AutoFix che valida prima. Kusari Inspector esamina le pull request alla ricerca di pacchetti malevoli, secret e workflow non sicuri, e Kusari afferma che è gratuito da installare. Ideale per un unico grafo su molte fonti di SBOM e scanner. Attenzione: un grafo riflette le SBOM che riceve, e quelle di Kusari provengono da un generatore (il suo toolkit waybill o un Suo strumento) e non dalla build. CRACI vs Kusari e Alternative a Kusari

Endor Labs

Endor Labs è costruito attorno alla raggiungibilità a livello di funzione: l'analisi statica del programma verifica se il Suo codice può chiamare una funzione vulnerabile in una dipendenza diretta o transitiva, il che secondo Endor Labs riduce i risultati SCA del 92%. L'analisi dell'impatto degli aggiornamenti, le pull request automatizzate e Endor Patches, che esegue il backport delle correzioni alla versione che Lei usa, gestiscono la remediation. Copre anche AI SAST, secret, container, un Package Firewall davanti ai Suoi registry e un SBOM Hub con VEX basato sulla raggiungibilità. Ideale per i team il cui problema principale è il volume di avvisi. Attenzione: il suo inventario deriva dall'analisi del codice sorgente, e non esegue né limita le Sue build. CRACI vs Endor Labs

Sicurezza di build e runner

StepSecurity

StepSecurity Harden-Runner è la sovrapposizione più stretta che CRACI abbia con un vendor di sicurezza. È un agente sui runner GitHub Actions che Lei già usa, compresi quelli ospitati da GitHub, e collega ogni connessione in uscita, processo e scrittura di file allo step del workflow che l'ha causata. Può prima eseguire un audit, costruendo una baseline per job, poi bloccare l'egress verso tutto ciò che è fuori da una allowlist. StepSecurity vende anche Secure Registry, pull request di hardening dei repository e Dev Machine Guard. Ideale per i team che vogliono mantenere runner ospitati da GitHub o self-hosted, o che usano GitLab CI o Azure DevOps. Attenzione: la sua allowlist è un elenco di endpoint, e registra destinazioni invece di una SBOM a livello di pacchetto. CRACI vs StepSecurity

Sicurezza di pacchetti e input

Socket

Socket analizza il comportamento dei pacchetti open source: script di installazione, accesso alla rete e al filesystem, codice offuscato, malware noto e typosquat. Segnala le aggiunte rischiose nelle pull request, e Socket Firewall blocca i pacchetti malevoli in fase di installazione, con una versione gratuita per npm, yarn, pnpm, pip, uv e cargo. Offre anche l'analisi di raggiungibilità. Ideale per fermare i pacchetti malevoli prima che arrivino, compresi quelli che non hanno ancora un advisory. Attenzione: legge i manifest e i lockfile dichiarati da un progetto, e il suo firewall filtra le installazioni dei pacchetti, non il resto del traffico di rete di un job. CRACI vs Socket

Chainguard

Chainguard compila software open source dai sorgenti e lo distribuisce rafforzato: immagini container che definisce zero-CVE, librerie Java, Python e JavaScript ricompilate da sorgenti verificati, immagini VM e GitHub Actions rafforzate, ciascuna con una SBOM firmata e provenance SLSA. Per i clienti con un ordine si impegna a correggere le CVE critiche entro 7 giorni e quelle di altra gravità entro 14 giorni da una patch idonea. Ideale per i team i cui scanner continuano a segnalare CVE nelle immagini base. Attenzione: le sue SBOM e la sua provenance descrivono gli artefatti di Chainguard. La Sua build ha comunque bisogno di un proprio registro, ed è per questo che si abbina bene a uno strumento a livello di build. CRACI e Chainguard

Analisi dei binari

ReversingLabs

ReversingLabs Spectra Assure analizza pacchetti software finiti senza codice sorgente, usando l'analisi statica dei binari, 16 motori di rilevamento del malware e un'analisi differenziale che segnala modifiche sospette tra le versioni. Esporta SBOM CycloneDX e SPDX dal binario e può valutare software commerciale e di terze parti prima che Lei lo distribuisca. Ideale per un gate di release contro malware e manomissioni, e per il software che non ha compilato. Attenzione: lavora a ritroso dall'output, quindi non vede gli strumenti di build né le dipendenze di test che la build ha scaricato ma non distribuito. CRACI vs ReversingLabs

Framework e normative alla base della categoria

Gran parte della domanda per questi strumenti nasce da framework e norme che chiedono un inventario dei componenti, un registro di come è stato compilato il software e un processo per gestire le vulnerabilità.

• SLSA (Supply-chain Levels for Software Artifacts) è un insieme di linee guida adottabili in modo incrementale, mantenuto come collaborazione intersettoriale sotto la Linux Foundation. Il suo Build track valuta quanto sia affidabile la provenance di una build.
• NIST SSDF (SP 800-218, versione 1.1, febbraio 2022) definisce pratiche di sviluppo software sicuro per ridurre le vulnerabilità nel software rilasciato.
• L'Executive Order 14028 degli Stati Uniti, sezione 4(e), ha disposto linee guida sulla software supply chain che includono la fornitura all'acquirente di una SBOM per ogni prodotto. Orienta le linee guida federali sugli acquisti, invece di vincolare direttamente ogni vendor.
• CISA, NSA e ODNI hanno pubblicato nel 2023 "Securing the Software Supply Chain: Recommended Practices Guide for Customers", che copre acquisti, test, deployment, patching e SBOM.
• Il Cyber Resilience Act dell'UE (regolamento (UE) 2024/2847) rende effettivi i suoi obblighi di segnalazione l'11 settembre 2026 e si applica integralmente dall'11 dicembre 2027.
• NIS2, all'articolo 21, paragrafo 2, indica la sicurezza della supply chain e la gestione delle vulnerabilità tra le misure che richiede, e la FDA statunitense richiede una SBOM ai produttori di cyber device.

Nessuno di questi framework indica una categoria di prodotto. Ciò che hanno in comune sono le evidenze: un elenco accurato dei componenti per release, un registro di come è stata compilata e la prova che le vulnerabilità sono state tracciate.

Dove si colloca CRACI?

CRACI è un runner per GitHub Actions. Lei cambia runs-on in craci e, mentre ogni job è in esecuzione, un proxy che riconosce i pacchetti registra ciò che ha scaricato, compresi i pacchetti ripristinati dalle cache CI. Ogni SBOM riporta uno stato di completezza per job e per cache. Una policy di egress, deny predefinito o allow predefinito, viene validata prima dell'avvio del job e opera in modalità fail closed. CRACI continua a rivalutare le SBOM di ciò che è stato distribuito. La vista inventario di CRACI mostra esattamente quali versioni del software sono distribuite in quali prodotti, a livello globale. Il risultato è una SBOM per build, un registro di ciò che ogni build ha raggiunto e dati di provenance dall'API, il che automatizza una parte significativa della visibilità e delle evidenze sulla supply chain di cui il Suo processo CRA ha bisogno.

CRACI non è la scelta giusta se Le servono scansione SAST, di secret o IaC, controlli di postura sui Suoi repository, una modalità audit prima del blocco, blocklist di pacchetti (in roadmap), analisi dei binari o, oggi, sistemi CI diversi da GitHub Actions (GitLab CI e Jenkins sono in roadmap). Molti team lo abbinano a uno degli strumenti qui sopra: una piattaforma ASPM per codice e postura, Socket o Chainguard per gli input, ReversingLabs per l'output. Scopra di più sulla generazione di SBOM in fase di build, sull'integrazione CI/CD e sui prezzi, oppure prenoti una demo per vedere una build registrata dall'inizio alla fine.

Confronti gli strumenti per ogni parte della supply chain

Questa pagina è la panoramica. Ogni area ha il proprio confronto approfondito e le proprie guide.

• SBOM: strumenti SBOM a confronto, generazione di SBOM in fase di build, perché le SBOM in fase di build e come generare una SBOM in GitHub Actions.
• Runner e sicurezza CI/CD: fornitori di runner per GitHub Actions, strumenti per la sicurezza dei runner, checklist di sicurezza della pipeline CI/CD e policy di egress per GitHub Actions.
• Dipendenze: strumenti SCA a confronto, le dipendenze transitive spiegate e che cos'è la software composition analysis.
• Normative: strumenti per la conformità al CRA.
• Perché la build: perché la sicurezza della supply chain va nella CI, la sicurezza della software supply chain con CRACI e perché ne ha bisogno anche il software interno e a basso rischio.

CRACI a confronto con ciascuno strumento

• CRACI e Apiiro a confronto Grafo del rischio dal codice contro evidenze dalla build.
• CRACI e Cycode a confronto ASPM più un agent di build contro il runner di build stesso.
• CRACI e OX Security a confronto PBOM dagli strumenti collegati contro una registrazione dal runner.
• CRACI e Legit Security a confronto Proteggere l'SDLC contro registrare la build.
• CRACI e Kusari a confronto Grafo della supply chain contro SBOM di build con monitoraggio.
• CRACI e ReversingLabs a confronto Analisi binaria dell'output contro evidenze dalla build.
• CRACI e Socket a confronto Analisi del comportamento dei pacchetti contro osservazione della build.
• CRACI e Chainguard a confronto Input sicuri contro una build sicura e registrata.
• CRACI e Xygeni a confronto Piattaforma AppSec con attestazioni di build contro essere il runner di build.
• CRACI e Wiz a confronto Rilevamenti sulla postura dei workflow contro controlli applicati dentro il job.
• CRACI e Safeguard a confronto Scansione e correzione automatica con IA contro la registrazione della build stessa.

Sicurezza della software supply chain: FAQ

Risposte brevi alle domande più frequenti degli acquirenti

Che cosa sono le soluzioni per la sicurezza della software supply chain?

Strumenti che proteggono tutto ciò che entra nel Suo software tra il primo commit e la release: dipendenze open source, immagini base, strumenti di build, pipeline CI e gli artefatti che distribuisce. I tipi principali sono le piattaforme ASPM che mappano il rischio lungo il ciclo di sviluppo, la software composition analysis per le dipendenze, la sicurezza di build e runner, i firewall per pacchetti, le immagini rafforzate, l'analisi dei binari e gli strumenti per SBOM e provenance.

Qual è la migliore piattaforma per la sicurezza della software supply chain?

Non ne esiste una migliore in assoluto, perché ciascuna copre un anello diverso. Le piattaforme ASPM come Apiiro, Cycode, OX Security e Legit Security offrono la copertura più ampia su repository e sistemi CI. Endor Labs si concentra sulla raggiungibilità per i risultati sulle dipendenze, Socket sui pacchetti malevoli, Chainguard sugli input rafforzati e ReversingLabs sui binari finiti. CRACI è la scelta quando Le serve un registro di ciò che ogni build GitHub Actions ha effettivamente introdotto, con controllo dell'egress e dati di provenance.

In che cosa la sicurezza della software supply chain differisce dalla sicurezza applicativa?

La sicurezza applicativa cerca difetti nel codice scritto dal Suo team, con strumenti come SAST e DAST. La sicurezza della software supply chain copre ciò che circonda quel codice: componenti di terze parti, il sistema di build, la pipeline CI e il percorso dalla build alla release. La backdoor di xz utils, la compromissione di tj-actions/changed-files e il worm npm Shai-Hulud sono tutti entrati attraverso la supply chain, non attraverso un bug nel codice delle vittime.

Da quale strumento per la sicurezza della software supply chain conviene iniziare?

Parta dalla domanda a cui oggi non sa rispondere. Se non sa quali dipendenze vulnerabili distribuisce, inizi dalla SCA. Se i pacchetti malevoli La preoccupano di più, valuti un firewall per pacchetti. Se deve dimostrare che cosa è entrato in ogni release, per i clienti o per il Cyber Resilience Act dell'UE, Le serve un registro acquisito durante la build. I grandi programmi con molti repository e sistemi CI spesso aggiungono una piattaforma ASPM al di sopra.

Serve una SBOM per la sicurezza della software supply chain?

Sempre più spesso, sì. Il Cyber Resilience Act dell'UE chiede ai fabbricanti di identificare i componenti dei loro prodotti, anche redigendo una SBOM, e di gestirne le vulnerabilità. La FDA statunitense richiede una SBOM per i cyber device, e l'Executive Order 14028 degli Stati Uniti ha plasmato le linee guida federali che ne chiedono una ai fornitori. Una SBOM è utile solo nella misura in cui è completa, quindi chieda a ogni vendor da dove proviene il suo elenco di componenti e se Le dice quando l'elenco è incompleto.

In che cosa CRACI differisce da uno scanner per la supply chain?

Gli scanner leggono i file a posteriori: un manifest, un lockfile, il codice sorgente o un binario finito. CRACI è un registratore. È il runner dei Suoi job GitHub Actions e, mentre ogni job è in esecuzione, registra i pacchetti effettivamente introdotti dal job, compresi quelli ripristinati dalle cache CI. Ogni SBOM dichiara la propria completezza, una policy di egress controlla che cosa può raggiungere la build e l'API restituisce SBOM, tracce di rete e provenance.

Quali sistemi CI supporta CRACI?

Oggi GitHub Actions; altri sistemi CI sono in roadmap, tra cui GitLab CI e Jenkins. I runner sono Linux su x86-64 e ARM64, con Windows e macOS in roadmap. La maggior parte delle piattaforme in questa pagina copre più sistemi CI, quindi ne tenga conto se usa anche Jenkins o Azure Pipelines.

Quanto costano gli strumenti per la sicurezza della software supply chain?

La maggior parte applica un prezzo per sviluppatore. A settembre 2026, StepSecurity Enterprise costa $16 per sviluppatore che contribuisce al mese e Socket Team $25 per sviluppatore al mese, mentre Cycode, OX Security ed Endor Labs vendono i piani a pagamento tramite il reparto vendite. ReversingLabs Community+ ha un costo fisso di $500 al mese, Chainguard offre fino a cinque immagini gratuite e CRACI addebita solo i minuti di build, $0.002 per vCPU-minuto ($0.004 per un runner predefinito da 2 vCPU), senza canone mensile.