Cosa devi fare per raggiungere i livelli SLSA: una guida molto pratica

sfondo

SLSA (Supply-chain Levels for Software Artifacts) è un framework di sicurezza che mira a prevenire manomissioni, migliorare l'integrità e proteggere pacchetti e infrastrutture. Il concetto centrale di SLSA è che un artefatto software può essere considerato attendibile solo se soddisfa tre requisiti:

1. L'artefatto dovrebbe avere un documento di Provenienza che ne descriva l'origine e il processo di costruzione (L1).
2. Il documento di provenienza dovrebbe essere affidabile e verificato a valle (L2).
3. Il sistema di compilazione dovrebbe essere affidabile (L3).

Il framework SLSA definisce i livelli che rappresentano quanto è sicura la catena di fornitura del software. Questi livelli corrispondono al livello di attuazione di questi requisiti (indicati sopra come L1-L3).

Quello dello Scriba valint slsa il comando può essere utilizzato per produrre documenti di provenienza. Di seguito descriviamo come raggiungere i livelli SLSA utilizzando questo strumento.

Nota: qui facciamo riferimento al framework SLSA V1.0.

SLSA L1

Il requisiti per SLSA L1 includono:

• I produttori di software seguono un processo di creazione coerente.
• La piattaforma di costruzione genera automaticamente dati di provenienza che descrivono come è stato costruito l'artefatto.
• I produttori di software distribuiscono i dati sulla provenienza ai consumatori.

Lista di controllo per raggiungere il livello SLSA L1:

• Costruisci il tuo software utilizzando un sistema CI. Utilizzare preferibilmente uno script di compilazione controllato dal codice sorgente.
• attivare la valint slsa comando come parte dello script di build per creare un documento di provenienza. Si noti che il valint slsa  Il comando consente di aggiungere ulteriori informazioni al documento di Provenienza: puoi personalizzare il contenuto del documento di Provenienza in base alle tue esigenze.

SLSA L2

Il requisiti per SLSA L2 includono:

• I requisiti SLSA L1.
• La build viene eseguita su una piattaforma di build ospitata che genera e firma la provenienza stessa.
• La verifica a valle della provenienza include la convalida dell'autenticità della provenienza.

Lista di controllo per raggiungere il livello SLSA L2:

• La lista di controllo SLSA L1.
• Utilizza un servizio di build ospitato (invece di eseguire la build sul computer dello sviluppatore).
• Creare un documento di provenienza firmato (invece di uno non firmato, che è sufficiente per SLSA L1) Ciò può essere ottenuto eseguendo valint slsa ... -o attest. Quello dello Scriba valente lo strumento ha un'ampia gamma di funzionalità di firma; per un'azienda, consigliamo di utilizzare chiavi e certificati PKI X.509. 
• Verificare l'autenticità del documento di provenienza a valle utilizzando il file valint verifycomando. La verifica può includere la firma e l'identità della firma, nonché altre regole di verifica che garantiscono il contenuto del documento di provenienza SLSA. Alcuni esempi possono essere trovati in Scribe catalogo delle politiche.

Nota: la verifica dovrebbe essere effettuata dal consumatore del software creato; per la conformità interna, la verifica può essere eseguita come parte di una pipeline di test.

SLSA L3

Requisiti SLSA L3

Il requisiti per SLSA L3 includono:

• I requisiti SLSA L2.
• La piattaforma di creazione implementa controlli efficaci per:
  • Evita che le esecuzioni si influenzino a vicenda, anche all'interno dello stesso progetto.
  • Impedisci che i segreti utilizzati per firmare la provenienza siano accessibili dai passaggi di compilazione definiti dall'utente.

Inoltre, per avere fiducia nella piattaforma di creazione, è necessario verificare la piattaforma di creazione. La piattaforma di creazione dovrebbe essere considerata attendibile nel senso in cui lo sarà il documento di provenienza imperdonabile e la build sarà isolato. Da tale verifica derivano i seguenti requisiti:

• Verificarlo l'uso della piattaforma non si interrompe l’indimenticabilità e l’isolamento requisiti.
  • La verifica dell'isolamento, ad esempio, può essere eseguita valutando l'utilizzo della cache nella pipeline.
  • Per garantire l'infalsificabilità del documento di provenienza, consigliamo di generarlo e firmarlo in una pipeline di compilazione dedicata.
• Verifica il file affidabilità della piattaforma di creazione.
  •  Per gli elementi della configurazione SaaS, è necessario effettuare una verifica con il fornitore della piattaforma di compilazione. Nei casi in cui il produttore del software è responsabile della distribuzione del sistema di compilazione, si consiglia una combinazione di autocertificazione del fornitore e di analisi degli aspetti di distribuzione.
  • Ad esempio, quando si distribuisce un CI self-hosted, l'attestazione del fornitore deve dichiarare in che modo le build sono isolate le une dalle altre e l'analisi della distribuzione deve verificare le autorizzazioni di accesso e il controllo dei log del sistema CI.

Questi requisiti sono impegnativi perché soddisfarli dipende dalla piattaforma CI, non può essere completamente automatizzato e richiede un'analisi professionale della sicurezza dei sistemi e delle pipeline di creazione. Questo è il motivo per cui il framework SLSA suggerisce specificamente che le organizzazioni evolvano gradualmente dalla conformità SLSA L2 a SLSA L3.

Se hai letto questo articolo fino a qui e hai deciso che SLSA L3 è la cosa giusta per te, rimboccati le maniche: ecco la nostra lista di controllo consigliata:

Lista di controllo per raggiungere il livello SLSA L3:

• La lista di controllo SLSA L2.
• Valutare il sistema CI. L’obiettivo è rispondere alle seguenti domande:
  • In quali condizioni un'entità non autorizzata può eludere il sistema di compilazione?
  • In quali condizioni le build possono influenzarsi a vicenda?

Una volta risposto, gestisci i rischi rimanenti.

• Isolare la generazione del documento di Provenienza:
  • Separare la creazione del documento di provenienza in una pipeline diversa, preferibilmente in un servizio di compilazione separato.
    • Esporre a questa pipeline solo i segreti utilizzati per firmare il documento di Provenienza.
    • Crea o verifica il contenuto del documento di provenienza su questa pipeline. In caso di verifica, verificare tutti i campi possibili di un documento di provenienza generato in pipeline con i dati raccolti direttamente dalla piattaforma di creazione o da altre fonti attendibili.
• Isolare e verificare l'isolamento della pipeline di compilazione dalle altre esecuzioni della pipeline:
  • Verificare l'utilizzo delle cache e dei volumi condivisi.
  • Verificare che i segreti condivisi con altre pipeline non possano consentire alle pipeline di influenzarsi a vicenda.
  • Verificare che le esecuzioni della pipeline non possano influenzarsi a vicenda
    • Ad esempio, impedire che le installazioni eseguite tramite una pipeline incidano su altre esecuzioni della pipeline. Questo può essere fatto utilizzando build-runner effimeri (come un contenitore creato per ogni build) o verificando che i build-runner inizino ogni volta da uno stato predeterminato.

Per ottenere SLSA L3 con gli strumenti Scribe, consigliamo quanto segue:

• Strumentare la pipeline di compilazione per generare tutte le attestazioni che saranno necessarie per popolare il documento di provenienza. Ad esempio, potresti decidere di volere un elenco delle dipendenze installate durante la compilazione. Questo elenco può essere generato da a valint bom dir:comando. Inoltre, crea un'attestazione di provenienza nella pipeline utilizzando il file valint slsa comando.
• Creare una pipeline di generazione di provenienza attendibile separata che eseguirà quanto segue:
  • Genera un documento di provenienza attendibile basato su quello creato nella pipeline di compilazione;
    • Raccogli i dati dal servizio di compilazione e usali per verificare e aggiornare il documento di provenienza.
    • Verificare il contenuto delle attestazioni create nella pipeline di compilazione. Ad esempio, verificare il contenuto del build-runner confrontando un'attestazione SBOM dalla pipeline di compilazione con un'attestazione SBOM campionata separatamente.
    • Utilizza le attestazioni raccolte dalla pipeline di compilazione per aggiornare il documento di provenienza.
    • L'aggiornamento del documento di provenienza può essere effettuato utilizzando il file valint slsa comando.
  • Verificare che la build sia stata isolata valutando i dati raccolti dal servizio di build. Ad esempio: verifica l'uso di cache e segreti.

Per eseguire tale raccolta e valutazione dei dati, Scribe fornisce strumenti che creano attestazioni per l'esecuzione della build ed eseguono le verifiche necessarie.

---

Va bene. Sembra che tu sia pronto per partire. Naturalmente, se hai bisogno di assistenza, scrivici. Siamo qui per aiutare e ci piacerebbe consigliare o aiutare attivamente.

Post Correlati

Come puoi assicurarti che i tuoi profitti non vengano vanificati dal Memo OMB?

Il governo degli Stati Uniti sta rinnovando le sue politiche di sicurezza informatica. Ciò include il rilascio del Secure Software Development Framework (SSDF) versione 1.1 da parte del National Institute of Standards and Technology (NIST), che mira a ridurre le vulnerabilità della sicurezza lungo il ciclo di vita dello sviluppo software (SDLC). Il documento fornisce ai venditori e agli acquirenti di software “un […]

Versione finale SSDF (NIST 800-218): differenze rispetto alla bozza e relative implicazioni per te

Il 22 marzo il NIST ha rilasciato la versione finale del SSDF 1.1 (Secure software development framework). Daremo un'occhiata ad alcune delle differenze tra la versione finale e la bozza precedente.

Strumenti SBOM in soccorso: il case backdoor XZ Utils

Cos'è la backdoor XZ Utils (CVE-2024-3094)? CVE-2024-3094, pubblicato all'inizio di aprile 2024, è una backdoor inserita in modo dannoso in un'utilità Linux. È stato rilevato da Andres Freund, un ingegnere informatico Microsoft curioso e attento alla sicurezza, sul punto di essere integrato nelle principali distribuzioni Linux. Se ciò fosse riuscito, un numero inimmaginabile di server […]