Google rilascia un framework per prevenire gli attacchi alla supply chain.

Poiché gli attacchi alla catena di fornitura del software emergono come un punto critico a seguito degli incidenti di sicurezza come SolarWinds e Codecov, Google propone una soluzione per garantire l’integrità dei pacchetti software e prevenire modifiche non autorizzate.

Chiamato “Supply chain Levels for Software Artifacts” (SLSA, e pronunciato “salsa”), il framework end-to-end mira a proteggere la pipeline di sviluppo e distribuzione del software, ovvero il flusso di lavoro del codice sorgente e la sua creazione e pubblicazione, e mitigare le minacce che derivano dalla manomissione del codice sorgente, della piattaforma di compilazione e del repository degli artefatti in ogni anello della sua catena.

Google ha affermato che SLSA si ispira al meccanismo di applicazione interno dell’azienda chiamato Binary Authorization for Borg , un insieme di strumenti di auditing che verificano la provenienza del codice e implementa l’identità del codice per accertare che il software di produzione distribuito sia adeguatamente rivisto e autorizzato.

“Nel suo stato attuale, SLSA è un insieme di linee guida di sicurezza adottabili in modo incrementale, stabilite dai consensi del settore”

hanno affermato Kim Lewandowski del Google Open Source Security Team e Mark Lodato del Binary Authorization for Borg Team.

“Nella sua forma, SLSA differisce da un elenco di best practices di applicabilità: supporterà la creazione automatica di metadati verificabili che possono essere inseriti nei motori delle politiche per fornire ‘certificazione SLSA’ ad un particolare pacchetto o piattaforma di compilazione”.

Il framework SLSA promette l’integrità della supply chain del software end-to-end ed è progettato per essere sia incrementale che attuabile.

Il framework comprende quattro diversi livelli di complessità, con SLSA 4 che offre un alto grado di sicurezza che il software non sia stato manipolato in modo improprio.

• SLSA 1 — Richiede che il processo di compilazione sia completamente automatizzato;
• SLSA 2 — Richiede l’utilizzo del controllo della versione e un servizio di build in hosting che genera una provenienza autenticata;
• SLSA 3 — Richiede che le piattaforme di origine e di compilazione soddisfino standard specifici per garantire la verificabilità della fonte e l’integrità della provenienza;
• SLSA 4 — Richiede una revisione manuale da parte di due persone di tutte le modifiche e un processo di costruzione ermetico e riproducibile.

“Livelli SLSA più elevati richiedono controlli di sicurezza più rigorosi per la piattaforma di compilazione, rendendo più difficile la sua compromissione e l’ottenimento della persistenza”

hanno osservato Lewandowski e Lodato.

Ti è piaciuto questo articolo? Ne stiamo discutendo nella nostra Community su LinkedIn, Facebook e Instagram. Seguici anche su Google News, per ricevere aggiornamenti quotidiani sulla sicurezza informatica o Scrivici se desideri segnalarci notizie, approfondimenti o contributi da pubblicare.

Redazione

La Redazione di Red Hot Cyber fornisce aggiornamenti quotidiani su bug, data breach e minacce globali. Ogni contenuto è validato dalla nostra community di esperti come Pietro Melillo, Massimiliano Brolli, Sandro Sana, Olivia Terragni e Stefano Gazzella. Grazie alla sinergia con i nostri Partner leader nel settore (tra cui Accenture, CrowdStrike, Trend Micro e Fortinet), trasformiamo la complessità tecnica in consapevolezza collettiva, garantendo un'informazione accurata basata sull'analisi di fonti primarie e su una rigorosa peer-review tecnica.