Questa è davvero una buona domanda, che ci stanno ponendo molti potenziali clienti. Per la maggior parte delle volte la risposta è semplice: possiamo indirizzarli verso hack come Equifax o British Airways, o Carphone Warehouse e così via. Ma se qualcuno credesse di essere già protetto?

STIAMO GIÀ CONTROLLANDO IL NOSTRO CODICE!

Sì, alcuni di noi dispongono già di una soluzione SAST, come SonarCube o Fortify, e riteniamo di essere completamente protetti. Alcuni invece usano alternative open source, come Spotbugs o PMD , e si sentono altrettanto protetti. In effetti, questi strumenti eseguiranno continuamente la scansione del codice sorgente degli sviluppatori e assicureranno che non includa alcun pattern che potrebbe essere sfruttato da un hacker malintenzionato.

Inoltre, abbiamo già messo in atto una politica di secure coding: utilizziamo peer review e pair programming in modo che tutto il nostro codice sia sottoposto a severi controlli. Usiamo pratiche di codifica sicura concordate, seguiamo checklist dettagliate e abbiamo gli sviluppatori addestrati continuamente su questi argomenti. Sembra che tutto vada bene!

MA NON TUTTO È SCRITTO DA ZERO…

Ma quando lo sviluppatore scrive codice, non scrive tutto da zero. Sei mai stato sorpreso da quanto poco tempo ci è voluto per una consegnare qualcosa? Forse, solo una volta. E sai come è potuto succedere? I vostri sviluppatori, giustamente, si sono immersi nel grande pool opensource e hanno estratto un componente che è stato in grado di accelerare il loro sviluppo, fornendo blocchi predefiniti pronti all’uso in modo che potessero concentrarsi solo sulla logica aziendale.

Quei componenti opensource sono così ampiamente usati che, nel tuo prodotto finale, fino all’80% del codice è composto da questi: solo un semplice 20% è il codice accuratamente realizzato dai tuoi sviluppatori, dove le tue pratiche interne e gli strumenti esistenti fanno una differenza. Ma chi sta controllando la sicurezza di quei componenti opensource? Bene, succede che molte persone in tutto il mondo lo facciano, in modo che questi componenti si evolvano molto rapidamente. Quando viene rilevato un bug o un problema di sicurezza, viene rapidamente risolto e viene rilasciata una nuova versione del componente. Quando si tratta di un problema di sicurezza, spesso il problema viene anche segnalato pubblicamente in specifiche mailing list o newsrooom dedicate alla sicurezza.

COME FAI A SAPERE SE UN COMPONENTE OPENSOURCE DEVE ESSERE AGGIORNATO?

Il nocciolo del problema è qui: come fai tu a saperlo? In che modo il tuo team viene a conoscenza del fatto che un determinato componente che utilizza è ora vulnerabile e che lo si deve aggiornare a una nuova versione? In che modo si assicurano che anche questo codice che non scrivono, che rappresenta fino all’80% del prodotto, sia sicuro? Mantenete un team che lo fa, scrutando meticolosamente più fonti di notizie, assicurandovi che la vostra applicazione non contenga un componente vulnerabile o obsoleto, avvisando i vostri sviluppatori di conseguenza?

È qui che entrano in scena i prodotti SCA (Software Composition Analysis) come Meterian. Questi prodotti sono un complemento naturale di strumenti come SonarQube o PMD, poiché controllano il codice che il tuo team non ha scritto. In tandem insieme al sistema di build, impediranno il rilascio del prodotto nel caso venga scoperto un componente vulnerabile e forniranno agli sviluppatori le informazioni di cui hanno bisogno per risolvere immediatamente il problema (e, in alcune occasioni, automaticamente). Sarai in grado di proteggere l’80% del prodotto dei tuoi team di sviluppo senza investire una fortuna, senza ulteriore personale e con un minimo sforzo di integrazione.

Quindi, se non disponi di una soluzione per i tuoi componenti opensource, non ti farà male dare un’occhiata a Meterian: è un sistema economico a tutto tondo che ti darà tranquillità sul codice che gli sviluppatori non scrivono. E, a proposito, Meterian controlla anche le licenze dei componenti, ma questo è per un altro post sul blog 🙂