A seguito del rilascio in produzione di un’applicazione, il suo debito tecnico impatterà direttamente sugli utenti e sul rischio che le violazioni di sicurezza, di efficienza e robustezza, che l’applicazione contiene nel suo codice, portino a incidenti, minacce e, nei casi più gravi, all’interruzione del servizio.
Gli strumenti di CAST (CAST Imaging e CAST Highlight) consentono di analizzare il codice sorgente delle applicazioni software e di evidenziare tutti i possibili difetti che possono comportare rischi, prima che questi siano rilasciati in produzione.
Per fare in modo che i difetti più gravi siano individuati e risolti prima che il codice sia rilasciato e l’applicazione eseguita in produzione, l’utilizzo dei tool di CAST va effettuato integrando il processo di ALM (Application Lifecycle Management) e CI/CD delle applicazioni con uno o più Structural Quality o Risk Gate.
Il Quality Gate (QG) può essere posizionato in diverse fasi a monte del rilascio in produzione, a seconda delle esigenze e delle modalità di gestione del processo ALM :
- nell’ambiente di sviluppo, ogni volta che il codice viene caricato sul repository di SCM (source Code Management)
- nell’ambiente di test, dopo che sono stati completati gli Unit Test
- nell’ambiente di preproduzione, dopo i test di integrazione
- …
In ciascuna di queste fasi, possono variare i perimetri e le frequenze di analisi del codice sorgente.
Con i tool di CAST, l’applicazione del QG può essere manuale o anche totalmente automatizzata ed integrata nella toolchain, anche in ambito DevOps:
Un buon esempio di QG è quello eseguito su ambiente di test sui sorgenti completi dell’applicazione, che possono essere stati sviluppati sia internamente o anche da fornitori esterni, di cui si vuole controllare il risultato prodotto ed il rispetto degli eventuali SLA contrattuali.
In questo caso si andrà ad operare in 2 fasi:
Fase 1 : Onboarding Applicazione (Baseline)
Il repository dei sorgenti per la baseline sarà quello di produzione dove dovrà trovarsi il codice sorgente completo del perimetro applicativo da analizzare (scaricato da Git o da altri SCM). Sulla base dei risultati prodotti, le violazioni saranno selezionate, raccolte in opportuni subsets (Golden/Silver/Bronze Rules) e prioritizzate con uno specifico Action Plan che sarà condiviso con gli application owner ed i fornitori.
Fase 2 : Quality Gate (Rescan in test)
Il repository dei sorgenti per il QG sarà quello di test, dove dovrà trovarsi il codice sorgente completo del perimetro applicativo da analizzare comprensivo delle modifiche da rilasciare in produzione (scaricato da Git o da altri SCCM). Il perimetro applicativo e l’organizzazione dei sorgenti dovrà essere la stessa già analizzata per la baseline.
Il quality check, a questo punto, può essere effettuato in due modalità:
- Su tutte le violazioni individuate appartenenti al sottoinsieme delle Rule selezionate
- Solo sulle nuove violazioni aggiunte rispetto alla baseline precedente appartenenti al sottoinsieme delle Rule selezionate
Il report contentente l’elenco delle violazioni che hanno bloccato il rilascio dovrà quindi essere fornito a tutti i principali stakeholders operativi.
Se il QG è superato, I risultati saranno marcati come nuova baseline e rilasciati in produzione.
Se il QG è fallito, l’applicazione verrà rimandata allo sviluppo per effettuare le fix necessarie. Una volta completate le modifiche richieste, il QG verrà ripetuto.
Le Golden Rule, in questo caso, sono il sottoinsieme delle regole appartenenti al Quality Model di CAST, che vengono ritenute bloccanti al fine del Quality Gate. A seconda dei criteri di selezione di queste regole, il gate sarà più focalizzato sulla Security o sulla Quality in generale, nel rispetto di standard di qualità come il CISQ Index o ISO 5055 Index, oppure più specifici di sicurezza come OWASP top 10 o CWE (in questo caso si può parlare di Risk Gate).
Un ulteriore livello di affinamento del QG potrà tenere conto, oltre della classificazione di regola violata (Golden/Silver/Bronze), anche del livello di rischio associato alla singola violazione. Nella Engineering Dashboard di CAST, ad ogni violazione è, infatti, associato un Propagation Risk Index (PRI) che dipende da quanto l’oggetto che contiene la violazione sia impattante su funzionamento del resto dell’applicazione. Questo è reso possibile dal fatto che CAST analizza tutto lo stack tecnologico compreso nel perimetro delle applicazioni software, dal frontend ai database, individuando tutte le possibili interazioni tra i componenti.
Comments: