Cos'è la sicurezza shift-left?

Lo sfruttamento delle vulnerabilità è diventato la causa principale degli attacchi informatici, rappresentando il 40% degli incidenti osservati dal team IBM X-Force, secondo l'X-Force X-Force Threat Intelligence Index. "I leader della sicurezza devono adottare un approccio più proattivo", ha dichiarato Mark Hughes, Global Managing Partner per i Servizi di Cybersecurity di IBM, in un comunicato stampa sul Threat Intelligence Index. Una strategia shift left trasforma la cybersecurity da reattiva a proattiva, rendendola una priorità piuttosto che un ripensamento.

Shifting Security Left è integrato nel ciclo di vita sicuro dello sviluppo del software (SSDLC), che integra la sicurezza in ogni fase dello sviluppo del software. È anche una best practice per DevSecOps, che automatizza l'integrazione della sicurezza dell'applicazione (AppSec) e della sicurezza dell'infrastruttura nei processi DevOps.

La sicurezza shift left aiuta a ridurre i rischi di sicurezza, individuandoli prima che peggiorino. Consiste nelle seguenti pratiche fondamentali:

• Modellazione delle minacce

• Codifica sicura

• Test di sicurezza

• Integrazione CI/CD

• Security as code

La modellazione delle minacce avviene durante la fase di progettazione. Implica l'identificazione e la valutazione delle potenziali minacce a un sistema e la definizione delle azioni per mitigarle o prevenirle.

Il processo inizia con l'analisi dell'architettura del sistema, la ricerca dei punti di accesso e la mappatura dei flussi di dati. Successivamente, le minacce vengono classificate in base alla gravità per determinare a quali dare priorità. Vengono quindi impostati controlli o salvaguardie per gestire le minacce. Il modello di minaccia risultante può essere perfezionato all'interno dell'SDLC.

La modellazione delle minacce implica diverse tecniche, come la metodologia STRIDE e il framework MITRE ATT&CK. L'Open Worldwide Applicazione Security Project (OWASP) fornisce ulteriori indicazioni sulla modellazione delle minacce.

Le pratiche di codifica sicura comprendono strategie di programmazione difensiva che proteggono il codice sorgente dagli attacchi informatici. Questi includono:

• Aggiungere la sicurezza come parte delle revisioni del codice

• Autenticazione e autorizzazione per verificare l'identità di un'entità e garantire il giusto livello di accesso

• Abbinare le query parametrizzate alle istruzioni preparate per prevenire attacchi di tipo SQL injection

• Meccanismi robusti di registrazione e gestione sicura degli errori

• Convalida lato server e sanificazione degli input, nonché codifica degli output per proteggersi dagli attacchi di tipo injection

• Solidi protocolli crittografici per salvaguardare la disponibilità, la riservatezza e l'integrità dei dati

Un test di sicurezza completo convalida le misure di sicurezza incorporate nel codice sorgente. A differenza del shift left-testing, che mira a migliorare la copertura e la qualità del codice, il test di sicurezza si concentra sull'applicazione nel suo complesso per mettere in luce le problematiche di sicurezza.

Ecco alcuni tipi comuni di test di sicurezza:

• Test di sicurezza statica delle applicazioni (SAST): chiamato anche test "white box", il SAST analizza il codice senza eseguire l'applicazione. Applica regole predefinite per segnalare le falle di sicurezza.

• Test dinamico della sicurezza delle applicazioni (DAST): spesso chiamato black box testing, DAST valuta le app mentre sono in esecuzione. Utilizza attacchi simulati per imitare gli attori delle minacce del mondo reale.

• Test interattivi di sicurezza delle applicazioni (IAST): l'IAST valuta sia il contesto del codice che il comportamento del tempo di esecuzione per segnalare le vulnerabilità in tempo reale.

Questi metodi possono essere combinati per un quadro più completo delle probabili vulnerabilità.

L'automazione della sicurezza può essere integrata nell'integrazione continua/implementazione continua (CI/CD). Alcune tecniche per incorporare la sicurezza nelle pipeline CI/CD includono:

• Implementare hook pre-commit che richiedano la scansione dei segreti prima che gli sviluppatori avviino pull request e blocchino le modifiche che contengono segreti hardcoded (come chiavi API, stringhe di connessione e altre credenziali)

• Scansione dell'infrastruttura come codice (IaC) alla ricerca di configurazioni errate

• Rilevamento dei segreti per artefatti, log di build e variabili di ambiente per scoprire eventuali segreti esposti prima che raggiungano la produzione

• Analisi della composizione software (SCA) per esaminare librerie e componenti open source, generare una lista dei materiali software (SBOM) e confrontarla con database di vulnerabilità di sicurezza note

• Scansione delle vulnerabilità per immagini container di applicazioni cloud-native

Come la policy as code, la security as code tratta le regole e le politiche di sicurezza come logica eseguibile. Possono essere eseguiti controlli automatici prima che gli sviluppatori apportino modifiche al codice per assicurarsi che rispettino regole e politiche di sicurezza.

La sicurezza come codice risiede negli stessi sistemi di controllo di versione che i team di ingegneri del software utilizzano per gestire il codice. Ciò significa che le politiche di sicurezza basate sul codice possono essere applicate in modo ampio e scalabile, e qualsiasi aggiornamento può essere facilmente revisionato e tracciato.

La sicurezza shift-left aiuta a ridurre la superficie di attacco di un'organizzazione pur mantenendo la qualità del software. Quando le aziende adottano la sicurezza shift-left, ottengono questi vantaggi:

• Cultura del team potenziata

• Aumento della soddisfazione del cliente

• Costi ridotti

• Release più rapide

La sicurezza shift-left favorisce la collaborazione tra sviluppatori, DevOps e team di sicurezza. Condividono conoscenze e best practice di sicurezza, eliminando i silos informativi. E concordano gli obiettivi di sicurezza, lavorando insieme per creare software più sicuri.

Anticipare la sicurezza nel ciclo di vita dello sviluppo impedisce che exploit di grave entità raggiungano l’ambiente di produzione e abbiano un impatto negativo sugli utenti. Inoltre, limita i tempi di inattività che accompagnano le correzioni di emergenza o le patch per le violazioni. Ciò consente ai team di fornire sistemi di alta qualità, affidabili, sicuri e stabili, il che a sua volta contribuisce ad aumentare la fiducia dei clienti.

Rilevare vulnerabilità nelle fasi avanzate dell'SDLC può comportare costose rielaborazioni. Se individuati precocemente, i problemi di sicurezza diventano meno costosi da risolvere.

La sicurezza shift-left evita i colli di bottiglia derivanti dai ritardi nella ricerca delle vulnerabilità verso la fine del processo di sviluppo, portando a cicli di consegna più rapidi. Nel frattempo, l'integrazione della sicurezza shift-left nell'SDLC aiuta a semplificare i workflow, mentre i test automatizzati e l'automazione come parte delle pipeline CI/CD contribuiscono a rilasci più rapidi.

La sicurezza shift-left contribuisce a migliorare il livello di sicurezza complessivo di un'azienda. Ecco alcuni suggerimenti che possono aiutare i team a implementare la sicurezza shift-left:

• Definire requisiti e politiche di sicurezza chiari

• Iniziare in piccolo

• Adottare l'automazione

• Stabilire le priorità in base alla gravità

• Abbinare lo “shift-left” allo “shift-right”

• Ottimizzazione nel tempo

• La formazione è fondamentale

Le fasi di pianificazione e analisi dell'SDLC devono definire i requisiti e le politiche di sicurezza insieme ai requisiti funzionali e di altri progetti. Questo è il momento di coinvolgere i team di cybersecurity, che offrono guida e supporto cruciali lungo il percorso.

Integrare la sicurezza fin dalle prime fasi del progetto può essere un'impresa ardua, soprattutto per i progetti software di grandi dimensioni. Iniziare in piccolo e in modo semplice può rendere il processo più realizzabile. Può sembrare l'applicazione di una particolare pratica di codifica sicura, ad esempio, o la sperimentazione di test di sicurezza per una funzionalità minore.

L'automazione è un asset vitale quando si tratta di sicurezza shift-left. Ad esempio, Red Hat Advanced Cluster Security for Kubernetes è una piattaforma di sicurezza nativa Kubernetes che protegge le app containerizzate durante tutto il loro ciclo di vita—dalla compilazione e distribuzione fino all'esecuzione. Consente la scansione automatica delle immagini dei container alla ricerca di configurazioni errate e vulnerabilità note. Può anche applicare automaticamente le politiche di sicurezza, come la costruzione di blocchi o interrompere le pipeline di distribuzione se un'immagine non supera i controlli automatici.

Man mano che i team mettono in atto la sicurezza shift-left, potrebbero andare incontro a una “fatica da avvisi” a causa dei numerosi avvisi generati dagli strumenti che utilizzano. La creazione di un sistema di triage può essere d’aiuto, consentendo di risolvere prima i problemi ad alto rischio rispetto a quelli a basso rischio.

L'integrazione di entrambe le strategie può portare a software più sicuri e robusti. Mentre lo spostamento a sinistra diffonde la sicurezza in tutto l'SDLC, lo spostamento a destra protegge dall'evoluzione delle minacce alla sicurezza in produzione, rendendole tecniche complementari.

Esempi di sicurezza shift-right includono la protezione automatica delle applicazioni in tempo di esecuzione (RASP), che rileva e risponde agli attacchi in tempo reale, e i firewall delle applicazioni web (WAF) che monitorano il traffico web verso le app e bloccano il traffico dannoso come determinato dalle politiche di sicurezza.

La sicurezza shift-left è una metodologia continua e iterativa. Le aziende possono applicare quanto appreso nel tempo per migliorare continuamente il proprio approccio.

Le aziende devono includere la sicurezza shift-left come parte della formazione sulla sicurezza di un team di sviluppo o DevOps. I team devono capire perché è importante spostare la sicurezza a sinistra, come implementarla e come utilizzare gli strumenti necessari.

Man mano che l'AI generativa diventa sempre più integrata nei workflow di sviluppo software, può anche aiutare a proteggere tali workflow.

Ad esempio, IBM® Bob, un partner di sviluppo basato sull'AI, si fonda su principi che mettono la sicurezza al primo posto e abbraccia la filosofia dello “shift-left”. Dispone di un workflow di revisione integrato che analizza le modifiche al codice e segnala potenziali problemi di sicurezza prima che gli sviluppatori comincino il loro lavoro. I team possono creare una revisione del codice skill incentrata sulla sicurezza, in grado di verificare il codice sorgente per vulnerabilità comuni e la conformità alle pratiche di codifica sicura.

Facendo un ulteriore passo avanti, Bob può generare codice sicuro con un workflow di tipo actor-critic. Un subagente attore scrive codice conforme alle norme di sicurezza configurate, mentre un subagente critico convalida il codice rispetto agli standard di sicurezza pubblicati.

Allo stesso tempo, IBM Concert è una piattaforma agentica IT Ops che fa emergere in modo proattivo i rischi per la sicurezza prima che si trasformino in problemi di produzione. Concert Protect utilizza la gestione delle vulnerabilità basata sull'AI per dimostrare quali vulnerabilità sono rilevanti e coordinare la correzione.