Storicamente, la sicurezza è stata considerata come qualcosa di secondario nel settore IT. Negli ultimi anni, tuttavia, ci sono state pressioni per introdurre la”sicurezza fin dalla progettazione”per garantire che i prodotti siano sviluppati tenendo conto delle best practice.
Abbiamo parlato con David Melamed, CTO di Jit per scoprire come integrare la sicurezza e come gli strumenti di sicurezza possono essere utilizzati dagli sviluppatori e non solo dai professionisti della sicurezza.
BN: Come sei stato coinvolto nello spazio di sicurezza dello sviluppo?
DM: Come ingegnere del software (da molto tempo), ho capito che la sicurezza è un aspetto fondamentale per fornire software di alta qualità. Nel corso degli anni, ho investito più tempo e sforzi per studiare il dominio e ho avuto l’opportunità specifica di entrare in pratica nella sicurezza del cloud presso CloudLock (successivamente acquisito da Cisco). Nell’ufficio CTO ho svolto ricerche approfondite sulle minacce alla sicurezza del cloud nel mondo reale ed è stato anche uno dei ricercatori che hanno contribuito alle 10 principali minacce alla sicurezza serverless (prima che Serverless decollasse come lo è ora). Oggi, in Jit, ho portato quell’esperienza di dominio di molti anni come sviluppatore, architetto e ricercatore di sicurezza pratico per coprire l’intero ambito della sicurezza end-to-end attraverso un framework aperto e accessibile a tutti.
BN: Quali sono le principali sfide nell’implementazione degli strumenti di sicurezza?
DM: In poche parole, ce ne sono molte.
Il puro la diversità e la quantità di strumenti di sicurezza rendono questo un panorama davvero difficile da navigare. Non solo esistono diverse categorie dal rilevamento alla prevenzione, scansione del codice, rilevamento delle vulnerabilità di runtime, ma possono anche presentarsi in molte forme, da eseguibili e script, a strumenti basati su API, SaaS e pacchetti open source. La sfida più grande e più comunemente notata, tuttavia, è che ciascuno di questi strumenti è un mondo di competenze di dominio a sé stante e viene fornito con il proprio”linguaggio”, metodo di implementazione, interfaccia e output. Tutto questo insieme crea una ripida curva di apprendimento per ottenere una copertura di sicurezza end-to-end per i molti livelli degli odierni stack nativi del cloud, oltre a un lungo”tempo per la copertura di sicurezza completa”.
Tuttavia l’elemento di sicurezza più critico in un tale panorama è avere un piano predefinito, essenzialmente una stella polare per la sicurezza del tuo prodotto. Questo perché anche se integri tutti gli strumenti giusti, ma il tuo obiettivo di sicurezza non è ben definito, non saprai mai se stai gestendo correttamente la tua posizione di sicurezza e se ci sono lacune significative nella sicurezza del tuo prodotto.
BN: In che modo i team dovrebbero integrare la sicurezza nel processo di sviluppo?
DM: L’integrazione della sicurezza nello sviluppo dovrebbe iniziare già dalla prima riga di codice e non appena pratica e cultura, prima ancora che nelle fasi di progettazione e modellazione delle minacce. Ci sono così tanti livelli di cui sono composti i nostri prodotti oggi-dal codice, alle integrazioni e alle terze parti (spesso chiamate supply chain), all’infrastruttura-con una varietà di tempi di esecuzione e molto altro. Tutto questo insieme ha creato molti punti di ingresso per potenziali aggressori e nessuno di questi può essere trascurato.
Detto questo, crediamo che i team possano iniziare in piccolo e iterare con un approccio di sicurezza minimo praticabile–simile a un MVP, non è necessario costruire una fortezza dal primo giorno, solo un piano di base che ti fornirà il set minimo di controlli per coprire i principali exploit in tutte queste categorie. Ci sono un sacco di ottimi strumenti open source per iniziare, abbiamo un bel riepilogo sul nostro blog del I 5 principali strumenti di sicurezza open source che tutti gli sviluppatori dovrebbero conoscere (e un bella chiacchierata!)
BN: Puoi spiegare il ruolo dei progetti open source nello spazio della sicurezza informatica?
DM: La sicurezza open source si è evoluta incredibilmente nel corso degli anni e oggi ci sono una notevole quantità di strumenti di sicurezza open source davvero fantastici, che sono stati un punto di svolta per il settore. Da OWASP ZAP (lo scanner per applicazioni web più ampiamente adottato–gestito dal nostro illustre ingegnere, Simon Bennetts), a Gitleaks che Jit ha scelto di supportare e sponsorizzare, tra molti altri da KICS, a Prowler, Semgrep e altri.
Questi progetti hanno abbassato la barriera all’ingresso per la sicurezza, dove fino ad oggi gran parte del panorama della sicurezza è stato chiuso e suite premium di software che non sono sempre accessibili alle aziende più piccole e in crescita. Molti strumenti di sicurezza OSS sono oggi i migliori della razza e forniscono un’ottima copertura per le esigenze comuni e sono serviti a fornire l’innovazione tanto necessaria, oltre a comprendere come dovrebbe essere l’esperienza di sicurezza (simile all’esperienza dello sviluppatore o dell’utente) per abilitare veramente diffusa adozione.
BN: Qual è la tua opinione sul futuro della sicurezza per le aziende con team di sviluppo frenetici?
DM: Aziende che non lo faranno sapere come incorporare la sicurezza nei flussi di lavoro degli sviluppatori nativi nelle organizzazioni di ingegneria ad alta velocità verrà lasciato indietro. Non c’è tempo per attriti o curve di apprendimento, gli strumenti di sicurezza devono essere ottimizzati per gli sviluppatori. Devono fornire un output chiaro e non solo informativo, con l’obiettivo di essere attuabili con la correzione integrata. Riteniamo che gli strumenti di sicurezza che cambieranno le regole del gioco siano quelli forniti con una mentalità orientata alla correzione, non solo orientati ai problemi (gli sviluppatori sono stufi di lunghi elenchi di vulnerabilità e sanno come risolverli).
Inoltre, l’altra metà è che alla fine, con il panorama delle minacce in crescita e in continua evoluzione, vedremo che gli strumenti di sicurezza (sviluppo) che lo fanno bene, alla fine saranno l’abilitatore (sì, hai sentito bene–l’abilitatore) dell’ingegneria ad alta velocità con sicurezza. La posta in gioco oggi è troppo alta e le aziende sono a una richiesta pull e una violazione da un grave disastro. Le organizzazioni di ingegneria che saranno in grado di fornire rapidamente, pur mantenendo la sicurezza continua, saranno quelle che prenderanno l’iniziativa.
Credito immagine: mikkolem/depositphotos.com