Framework SLSA: guida completa ai livelli di sicurezza e strategie di implementazione per la Software Supply Chain
L’ecosistema digitale contemporaneo poggia su fondamenta invisibili ma critiche: la catena di approvvigionamento del software. Ogni applicazione moderna integra centinaia di dipendenze, librerie e componenti esterni, creando una superficie di attacco che si estende ben oltre i confini del codice proprietario. Gli attacchi alla supply chain software hanno registrato un incremento del 200% nel 2023 rispetto all’anno precedente secondo il State of the Software Supply Chain Report di Sonatype, trasformando quello che era un vettore di attacco marginale in una minaccia sistemica per l’intero ecosistema tecnologico globale.
L’attacco a SolarWinds nel dicembre 2020 ha rappresentato un punto di non ritorno: la compromissione del processo di build ha permesso la distribuzione di aggiornamenti malevoli a oltre 18.000 organizzazioni, incluse agenzie governative statunitensi e corporation Fortune 500. Questo evento ha catalizzato la nascita di SLSA, un framework che ambisce a definire standard universali per la sicurezza della software supply chain.
Che cos’è il Framework SLSA: origini e architettura concettuale
SLSA (pronunciato “salsa”) è l’acronimo di Supply-chain Levels for Software Artifacts. Sviluppato originariamente da Google e successivamente adottato dalla Open Source Security Foundation (OpenSSF) come progetto community-driven, SLSA rappresenta un framework di sicurezza che definisce requisiti progressivi per proteggere l’integrità degli artefatti software durante l’intero ciclo di vita della produzione.
La filosofia architetturale di SLSA si distingue per tre caratteristiche fondamentali.
La prima è la progressività strutturata: anziché imporre requisiti monolitici, il framework articola la sicurezza in livelli incrementali che permettono un’adozione graduale, calibrata sulla maturità organizzativa e sulle risorse disponibili.
La seconda è la verificabilità empirica: ogni requisito SLSA è progettato per essere verificabile attraverso evidenze oggettive, principalmente mediante attestazioni crittograficamente firmate che documentano la provenance degli artefatti.
La terza è l’agnosticismo tecnologico: il framework prescinde da specifiche tecnologie o piattaforme, concentrandosi su principi universali applicabili a qualsiasi stack tecnologico.
La specifica corrente, SLSA v1.0, rilasciata il 19 aprile 2023, ha consolidato anni di iterazioni e feedback dalla community, introducendo una struttura più coerente e requisiti più pragmatici rispetto alle versioni precedenti. Una novità significativa della v1.0 è la suddivisione dei requisiti in track separati: la versione attuale definisce il Build Track con i livelli 1-3, mentre altri track (come il Source Track) sono previsti per versioni future.
Anatomia dei livelli SLSA: dal livello 0 al livello 3
Il framework SLSA nella versione 1.0 articola la maturità della supply chain security attraverso il Build Track, che comprende quattro livelli progressivi (da L0 a L3). Ciascun livello è caratterizzato da requisiti specifici che rafforzano le garanzie di integrità e provenance degli artefatti software.
Build L0: assenza di requisiti
Il livello zero rappresenta l’assenza di SLSA: nessun requisito è soddisfatto e non esistono garanzie di integrità degli artefatti. Questo livello descrive lo stato di partenza della maggior parte dei progetti software prima dell’adozione del framework.
Build L1: documentazione della provenance
Il primo livello operativo rappresenta il punto di ingresso nel framework e si focalizza sulla creazione di una traccia documentale del processo di build.
Il Livello 1 richiede che il processo di build produca attestazioni di provenance che documentino quale sorgente è stata utilizzata, quale processo di build è stato eseguito e quali artefatti sono stati generati. Queste attestazioni seguono il formato standardizzato in-toto, un framework per la supply chain integrity sviluppato alla NYU Tandon School of Engineering e ora progetto graduated della Cloud Native Computing Foundation.
La provenance al Livello 1 non richiede ancora garanzie crittografiche robuste: l’obiettivo primario è stabilire visibilità sul processo di build, creando le fondamenta per i livelli successivi. Come specificato nella documentazione SLSA, questo livello può essere facilmente aggirato o falsificato, ma fornisce comunque benefici significativi per audit e incident response.
Sebbene le garanzie di sicurezza al Livello 1 siano limitate, l’adozione di questo livello fornisce immediate capacità di tracciamento. In caso di vulnerabilità scoperta in una dipendenza, l’organizzazione può rapidamente identificare quali build sono potenzialmente compromessi.
Build L2: attestazioni firmate e build service autenticato
Il Livello 2 introduce requisiti crittografici che trasformano le attestazioni di provenance da semplici documenti a evidenze verificabili.
Le attestazioni di provenance devono essere crittograficamente firmate utilizzando chiavi gestite dal servizio di build. Questo garantisce che le attestazioni non possano essere falsificate o modificate retroattivamente senza invalidare la firma.
Il processo di build deve essere eseguito su un hosted build service che implementi controlli di autenticazione e autorizzazione. Piattaforme come GitHub Actions, Google Cloud Build e GitLab CI/CD offrono funzionalità native per la generazione di attestazioni SLSA Livello 2.
Il Livello 2 introduce un significativo incremento della fiducia: le attestazioni firmate permettono a consumatori terzi di verificare l’autenticità della provenance senza dover fidarsi implicitamente del produttore del software.
Build L3: isolamento del build e hardening della piattaforma
Il Livello 3 rappresenta il massimo livello di sicurezza attualmente definito nella specifica v1.0, introducendo requisiti architetturali che proteggono il processo di build da manipolazioni interne.
Il build deve essere eseguito in un ambiente isolato che impedisca interferenze da altri processi o build concorrenti. L’isolamento deve garantire che il processo di build non possa essere influenzato da fattori esterni non documentati nelle attestazioni di provenance.
La piattaforma di build deve implementare meccanismi di hardening che prevengano la compromissione del sistema di generazione delle attestazioni, anche in presenza di codice sorgente malevolo. Questo requisito, noto come unforgeable provenance, impone che la generazione e firma delle attestazioni avvenga in un dominio di sicurezza separato dal codice in esecuzione.
La specifica SLSA Build Track dettaglia i requisiti tecnici per l’isolamento, includendo la necessità di ambienti effimeri che vengono distrutti dopo ogni build, l’impossibilità per i custom build steps di accedere ai materiali crittografici usati per firmare la provenance, e l’isolamento completo tra build differenti anche all’interno dello stesso progetto.
Il Livello 3 fornisce garanzie contro minacce interne e compromissioni del processo di sviluppo. Anche se un attaccante ottiene accesso al repository sorgente o al sistema CI/CD, la generazione di attestazioni fraudolente risulta significativamente più complessa.
Prospettive future: Build L4 e Source Track
La specifica SLSA v1.0 si concentra deliberatamente sul Build Track con livelli 1-3, rimandando a versioni future requisiti più avanzati. Come indicato nella documentazione What’s New in SLSA v1.0, sono previsti sviluppi che includono un Build Level 4 (con requisiti come il two-party review e i reproducible builds) e un Source Track dedicato alla protezione dell’integrità del codice sorgente.
Questa scelta architetturale riflette un approccio pragmatico: consolidare requisiti stabili e implementabili prima di estendere l’ambito del framework.
Implementazione pratica del Framework SLSA
L’adozione del framework SLSA richiede un approccio metodico che integri modifiche tecnologiche, processuali e organizzative. Le seguenti linee guida delineano un percorso di implementazione strutturato.
Fase 1: assessment e gap analysis
Prima dell’implementazione, è essenziale condurre una valutazione dello stato corrente della supply chain. La specifica SLSA fornisce criteri dettagliati che possono essere utilizzati come checklist per identificare gap rispetto ai requisiti di ciascun livello.
L’assessment dovrebbe mappare le piattaforme di build attualmente utilizzate e le loro capacità native di attestazione, i processi di code review esistenti, le pratiche di gestione delle dipendenze e la visibilità sulla loro provenance, e le capacità di verifica delle attestazioni nei processi di deployment.
Fase 2: infrastruttura di attestazione
L’implementazione delle attestazioni SLSA richiede l’integrazione di componenti specifici nella pipeline CI/CD. I SLSA GitHub Generators offrono implementazioni di riferimento per GitHub Actions che generano automaticamente attestazioni conformi.
Per ambienti enterprise, Sigstore, un progetto OpenSSF, fornisce un’infrastruttura completa per la firma e verifica delle attestazioni, includendo Fulcio (Certificate Authority per identità effimere), Rekor (Transparency log immutabile per attestazioni) e Cosign (strumento per firma e verifica di container e artefatti).
L’integrazione con SLSA Verifier permette la validazione automatizzata delle attestazioni durante i processi di deployment, garantendo che solo artefatti con provenance verificata raggiungano gli ambienti di produzione.
Fase 3: hardening del build environment
Il raggiungimento del Livello 3 richiede investimenti significativi nell’hardening dell’infrastruttura di build. Le raccomandazioni del NIST Secure Software Development Framework (SSDF) forniscono guidance complementare per l’implementazione di ambienti di build sicuri.
Elementi critici includono l’implementazione di build ermetici che isolino completamente il processo, la separazione dei privilegi tra l’ambiente di esecuzione del build e il sistema di attestazione, il monitoring e logging completo delle operazioni di build per finalità forensi, e la rotazione periodica delle chiavi di firma con audit dei meccanismi di accesso.
Fase 4: integrazione organizzativa
L’aspetto organizzativo risulta critico per il successo dell’implementazione. Anche se il two-party review formale è previsto per livelli futuri, stabilire processi robusti di revisione del codice fin dalle prime fasi dell’adozione SLSA prepara l’organizzazione per requisiti più stringenti.
Le best practice includono la definizione di policy chiare per la revisione del codice, il training dei team di sviluppo sui principi SLSA e sulle procedure operative, l’integrazione dei controlli SLSA nei processi di vendor assessment per dipendenze esterne, e il reporting periodico sulla conformità e sui gap identificati.
Ecosistema e interoperabilità: SLSA nel contesto normativo
Il framework SLSA non opera in isolamento ma si integra in un ecosistema più ampio di standard e normative per la software security.
Sinergie con SBOM e VEX
L’Executive Order 14028 dell’amministrazione Biden, firmato il 12 maggio 2021, ha imposto requisiti di Software Bill of Materials (SBOM) per i fornitori del governo federale USA. SLSA e SBOM sono complementari: mentre SBOM documenta i componenti presenti nel software, SLSA attesta la provenance e l’integrità del processo che ha prodotto quei componenti.
Il formato VEX (Vulnerability Exploitability eXchange), promosso dalla CISA, si integra con le attestazioni SLSA per fornire informazioni sulla applicabilità delle vulnerabilità agli artefatti specifici.
Allineamento con NIS2 e Cyber Resilience Act
La Direttiva NIS2 dell’Unione Europea, applicabile dal 17 ottobre 2024, introduce requisiti espliciti per la sicurezza della supply chain software, particolarmente per operatori di servizi essenziali e fornitori di servizi digitali. L’adozione del framework SLSA costituisce un meccanismo concreto per dimostrare conformità ai requisiti di supply chain risk management previsti dalla direttiva.
Il Cyber Resilience Act, entrato in vigore il 10 dicembre 2024 con piena applicazione prevista dall’11 dicembre 2027, impone requisiti di cybersecurity per prodotti con elementi digitali immessi sul mercato europeo. Il regolamento richiede ai produttori di garantire la sicurezza lungo l’intero ciclo di vita del prodotto, includendo requisiti sulla gestione delle vulnerabilità e sulla trasparenza della supply chain che si allineano strettamente con i principi SLSA.
Prospettive future: SLSA e l’evoluzione della Supply Chain Security
Il framework SLSA rappresenta un punto di partenza, non una destinazione finale, nell’evoluzione della software supply chain security. Diverse direttrici di sviluppo stanno emergendo nella community e nelle organizzazioni di standardizzazione.
Attestazioni per Source Code e dipendenze
Come indicato nella sezione Current Activities del sito SLSA, la community sta lavorando attivamente su nuovi track che estenderanno le garanzie oltre il processo di build. Il Source Track in sviluppo definirà requisiti per la protezione dell’integrità dei repository e per la tracciabilità delle modifiche al codice sorgente. Un Dependency Track è inoltre in fase di elaborazione per affrontare i rischi introdotti dalle dipendenze esterne.
Integrazione con AI/ML Supply Chain
L’emergere di modelli di machine learning come componenti critici delle applicazioni moderne pone sfide uniche per la supply chain security. Iniziative come Model Transparency stanno esplorando l’applicazione di principi SLSA alla provenance dei modelli AI, includendo attestazioni sui dataset di training e sui processi di fine-tuning.
Hardware-Backed Attestations
L’integrazione con tecnologie di attestazione hardware, come Trusted Platform Module (TPM) e Confidential Computing, promette di fornire root of trust basata su hardware per le attestazioni SLSA, elevando ulteriormente le garanzie di integrità.
Conclusioni: SLSA come imperativo strategico
L’adozione del framework SLSA trascende la mera conformità tecnica per configurarsi come imperativo strategico nell’economia digitale contemporanea. In un ecosistema dove la fiducia nel software è prerequisito per qualsiasi transazione digitale, la capacità di attestare rigorosamente la provenance e l’integrità degli artefatti software costituisce un differenziatore competitivo e un requisito per l’operatività in settori regolamentati.
L’implementazione progressiva dei livelli SLSA permette alle organizzazioni di calibrare gli investimenti in sicurezza rispetto al profilo di rischio specifico, evitando sia il sottoinvestimento che espone a compromissioni catastrofiche, sia il sovrainvestimento che drena risorse da altre priorità strategiche.
Il framework SLSA rappresenta la codificazione di principi che la community di sicurezza ha elaborato attraverso decenni di incidenti e lezioni apprese. Con l’entrata in vigore di normative come NIS2 e il Cyber Resilience Act, e con la crescente sofisticazione degli attacchi alla supply chain, la sua adozione non è più questione di “se” ma di “quando” per qualsiasi organizzazione che produca o consumi software in contesti critici.
