La Application Security (AppSec) è importante perché le applicazioni odierne sono spesso disponibili su varie reti o connesse al cloud e questa estensione aumenta la superficie potenziale di vulnerabilità alle minacce e le conseguenti violazioni della sicurezza.
Attuare la protezione delle applicazioni richiede una combinazione di strumenti e pratiche per identificare, correggere e quindi prevenire le vulnerabilità della sicurezza durante tutto il ciclo di vita dello sviluppo delle applicazioni, al fine di risolverle in modo proattivo e mitigarne le rischiosità di sicurezza prima che possano essere sfruttate negli ambienti di esercizio.
Ma poiché la produzione di software moderno è caratterizzato principalmente dall’esigenza di velocità nello sviluppo e dall’agilità, per razionalizzare la pipeline di Continuos Integration/Continuos Delivery (CI/CD) anche la sicurezza deve avere un “posto d’onore” in questa “continuità operativa di sviluppo”, così da creare applicazioni sicure mantenendo bassi i costi.
L’evoluzione progressiva degli ambienti di produzione del codice per ogni ambito di business impone anche all’AppSec di adeguarsi ai maggiori trend tecnologici e di predisporsi ai trend futuri con l’adozione di metodologie, pratiche e strumenti nuovi ed essi stessi altrettanto intrinsecamente sicuri. Perché chiunque si occupi di sicurezza sa che la prima regola della security è applicarla a sé stessi prima di tutto e poi condividere queste buone prassi con gli altri.
Sviluppo software per l’azienda, perché è essenziale disciplinare il destino del codice sorgente
Indice degli argomenti
Introduzione alla Application Security e sua evoluzione
La sicurezza delle applicazioni è, dunque, la pratica di utilizzare software di sicurezza, hardware, tecniche, best practice e procedure lungo l’intero ciclo di vita dell’applicazione, per proteggere le applicazioni del computer da minacce alla sicurezza esterne (fonte: OWASP).
Fino a circa dieci anni fa la sicurezza applicativa era considerata un tema riservato ai soli esperti di sicurezza senza che la security fosse inclusa né a livello di decisioni né di progettazione. I test erano relegati alla valutazione di qualità, non alla sicurezza applicativa e avvenivano appena prima di rilasciare il codice in produzione secondo il modello waterfall (modello a cascata). In questo contesto la sicurezza richiedeva un ripensamento eventuale a livello di progettazione del software, vanificando il lavoro svolto fino a quel momento.
Oggi l’AppSec è un aspetto critico per ogni fase del ciclo di vita delle applicazioni: dalla pianificazione alla distribuzione. Il volume di applicazioni sviluppate, distribuite, utilizzate e “patchate” (il patching è la pratica di installazione delle patch di sicurezza, ovvero di codici che correggono vulnerabilità n.d.r.) sulle reti è in rapida espansione. Di conseguenza, le pratiche di sicurezza delle applicazioni devono affrontare una crescente varietà di minacce e il tema della sicurezza deve essere una preoccupazione non solo degli esperti, ma anche degli sviluppatori durante il ciclo di vita dello sviluppo applicativo.
Maurizio Di Stefano, CSSLP® Fortify SaaS Solution Architect at CyberRes – Application Security, spiega che oggi si creano app incessantemente, con un sistema di “releasing continua”, piuttosto che con rilasci cadenzati secondo la versione. Nel mercato ci sono poche risorse che conoscono le prassi di security degli sviluppi e gli stessi sviluppatori sono sempre meno, tanto da non essere sufficienti per il fabbisogno di produzione di codice, in modalità sicura.
Vi sono, quindi, esigenze di formazione specifica perché se si conoscono le minacce, le vulnerabilità possono essere evitate durante la programmazione. Infatti, durante la produzione del codice è cruciale effettuare un’analisi statica (Static Application Security Testing – SAST) real-time localmente nell’Integrated Development Environment (IDE) del singolo sviluppatore mentre lui stesso scrive il codice.
Successivamente si dovrebbero eseguire controlli di sicurezza nell’area di condivisione del codice con gli altri sviluppatori, nel momento in cui si mettono insieme i vari componenti del codice (fase di “build” del codice n.d.r.) e si esegue il “commit” (il comando “commit” è l’azione che permette di aggiungere, rimuovere e modificare i file del repository e tiene il controllo dei cambiamenti del codice n.d.r.). Tutto questo integrato con la CI/CD pipeline.
In questa fase è consigliabile effettuare nuovamente la SAST ma di tipo integrato e aggiungere l’analisi della composizione del codice (Software Composition Analysis – SCA) per effettuare il controllo delle librerie open source eventualmente adottate nel codice.
Quando invece l’applicazione è distribuita su un application server (fase di “deploy” n.d.r.) è appropriato effettuare l’analisi dinamica dell’applicazione (Dynamic Application Security Testing – DAST).
La correlazione fra le analisi SAST e DAST è sempre più richiesta, ma gli sviluppatori non hanno tempo di fare tutti questi controlli se non tramite strumenti automatici che li supportino, ai fini dell’efficienza della produzione del codice e al contempo della security di quanto prodotto. I tempi dei test di security possono inficiare i tempi della produzione del codice.
Per questo motivo esistono strumenti configurabili equipaggiati di funzionalità di “speed dial” che consentono di far decidere al fruitore la profondità dell’analisi di sicurezza. Maggiore la profondità maggiore il tempo di analisi e viceversa.
Naturalmente queste fasi hanno senso se il modello di sviluppo del codi è di tipo “Agile” con modello di sviluppo a cicli iterativi piuttosto che come nel modello “a cascata” (waterfall n.d.r.). Il processo descritto è parte delle prassi di DevSecOps che significa integrare la sicurezza delle applicazioni e dell’infrastruttura fin dall’inizio del ciclo di sviluppo ed automatizzare alcune attività di controllo della sicurezza per evitare che rallentino il flusso di lavoro DevOps.
Durante la programmazione servono processi appropriati e strumenti che possono costantemente supportare la sicurezza. Quindi la challenge dell’AppSec è globalmente legata a persone, processi e strumenti e se fino ad oggi si faceva riferimento all’esigenza dello “shift left” della sicurezza che indica l’esigenza di anticipare i temi di security fin dalle fasi di design n.d.r.), da oggi è opportuno passare ad una sorta di “shift everywhere”.
Un’ulteriore challenge è costituita dal riuso massivo del codice delle librerie open source le cui vulnerabilità possono creare criticità di sicurezza anche se il codice principale è stato prodotto rispettando le prassi di Security; quindi, è necessario introdurre prassi di Open Source Security. Infine, Maurizio di Stefano suggerisce l’adozione di plugin IDE real-time di “Spell checking” che durante l’analisi statica del Codice (SAST) possano effettuare una analisi in tempo reale della sintassi e semantica del codice, non solo dal punto di vista linguistico, ma anche dal punto di vista della sicurezza.
I maggiori trend della application security oggigiorno
L’evoluzione dell’Application Security segue le trasformazioni tecnologiche che richiedono sviluppi di codice in ambienti digitali e piattaforme continuamente mutevoli, come ad esempio gli sviluppi a microservizi, la produzione di API, gli sviluppi in ambienti cloud con l’infrastructure-as-a-code (IaC).
Ecco, quindi, che accanto alle prassi tradizionali dell’AppSec sopraccitate è necessario considerare anche altri trend:
- Security della supply chain: in questo caso è necessario evidenziare le vulnerabilità di tutte le librerie incluse nel codice effettuando le analisi della composizione del codice (Software Composition Analysis – SCA) per evidenziare vulnerabilità nelle librerie Open source. I recenti attacchi Log4J and SolarWinds classificati come attacchi alla supply chain sono stati basati proprio su venerabilità note delle librerie open source. Un tema importante della Supply chain è anche la sicurezza intrinseca degli astrumenti di test automatico di security introdotti nella pipeline di sviluppo. In proposito Maurizio di Stefano chiarisce: “Anche noi per i nostri prodotti pratichiamo la DEVSECOPS applicando SAST, DAST e SCA su tutto il sofwtare prodotto come se fossimo i nostri primi clienti”.
- API security: Le API sono la superficie di attacco in più rapida crescita, ma non sono tenute in conto tanto dagli sviluppatori, quanto dai responsabili della sicurezza delle applicazioni, anche se costituiscono porzioni di codice che permettono la comunicazione fra i componenti di un sistema. Valutarne la security significa applicare le analisi SAST e SCA durante lo sviluppo del codice e applicare la DAST quando si conosce la business logic del sistema, ovvero quando si è compresa tutta la serie di possibili comunicazioni dell’API sotto analisi, con il resto dell’ambiente applicativo.
- Shift everywhere: poiché la sicurezza è diventata inequivocabilmente un componente critico, nella DevSecOps si è affermata da tempo la prassi dello “shift left” di security che consiste nell’anticipare i test di security fin dalle prime fasi della programmazione. Ma le pipeline di programmazione basate su Continuos Integration/Continuos Delivery (CI/CD) richiedono di attuare i controlli di sicurezza sempre e ovunque.
- Cloud native: l’ampia tendenza del settore IT verso il cloud ha portato alla diffusione di “stack software” (insieme di sottosistemi software o componenti necessari per creare una piattaforma completa n.d.r.) caratterizzati da elementi architetturali nativi del Cloud, così chiamati proprio perché sviluppati direttamente in Cloud. Le tecnologie “Cloud native” consentono alle organizzazioni di creare ed eseguire applicazioni scalabili in cloud pubblici, privati e ibridi: Microservizi, service mesh, infrastruttura immutabile, API dichiarative, Containers (Dockerfiles), Infrastructure as Code (Aws, Azure, Ansible, K8), Cloud SDKs di molteplici linguaggi (Aws, Azure, GCP) includendo funzioni serverless functions, Secret scanning (cloud secrets), etc. Di conseguenza tutti i test da fare, non dovrebbero essere condotti solo a livello applicativo, ma anche sui “container” sull’infrastruttura abilitante Cloud e sui “secret scanning” (noti anche come “cloud secret”, rappresentano i luoghi digitali dove si archiviano le credenziali n.d.r.).
Per approfondirne ulteriormente le caratteristiche dei trend è possibile consultare il report di CyberRes dal titolo “2022 AppSec Trend Report”.
Trend futuri nella AppSec
Anche nell’ambito dell’Application Security si possono individuare trend evolutivi che in un prossimo futuro dovranno essere accuratamente presidiati ed inseriti nella pipeline di sviluppo del codice:
- DAST di nuova generazione: oggi i test dinamici del codice DAST sono integrati sempre più “a monte” della pipeline. Storicamente, i tempi di consegna delle scansioni DAST ne avevano precluso l’integrazione nella pipeline, ma con la DevSecOps si assiste alla loro automazione e quindi alla loro espansione guidata dagli sviluppatori, a completamente delle pipeline CI/CD. Con la DAST di nuova generazione si dovrebbe assistere ad una evoluzione degli strumenti di test che passerà da strumento di rilevamento delle vulnerabilità, ad uno strumento di valutazione del rischio attraverso l’aggiunta di Hacker Level Insight (HLI) (un set tecnologico che fornisce agli sviluppatori e ai team di app sec lo stesso set di dati che un hacker cercherebbe per eseguire ricognizione e targeting n.d.r.). Vedere ciò che vede l’hacker consentirà a chi sviluppa di dare priorità alle proprie risorse, per poter prioritizzare le lacune più critiche nel proprio ambiente di sicurezza.
- Machine learning e AI per l’AppSecc evoluta e automatizzata: Applicare algoritmi di AI e machine learning, nell’AppSec, spiega Maurizio Di Stefano: “per Fortify significa adottare un “Audit Assistant” che, dopo avere effettuato la SAST, velocizza il processo di revisione grazie ad algoritmi di machine learning capaci di verificare i risultati e fornire una previsione sulle vulnerabilità (vulnerabilità sfruttabile oppure vulnerabilità che non è un problema). Il codice è quindi soggetto a miglioramento e lo stesso algoritmo apprende continuamente specializzandosi progressivamente in meglio. L’ apprendimento iniziale di questo tipo di algoritmi si basa sui dati della community ed in particolare deriva dal servizio SaaS “Fortify on Demand” che ha adottato Audit Assistant inizialmente per uso interno come parte del servizio erogato ed oggi disponibile per la community.
- Analisi delle librerie open source: molto importanti saranno due aspetti. Il primo è la creazione del Software Bill Of Materials (SBOM) e l’analisi a livello di licensing (License Compliance) delle librerie open source a seconda dell’uso previsto, effettuato tramite un test di compliance delle licenze, solitamente di tipo “creative common”. Il secondo aspetto è l’Open Source Intelligence dove gli sviluppatori dovrebber poter comparare velocemente componenti opensource, che fanno le stesse cose, in base ai criteri della community (popolarità, qualità dei collaboratori e sicurezza). Su questo tema Maurizio Di Stefano chiarisce che: “grazie all’acquisizione recente, dell’azienda Debricked da parte di CyberRes si potranno creare funzionalità avanzate di ricerca e confronto di librerie open source che possano valutare anche la similitudine operativa (suggerendo una o più librerie open source che già implementano la stessa logica) e permettere una scelta, a seconda del codice che stia scrivendo lo sviluppatore in quel momento, mediante un Real-time IDE Spell-checker plugin.Tutto ciò aiuterà a risolvere anche il problema della mancanza di sufficienti sviluppatori nel mercato aumentando la produttività degli sviluppatori stessi”.
Contributo editoriale sviluppato in collaborazione con MicroFocus
