Request Support  | Contact Sales

Diventa Autore per CoreTech | Scopri di più





Perché gli sviluppatori evitano la sicurezza e cosa puoi fare al riguardo

19/03/21 CoreTech Blog

La Linux Foundation e il Laboratorio per la scienza dell'innovazione di Harvard hanno recentemente pubblicato un rapporto sul sondaggio dei collaboratori del software gratuito / open source del 2020 . Una delle principali conclusioni di questo rapporto è stata il fatto che gli sviluppatori di software libero / open source spesso hanno un approccio molto negativo alla sicurezza. Dedicano pochissimo tempo alla risoluzione dei problemi di sicurezza (una media del 2,27% del tempo totale speso) e non esprimono la volontà di spendere di più.

Alcune delle citazioni del sondaggio erano semplicemente inquietanti. Ad esempio, “Trovo che l'impresa della sicurezza sia un compito che fa appassire l'anima e un argomento che è meglio lasciare agli avvocati e ai fanatici del processo. Sono uno sviluppatore di applicazioni. " Un altro esempio: "Trovo la sicurezza un ostacolo procedurale insopportabilmente noioso".

Sebbene il rapporto contenga le raccomandazioni strategiche degli autori, ecco i nostri pensieri su cosa significhi questa situazione per la sicurezza delle applicazioni e cosa puoi fare al riguardo.

Quanto lontano e quanto largo?

Il rapporto originale si concentra solo sul software libero / open source (FOSS), ma riteniamo sia importante considerare se questo è solo un problema FOSS o un problema con tutti gli sviluppatori.

Sulla base del sondaggio, la maggior parte degli sviluppatori FOSS (74,87%) sono impiegati a tempo pieno e più della metà (51,65%) sono specificamente retribuiti per sviluppare FOSS. Ciò significa che FOSS è spesso sviluppato dalle stesse persone che sviluppano software commerciale. Non crediamo che gli sviluppatori cambino atteggiamento a seconda che il software con cui lavorano sia gratuito o commerciale. Pertanto, riteniamo che questo cattivo atteggiamento nei confronti della sicurezza si estenda a tutti gli sviluppatori.

Crediamo inoltre che la causa di fondo di questo atteggiamento sia il fatto che agli sviluppatori viene insegnato male o non viene insegnato affatto. La maggior parte delle risorse online che insegnano la programmazione salta completamente il problema delle pratiche di codifica sicure . I libri sui linguaggi di programmazione raramente menzionano la codifica sicura. Le scuole spesso trattano anche la sicurezza come materia facoltativa invece che come corso principale che dovrebbe essere un prerequisito per tutte le altre classi di programmazione.

Pertanto, concludiamo che i risultati di questo sondaggio possono essere considerati applicabili a tutti gli sviluppatori di software. Mentre nel caso del software commerciale alcune misure di sicurezza possono essere aggiunte dalla presenza di team di sicurezza dedicati, “la radice è ancora marcia”.

Sviluppo sicuro? Non probabile!

Mentre l'86,3% degli intervistati del sondaggio ha ricevuto una formazione formale sullo sviluppo, solo il 39,8% ha dichiarato di avere una formazione formale nello sviluppo di software sicuro. Ciò significa che metà degli sviluppatori è stata istruita male.

Un altro shock viene dalla risposta alla seguente domanda: "Durante lo sviluppo di software, quali sono le principali fonti di best practice di sicurezza?". Risulta che solo il 10,73% ha appreso tali migliori pratiche da lezioni e corsi formali e il 15,51% dalla formazione aziendale. Quasi la metà degli sviluppatori utilizza articoli / blog online (46,54%) e forum (50,66%) come fonte primaria di informazioni sulle migliori pratiche, il che mostra ancora una volta lo stato orribile dell'istruzione e la mancanza di risorse sulla programmazione sicura. 

Ultimo ma non meno importante, i risultati del sondaggio dimostrano che il software gratuito / open source viene solitamente rilasciato senza alcun test di sicurezza. Mentre il 36,63% utilizza uno strumento SAST per eseguire la scansione del codice sorgente FOSS, solo il 15,87% utilizza un DAST per testare le applicazioni. Questa situazione è probabilmente migliore nel caso del software commerciale perché i team di sicurezza di solito introducono SAST / DAST nell'SDLC .

Banner

Perché il cattivo atteggiamento?

Se i tuoi sviluppatori di applicazioni hanno un cattivo atteggiamento nei confronti della sicurezza, non è solo dovuto alla loro educazione. Potrebbe anche essere a causa della tua organizzazione aziendale, che fa sentire loro di non essere affatto coinvolti nella sicurezza.

Gli sviluppatori non si sentono responsabili della sicurezza principalmente a causa dell'esistenza di team di sicurezza dedicati. Se il personale addetto alla sicurezza lavora in unità organizzative separate, gli sviluppatori pensano che la sicurezza non sia un loro problema e si aspettano che i ricercatori della sicurezza se ne occupino invece.

Gli sviluppatori inoltre non si sentono responsabili perché in un'organizzazione tradizionale raramente ci si aspetta che correggano i propri errori relativi alla sicurezza. Un tipico sviluppatore scrive un pezzo di codice, ottiene una revisione del codice da un altro sviluppatore (probabilmente altrettanto incapace di sicurezza) e poi se ne dimentica. Successivamente, un ricercatore di sicurezza trova una vulnerabilità e crea un ticket per risolverla. Questo ticket viene assegnato al primo sviluppatore disponibile, di solito non quello che ha originariamente introdotto la vulnerabilità.

Una tale organizzazione promuove la mancanza di responsabilità per la sicurezza e alimenta sentimenti negativi tra sviluppatori e team di sicurezza. Possono vedersi l'un l'altro come “quelli che causano problemi” - e questo è ciò che devi prima mirare a cambiare.

Automazione come soluzione

L'automazione del processo di individuazione e segnalazione delle vulnerabilità di sicurezza il prima possibile risolve questo problema. Prima di tutto, gli errori vengono segnalati da un software, non da un essere umano, quindi non c'è altra persona da incolpare. In secondo luogo, l'errore viene segnalato immediatamente, di solito dopo il primo tentativo di compilazione, e la compilazione fallisce, quindi lo sviluppatore deve correggere immediatamente il proprio errore. In terzo luogo, ogni volta che lo sviluppatore è costretto a correggere il proprio errore, impara un po 'di più su come scrivere codice sicuro e su quanto sia importante.

L'unico problema che rimane è trovare un software affidabile per questa attività. Sfortunatamente, le capacità limitate del software SAST / DAST sono state la causa di molti errori in passato ed è per questo che molti sviluppatori non vogliono utilizzare uno strumento SAST o DAST.

Gli strumenti SAST indicano potenziali problemi, ma segnalano alcuni falsi positivi: lo sviluppatore trascorre molto tempo a ricercare qualcosa che si rivela non essere affatto una vulnerabilità. Alla fine, gli sviluppatori smettono di fidarsi dello strumento e iniziano a odiarlo. D'altra parte, gli strumenti DAST segnalano meno falsi positivi ma spesso non forniscono informazioni sufficienti per lo sviluppatore per essere sicuro di dove si trova la vulnerabilità ea cosa può portare.

Conclusioni

La conclusione più preoccupante di questo articolo è che la maggior parte del software gratuito / open source è intrinsecamente insicuro e se vuoi sentirti sicuro usandolo, devi eseguire tu stesso test di sicurezza regolari.

Un'altra conclusione preoccupante è che le persone che dovrebbero essere la tua prima linea di difesa nella sicurezza IT non sono istruite sulla sicurezza e hanno un cattivo atteggiamento nei suoi confronti. Questo non è qualcosa che sarà facile o veloce da cambiare.

Sono necessarie risoluzioni strategiche a lungo termine per risolvere questi importanti problemi e la semplice implementazione di una soluzione automatizzata non può essere percepita come una bacchetta magica. Tuttavia, se introduci una soluzione di test automatizzata affidabile nel tuo DevSecOps SDLC nella prima fase possibile, ti assicurerai che il tuo software sia sicuro e insegnerai ai tuoi sviluppatori che devono assumersi la responsabilità della sicurezza del loro codice .


Articoli su Sicurezza

Sicurezza aziendale: da cosa è minacciata e come proteggerla?Il threat modeling per la sicurezza delle applicazioniScanner di vulnerabilità: ecco come funzionanoWeb security: 5 motivi per cui è essenziale contro i ransomwareChe cos'è DevSecOps e come dovrebbe funzionare?Test di penetrazione vs scansione delle vulnerabilitàConsiderazioni sui test di correzione delle applicazioni WebQuattro modi in cui l'analisi AppSec aiuta i tuoi professionisti DevSecOpsQuattro modi per combattere il divario di competenze di sicurezza informaticaDove i framework di cybersecurity incontrano la sicurezza webCome costruire un piano di risposta agli incidenti informaticiRendi i tuoi utenti parte della soluzione di sicurezza webSei l'unico che può proteggere le tue applicazioni webNuovo studio di settore: il 70% dei team salta i passaggi di sicurezzaConvergenza Dev-Sec: i progressi e le sfide sulla strada per garantire l'innovazioneAggiornamento FISMA: cosa sta cambiando e perché è importanteChe cos'è la sicurezza continua delle applicazioni Web?Sei l'unico che può proteggere le tue applicazioni webCos'è la sicurezza del sito Web: come proteggere il tuo sito Web dall'hackingRendi i tuoi utenti parte della soluzione di sicurezza webConvergenza Dev-Sec: la ricerca illustra i progressi per garantire l'innovazioneAggiornamento FISMA: cosa sta cambiando e perché è importanteChe cos'è la sicurezza continua delle applicazioni Web?La differenza tra XSS e CSRFNuovo studio di settore: il 70% dei team salta i passaggi di sicurezzaPrevenzione e mitigazione XSSStop ai compromessi sulla sicurezza delle applicazioni webSfatare 5 miti sulla sicurezza informaticaBasta compromessi sulla sicurezza delle applicazioni webNozioni di base sulla sicurezza web: la tua applicazione web è sicura?Che cos'è l'iniezione dell’header HTTP?Fare shift left o no?Individuazione e correzione di falle di sicurezza in software di terze partiClassi di vulnerabilità Web nel contesto delle certificazioniScripting tra siti (XSS)Che cos'è un attacco CSRFChe cos'è una SQL Injection (SQLi) e come prevenirlaAttacchi di attraversamento di directoryChe cos'è la falsificazione delle richieste lato server (SSRF)?7 migliori pratiche per la sicurezza delle applicazioni WebBlack Hat 2021: la più grande minaccia alla sicurezza informaticaÈ ben fatto? Chiedi allo sviluppatore!Scegli la soluzione di sicurezza delle applicazioni web che fa per teSicurezza fai-da-te: lo stai facendo bene?Sulla sicurezza delle applicazioni web professionali per MSSPLa cattiva comunicazione è al centro delle sfide di AppSecImpostazione e raggiungimento degli obiettivi di sicurezza delle applicazioniMetriche di sicurezza informatica per le applicazioni WebCome evitare attacchi alla supply chainPerché la maggior parte delle misure di sicurezza delle applicazioni fallisceVuoi che la tua sicurezza sia costruita su scuse?Cos'è SCA e perché ne hai bisognoLa scansione ad hoc non è sufficienteEsposizione dei dati sensibili: come si verificano le violazioniHai paura dei test di sicurezza nell'SDLC?Vantaggi di Web Asset DiscoveryStrumenti di scansione delle vulnerabilità: perché non open source?Protezione WAF - Ottieni il massimo dal tuo firewall per applicazioni webL'errore di comunicazione è al centro delle sfide di AppSecDebugger remoti come vettore di attaccoDAST è una parte essenziale di un programma completo per la sicurezza delle applicazioniCome difendersi dagli attacchi recenti su Microsoft Exchange5 principali vantaggi dei primi test di sicurezzaTecniche di attacco Denial-of-Service con avvelenamento della cacheQuali principali attacchi web possiamo aspettarci nella nuova top 10 di OWASP?Hack di SolarWindsPillole di Sicurezza | Episodio 38Pillole di Sicurezza | Episodio 37Perché gli sviluppatori evitano la sicurezza e cosa puoi fare al riguardoPillole di Sicurezza | Episodio 36Cos'è l'attacco RUDYCos'è la navigazione forzataCome gli scanner trovano le vulnerabilitàPillole di Sicurezza | Episodio 34Pillole di Sicurezza | Episodio 35Come eseguire il benchmark di uno scanner di vulnerabilità Web?Pillole di Sicurezza | Episodio 33Pillole di Sicurezza | Episodio 325 proposte di vendita comuni sulla sicurezza delle applicazioni web5 motivi per non fare affidamento sui programmi BountyPillole di Sicurezza | Episodio 315 motivi per cui la sicurezza web è importante quanto la sicurezza degli endpointPillole di Sicurezza | Episodio 305 motivi per cui la sicurezza web è importante per evitare il ransomwarePillole di Sicurezza | Episodio 293 motivi per cui DAST è il migliore per la sicurezza delle applicazioni WebPillole di Sicurezza | Episodio 28Pillole di Sicurezza | Episodio 27Pillole di Sicurezza | Episodio 24Pillole di Sicurezza | Episodio 25Pillole di Sicurezza | Episodio 21Pillole di Sicurezza | Episodio 22Pillole di Sicurezza | Episodio 20Pillole di Sicurezza | Episodio 17Il flag HttpOnly: protezione dei cookie da XSSPillole di Sicurezza | Episodio 16Il Bug Heartbleed – I vecchi Bug sono duri a morirePillole di Sicurezza | Episodio 15Pillole di Sicurezza | Episodio 14Pillole di Sicurezza | Episodio 13Pillole di Sicurezza | Episodio 12Pillole di Sicurezza | Episodio 11Pillole di Sicurezza | Episodio 10Sicurezza delle reti: gli hacker puntano CitrixCyber hacking: la Germania chiede l’intervento dell’UESicurezza informatica: Cisco rilascia aggiornamentiOcchio al cryptojacking: malware infiltrato in Docker HubSIGRed: bug di sistema in Windows Server scovato dopo 17 anniPillole di Sicurezza | Episodio 9Summit Live - Disponibili le registrazioni delle live di MonteleoneCriminalità informatica: Schmersal sventa un cyber-attaccoPillole di Sicurezza | Episodio 8Pillole di Sicurezza | Episodio 7Analisi pratica dei rischi per il SysAdmin, DevOps e Dev | Summit LivePillole di Sicurezza | Episodio 6Pillole di Sicurezza | Episodio 5Pillole di Sicurezza | Episodio 4Pillole di Sicurezza | Episodio 3Pillole di Sicurezza | Episodio 2Pillole di Sicurezza | Episodio 1Pillole di Sicurezza | Episodio 23