Nell’ottica di garantire una preventiva identificazione delle vulnerabilità inerenti ai rischi di sicurezza informatica e delle problematiche relative alle performance applicative è buona prassi, utilizzando la piattaforma di Software Intelligence di CAST, affidarsi ai criteri di shift left testing, di prioritizzazione delle violazioni e di automazione del processo di misurazione.
Affinché il processo di sviluppo del software sia virtuoso, occorre che l’identificazione delle problematiche di sicurezza e performance applicative avvenga già nei primi stadi del ciclo di vita del software. A tale scopo, un corretto monitoraggio del codice applicativo dovrebbe essere implementato a partire dalle attività di sviluppo e di collaudo, evitando la sola applicazione in ambiente di produzione, quando ormai le criticità hanno raggiunto l’esercizio e quindi sono parte del servizio erogato.
I punti di applicazione della piattaforma CAST MRI, all’interno della catena di sviluppo, vengono convenzionalmente indicati come GATE.
E’ infatti buona norma implementare un processo iterativo basato su azioni di rimedio, a seguito della identificazione di violazioni, tale che - ad ogni GATE - la criticità delle violazioni identificate sia sempre più bassa e il rischio che ne venga impattato il servizio in produzione sia via via minore.
Quello di sanare le violazioni non appena se ne ha evidenza nell’ambiente di sviluppo, è quindi un approccio assolutamente vantaggioso, in quanto presuppone che il passaggio allo stadio successivo, tipicamente quello di test/collaudo, sia condizionato alla risoluzione delle violazioni critiche già identificate.
Il processo finora descritto, che vede la realizzazione di azioni di rimedio prima del passaggio allo stadio successivo, va implementato su ognuno di quelli che tipicamente sono gli ambienti principali: Sviluppo, Collaudo e Produzione. Questa metodologia consente un’analisi uniforme e comune ai vari ambienti, a livello di criterio e metodologia di valutazione e garantisce il mantenimento di tali caratteristiche anche in situazioni cross-servizio e cross-tecnologia.
Inoltre, tale approccio permette un’interazione migliore con i fornitori, basata su criteri oggettivi, permettendo l’implementazione di interventi mirati e tempestivi e una diffusione ampia delle best practice e chiarezza circa i livelli minimi di servizio richiesti. Per essere veramente efficacie ed applicabile, questo tipo di soluzione impone naturalmente un criterio di prioritizzazione delle violazioni e l’implementazione di automatismi di analisi.
Il meta modello CAST prevede, per ogni tecnologia sotto analisi, un nutrito insieme di regole che vengono verificate durante la scansione del codice. La contravvenzione ad una di queste regole genera una violazione. L’identificazione delle violazioni è il processo alla base della determinazione dei KPI CAST e degli Action Plan di rimedio, tali dati - rilevanti e operativi - sono presenti nelle viste delle dashboard CAST Health ed Engineering, che consentono il drill-down sino alla riga di codice ove la violazione si è verificata.
Tali regole sono distinte per livello di criticità, secondo gli standard internazionali e le best practices architetturali e di sintassi del codice, per ogni specifica tecnologia (https://technologies.castsoftware.com/rules).
Inoltre, il meta modello CAST prevede la categorizzazione in violazioni critiche e non critiche, ma per efficientare l’identificazione delle violazioni da trattare, secondo un criterio di priorità, in termini di trattamento e risoluzione delle violazioni, può essere convenientemente introdurre un ulteriore sottosistema di categorizzazione sull’insieme delle regole disponibili. Questa operazione viene fatta per “concentrare l’attenzione” su quelle violazioni che, per il contesto applicativo, il tipo di business in cui il servizio si inserisce, gli aspetti che il cliente ritiene più rilevanti, assumono un’importanza focale sulla qualità di erogazione del servizio e sulla sicurezza. Tale ulteriore categorizzazione consente di concentrare le attività iniziali di risoluzione fornendo benefici effetti su un altro parametro centrale: il time to market.
Tipicamente si arriva a definire come Golden Rules, quel sottoinsieme di regole la cui risoluzione è ritenuta imprescindibile perché un componente raggiunga l’ambiente di produzione, o in genere venga trasferito nell’ambiente successivo.
Vengono definite Silver Rules, quelle regole non bloccanti, ma che hanno impatto rilevante sul codice in termini di rischio, e che meritano un’attenzione particolare e un processo di rimedio specifico.
Il resto delle violazioni, di tipo critico e non critico secondo il meta modello CAST, che non siano state identificate nei passaggi precedenti, vengono inserite in una terza categoria: le regole minori o Bronze Rules.
Risulta logico che per garantire un’analisi puntuale e fruibile ad ogni nuova release, si renda necessario automatizzare i processi di estrazione del codice, scansione e pubblicazione dei risultati, integrando tali azioni con il processo di SCM (Software Control Management) aziendale.
Una volta completata l’implementazione, saranno tempestivamente disponibili gli action plan di rimedio, tramite i quali potranno essere pianificate le eventuali necessarie azioni di modifica e correzione e riciclo dell’analisi, oppure venire sancita la promozione del codice allo stadio successivo.
Comments: