Contesto di misura
Si faccia riferimento ad una implementazione CAST integrata con il sistema di Software Control Management (SCM) estesa ai 3 ambienti standard di implementazione del codice: sviluppo, collaudo e produzione. In altri termini l’implementazione CAST di riferimento agisce su tre Gate in maniera autonoma, effettuando misurazioni automatiche ad ogni rilascio del software e producendo reportistica e dashboard che espongano dati inerenti alle violazioni.
Il perimetro applicativo e il versioning CAST
Il meta modello CAST prevede che venga definito un perimetro di misura a cui venga associato univocamente l’attributo applicazione. Ad ogni nuovo rilascio inerente ad una applicazione così definita, CAST produce una nuova versione della misura, caratterizzata dagli indicatori tipici dell’analisi.
La valutazione delle Violazioni
In questo contesto non si fa riferimento a nessuna tecnologia in particolare, fermo restando che CAST è in grado di sottoporre a misurazione un gruppo assai nutrito di tecnologie, per ognuna delle quali sono definite regole normate ISO, architetturali e sintattiche, che vengono verificate durante la scansione del codice estratto dal sistema SCM. Informazioni specifiche sono disponibili al seguente link: https://technologies.castsoftware.com/rules
Anche in relazione ai vari sistemi di software management, CAST ha disponibili una serie di connettori standard per realizzare l’integrazione necessaria, dettagli disponibili qui. https://doc.castsoftware.com/display/TECHNOS/Packaging+source+code+for+file+technologies
Tornando alle regole, generalmente non si utilizzano tutte quelle disponibili, ma si può far riferimento ad una normativa ISO specifica (ad es. la 5055). In alternativa si può definire un sottoinsieme di regole di tipo critico selezionate (Golden rule) seguendo criteri condivisi. Il passaggio per poter avere disponibili tali dati, ad ogni versione del software, consiste nell’impostare un action plan nella Engineering dashboard di CAST. Tale strumento consente la valutazione del delta violazioni fra una versione e la successiva, caratterizzate dagli attributi added (violazioni introdotte nell’ultima versione), pending (violazioni introdotte nelle versioni precedenti e ancora in carico), e solved (violazioni in carico risolte nell’ultima versione). Qui di seguito un esempio di action plan dell’Engineering dashboard CAST.
SLA basati sulla misura del numero di violazioni di tipo Golden presenti nel codice
L’approccio tipico prevede una severità stringente nei confronti delle violazioni Golden, che impone il blocco del trasporto in produzione del codice in cui sia presente anche una sola violazione che sia added o pending. L’ambiente più consono per una valutazione di questo genere è quello di collaudo: verranno effettuati ricicli, se necessario anche riportando il codice sino in ambiente di sviluppo, finché la misura nel gate di collaudo non evidenzierà un numero di violazioni pari a zero. Il successivo passaggio in produzione prevederà ancora una misura CAST, ma volta solo alla verifica dell’assenza di violazioni nel codice trasportato.
Eccezioni alla risoluzione delle violazioni rilevate nel codice in ambiente di collaudo
Risulta necessario prevedere dei casi in cui il codice possa comunque essere trasportato in produzione anche in presenza nella misura effettuata in ambiente di collaudo di violazioni di tipo Golden: si parla in questo caso di skip (differimento del momento in cui al violazione deve essere risolta) o annullamento della violazione (la violazione rilevata non sarà mai risolta, perché non sussiste). Questi rami di processo implicano la presenza di un ente deputato alla valutazione dei singoli casi, tipicamente composto da architetti software ed esperti di sicurezza informatica, con conoscenza del contesto applicativo specifico, ai quali spetta la scelta per determinare se la violazione può essere annullata o procrastinata l’azione di rimedio per motivi di business o comunque di oggettivi impatti molto invasivi della modifica necessaria.
Caso di skip delle violazioni
In questa casistica rientrano le violazioni rilevate nel codice in carico al team di sviluppo che non possono essere risolte immediatamente a causa di:
- Tempi stringenti legati al go-live della applicazione e conseguente impossibilità per motivi di business di completare il processo necessario per la risoluzione della violazione
- Tempi richiesti per la risoluzione della violazione molto elevati in assoluto a causa dell’impatto della modifica sull’architettura applicativa che deve essere radicalmente modificata.
In questi casi è possibile promuovere il codice in produzione se la violazione in questione non ha impatti rilevanti sulla sicurezza dell’applicazione. La violazione verrà comunque rilevata nella misura in ambiente di produzione ma dovrà essere necessariamente risolta in futuro con tempi stabiliti e regolati da SLA specifici.
Il processo di skip
Il responsabile dello sviluppo del codice invia richiesta di skip della violazione all’ente responsabile della valutazione tecnica e al PM del progetto, visto che il criterio di valutazione è principalmente di business, in quanto la violazione non è messa in discussione, nè relativa a condizioni di sicurezza informatica. Una volta ratificata la decisione di skip l’ente informa il Quality Manager CAST, con dettaglio dell’oggetto del codice ove è stata rilevata la violazione e dell’identificativo della violazione stessa. Viene rigenerato l’action plan di collaudo con la violazione che dovrà essere etichettata con un attributo dedicato di stato pari a skipped e con informazioni supplementari riguardo alla data di skip e quella di risoluzione differita. Tali informazioni andranno trasferite al gate di produzione che etichetterà la violazione appena rilevata dalla misura sul codice promosso e sono di importanza fondamentale riguardo al calcolo degli SLA inerenti ai vincoli sui tempi di risoluzione. Qui di seguito come si modifica l’action plan a seguito dell’approvazione dello skip di una o più violazioni.
Caso di annullamento delle violazioni
In questa casistica rientrano sostanzialmente due categorie di violazioni:
- I falsi positivi
- Violazioni per le quali nell’azione di rimedio è previsto il mantenimento del costrutto rilevato come violazione e la valutazione delle condizioni al contorno.
I Falsi positivi
Si parla di falso positivo quando una violazione rilevata in realtà non sussiste, in quanto conseguenza di:
- Issue del parser
- Impossibilità di applicare l’azione indicata nella documentazione a supporto perché il costrutto di rimedio non è supportato dall'attuale versione del software
- Violazione non attribuibile al fornitore perché fuori perimetro di pertinenza
- Violazione non attribuibile al fornitore in quanto il codice è di tipo standard e non customizzato dal fornitore, ad esempio codice autogenerato da tool automatici in ausilio agli sviluppatori.
Violazioni per le quali nell’azione di rimedio sia prevista la valutazione delle condizioni al contorno
Ci sono dei casi in cui la violazione può essere considerata annullabile se alcune condizioni al contorno vengono garantite. Un caso notevole riguarda ad esempio l’utilizzo di query dinamiche verso la base dati. Il parser CAST individua per tutti i codici di programmazione la presenza di query dinamiche come una violazione di tipo critico. Tipicamente questa regola è inclusa negli insiemi di tipo Golden. Questo tipo di costrutto, infatti, può esporre l’applicazione a potenziali problemi legati alla sicurezza, e il codice interessato ad essere contraddistinto come di scarsa leggibilità, con conseguenza sulla manutenibilità e sulla transferability.
In questo caso la letteratura indica come azione di rimedio principale di evitare l’uso di questa sintassi quanto possibile, ma non la esclude a priori, in quanto in determinati contesti applicativi può essere considerata una scelta opportuna o quasi obbligata. Nei casi in cui l’utilizzo sia praticamente inevitabile si chiede espressamente di verificare che i parametri che vengono passati dinamicamente alla query prima di essere eseguita siano filtrati convenientemente (ad esempio contenuti in una tabella che può essere modificata solo attraverso una CR). Un caso del genere deve essere circostanziato dallo sviluppatore e analizzato dall’ente preposto all’approvazione dell’annullamento.
La procedura di annullamento
Il responsabile dello sviluppo del codice inoltra la richiesta di annullamento della violazione, fornendo le informazioni necessarie all’ente preposto. Se la violazione viene reputata da annullare, l’ente inoltra la notifica dell’annullamento, con dettaglio della regola e dell’oggetto del codice dove tale regola è stata rilevata, al Quality Manager CAST che provvederà a conferire all’attributo della violazione nell’action plan il valore Annulled, in ambiente di collaudo, completo di data di annullamento. Viene quindi generato nuovamente l’action plan in ambiente di sviluppo e trasferite le informazioni di annullamento in termini di applicazione, oggetto contenente la violazione e codice univoco della violazione al Gate di produzione. Alla generazione dell’action plan conseguente alla misura del codice promosso in ambiente di produzione, nell’action plan comparirà la violazione ma etichettata come Annulled e con l’informazione riguardo alla data di annullamento. Questo non implica a priori che la violazione possa essere comunque risolta, senza vincoli sui tempi. La violazione quindi acquisirà lo stato Solved nell’action plan, con l’indicazione che comunque era stata giudicata annullabile. Qui di seguito l’effetto dell’approvazione di annullamento di una violazione sull’action plan.
Comments: