Che cos'è SLSA?

Quale problema risolve SLSA?

Può revisionare ogni riga del codice sorgente e distribuire comunque qualcos'altro, perché ciò che gli utenti eseguono è l'output di una build. Se la build viene compromessa, come è accaduto a SolarWinds, un sorgente pulito produce una release avvelenata. SLSA si concentra su questa lacuna: qualcuno può verificare che questo artefatto provenga da questo sorgente, attraverso questo processo?

Livelli SLSA

SLSA organizza i propri requisiti in track. La versione attuale, la 1.2, ha un Build track e un Source track. Il Build track ha quattro livelli.

Livello	Nome	Che cosa richiede	Che cosa offre
Build L0	Nessuna garanzia	Nulla	L0 è l'assenza di SLSA
Build L1	La provenance esiste	Un processo di build coerente e una provenance generata dalla piattaforma di build e fornita ai consumatori	Aiuta a prevenire gli errori, ma è banale da aggirare o falsificare
Build L2	Piattaforma di build ospitata	Le build vengono eseguite su una piattaforma ospitata che genera e firma la provenance, e i consumatori la verificano	Falsificare la provenance richiede ora un attacco esplicito
Build L3	Build rafforzate	Le esecuzioni sono isolate l'una dall'altra e il secret di firma è fuori dalla portata dei passaggi di build definiti dall'utente	Falsificare la provenance richiede lo sfruttamento di una vulnerabilità, cosa fuori dalla portata della maggior parte degli avversari

I livelli non sono un voto da massimizzare. Ognuno protegge da minacce specifiche, quindi scelga il livello adatto al Suo rischio. I maintainer open source con un servizio CI ospitato possono spesso arrivare a L2 senza molto lavoro.

Che cos'è la provenance?

La provenance è un registro di come è stato realizzato un artefatto. In SLSA indica quale piattaforma lo ha compilato, da quale sorgente, con quale processo e con quali input di primo livello. A partire da L2 la provenance è firmata, quindi un consumatore può verificare che provenga dalla piattaforma di build e che non sia stata alterata.

Si può pensare a una SBOM come agli ingredienti e alla provenance come a dove e come è stato cucinato il piatto. Rispondono a domande diverse e funzionano bene insieme: una SBOM elenca che cosa c'è dentro, mentre la provenance dice da dove viene l'artefatto.

Come adottare SLSA

1. Compili in CI, sempre nello stesso modo. Smetta di fare release dai portatili. Questa è gran parte del lavoro per raggiungere L1.
2. Generi la provenance. Su GitHub, le artifact attestations producono provenance firmata. Veda come funzionano le attestazioni con le SBOM in GitHub Actions.
3. La verifichi dove conta. Una provenance firmata che nessuno controlla non protegge nessuno. Aggiunga la verifica alla fase di deployment o all'admission controller.
4. Rafforzi la build. Isoli le esecuzioni e tenga le chiavi di firma lontane dai passaggi di build. Veda la sicurezza dei runner a confronto.
5. Chieda alle Sue dipendenze. Preferisca i pacchetti che pubblicano la provenance, come oggi consentono registry quali npm.

Che cosa SLSA non copre

• Vulnerabilità. Un artefatto compilato alla perfezione può contenere un difetto. SLSA non dice nulla sulla sicurezza del codice.
• Sorgente malevolo. Se un attaccante esegue un commit nel repository, la provenance registra fedelmente una build di quel codice. Il Source track affronta una parte di questo problema.
• Ciò che la build ha scaricato. La provenance elenca gli input di primo livello. Nulla nel Build track richiede un elenco completo delle dipendenze, ed è a questo che serve una SBOM.
• Insider fidati. La backdoor di xz è arrivata tramite un maintainer fidato, e SLSA da solo non l'avrebbe fermata.

SLSA e gli altri framework

SLSA va in profondità sull'integrità della build. Il NIST SSDF è molto più ampio: copre lo sviluppo sicuro nel suo insieme, inclusa una pratica sulla protezione e l'archiviazione delle release che la provenance SLSA supporta. SLSA è un progetto dell'OpenSSF e molti team usano entrambi. Per il quadro più ampio, veda che cos'è la sicurezza della software supply chain.

Dove si colloca CRACI

CRACI non produce provenance firmata e non rivendica alcun livello SLSA, quindi se Le serve usi le artifact attestations di GitHub o un servizio simile. CRACI aggiunge ciò che SLSA tralascia: un registro completo di ciò che ogni job GitHub Actions ha scaricato. Ogni job viene eseguito nella propria macchina virtuale isolata, ogni pacchetto che scarica finisce in una SBOM e una policy di egress blocca le connessioni di cui la build non ha bisogno. Veda la generazione di SBOM in fase di build.

SLSA: domande frequenti

Che cosa significa SLSA?

Supply-chain Levels for Software Artifacts. Si pronuncia "salsa".

Quali sono i livelli SLSA?

Il Build track ne ha quattro: L0, nessuna garanzia; L1, la provenance esiste; L2, una piattaforma di build ospitata che firma la provenance; e L3, build rafforzate con esecuzioni isolate e secret di firma protetti. La versione 1.2 aggiunge anche un Source track.

Che cos'è la provenance SLSA?

Un registro di come è stato compilato un artefatto: quale piattaforma, da quale sorgente, con quale processo e con quali input di primo livello. A partire da Build L2 è firmata, quindi i consumatori possono verificarla.

Qual è la differenza tra SLSA e una SBOM?

Una SBOM elenca che cosa c'è dentro un software. La provenance SLSA descrive come e dove è stato compilato. In genere servono entrambe.

SLSA è obbligatorio?

No. È un framework volontario della community OpenSSF. Alcuni clienti e organizzazioni possono richiedere un livello, ma non è una legge.

A quale livello SLSA conviene puntare?

Inizi da Build L1 compilando in CI e generando la provenance, poi passi a L2 su una piattaforma ospitata, che molti team possono raggiungere rapidamente. L3 è adatto alle release da cui dipendono molti altri o che comportano un rischio elevato.