AppSec e la sindrome del “bambino brutto” | Soluzioni di sicurezza per lo sviluppo di applicazioni | Sicurezza di contrasto

AppSec e la sindrome del

Come sviluppatore, ti è mai stato detto che tuo figlio è brutto?

Hai sudato sangue e lacrime costruendo quell’applicazione rivoluzionaria o creando la funzionalità rivoluzionaria solo per sentirti dire che non puoi rilasciarla?

L’approccio tradizionale (e ancora prevalente) all’Application Security (AppSec) consiste nel creare un team di specialisti della sicurezza e sanzionarli con il gatekeeping. In queste situazioni, i test di sicurezza vengono comunemente implementati come una funzione di gating pre-release o una regolare revisione e analisi formale del codice.

In entrambe le circostanze, i team di sicurezza che svolgono semplicemente il loro lavoro hanno il “piacere” di dire ai team di sviluppo che il loro codice presenta difetti di sicurezza.

“Sviluppatori, il tuo bambino è brutto!”

Indipendentemente da quanto sia ben e con delicatezza erogato, questo processo crea una resistenza significativa e persino risentimento tra i team di sviluppo.

Inutile dire che questo ricorda le pratiche di test tradizionali in cui il controllo qualità (QA) aveva il potere di interrompere il flusso di prodotti con messaggi simili.

Agile, e successivamente DevOps, hanno fatto enormi passi avanti nell’area dei test integrando i test nel ciclo di vita dello sviluppo e rendendolo una pratica collaborativa e inclusiva.

Sfortunatamente, i passaggi per “spostare a sinistra” i test di AppSec non hanno avuto successo. In parte, ciò è dovuto alle sfide degli strumenti più tradizionali, ma c’è anche un problema con il team di AppSec in corso.

L’implementazione degli strumenti SAST (static Application Security Testing) diventa un ostacolo per i team di sviluppo, con livelli elevati di falsi positivi che aggiungono carichi di lavoro non necessari e non pianificati. Di solito è un processo lento che riduce le velocità di sviluppo dell’integrazione continua/distribuzione continua (CI/CD). Il test dinamico della sicurezza delle applicazioni (DAST) e il test di penetrazione portano avanti i problemi degli approcci tradizionali ad AppSec, poiché sono implementazioni “a posteriori” anche se automatizzate.

In questi scenari, i team di sviluppo stanno, infatti, esaminando le pratiche e dicendo comunemente ai team di sicurezza che il loro bambino è brutto. È così che il problema si perpetua.

Inoltre, i team di sicurezza sono ancora disconnessi dai team di sviluppo e hanno un ruolo di “supervisione” e “autoritario” nelle organizzazioni. Sono spesso visti come un problema e non come parte della soluzione.

I “manifesti” Agile e DevOps non hanno mai escluso AppSec. In DevOps, c’è sicuramente più di un cenno in quella direzione. Nessuno dei due, tuttavia, è stato particolarmente disponibile sulla questione.

Quindi, come possiamo sbarazzarci della “Sindrome del bambino brutto” e crescere?

Per me, ci sono due soluzioni: una tecnica, una relativa alle persone.

Per quanto riguarda le persone, mentre AppSec rimane un ambito altamente complesso che richiede alcune competenze specialistiche, le organizzazioni dovrebbero scegliere di abilitare i team di sviluppo attraverso l’apprendimento contestuale. Questo concetto coglie l’opportunità di una vulnerabilità rilevata per fornire formazione basata sul contesto situazionale agli individui su detto tipo di vulnerabilità. Gli individui apprendono in modo più efficace quando viene fornito come parte del lavoro quotidiano e, risolvendo la vulnerabilità prima della revisione tra pari, ottengono complimenti sociali per il codice pulito. Lavorando all’interno del team, la condivisione delle conoscenze da parte di individui abilitati aggiunge un elemento distribuito e di grande impatto che non si trova nei tradizionali corsi di sicurezza. Questo aiuta a incorporare la sicurezza come parte del ciclo di vita dello sviluppo e aumenta la consapevolezza e il coinvolgimento di tutti.

Dal punto di vista tecnico, gli strumenti devono essere appropriati per l’odierno mondo in rapida evoluzione dello sviluppo di applicazioni. Strumenti come l’Interactive Application Security Testing (IAST) che possono integrarsi facilmente nel ciclo di vita dello sviluppo aggiungendo valore con un impatto minimo stanno diventando essenziali.

A differenza di SAST (che deve indovinare dal codice sorgente) o DAST e test della penna, che devono indovinare dall’esterno, IAST funziona all’interno dell’applicazione. In quanto tale, ha una conoscenza intima e dettagliata dell’applicazione e può prendere decisioni informate e informate sulle vulnerabilità.

L’implementazione multipunto di IAST è un must, secondo me. È essenziale nell’elaborazione automatizzata dei test e nel controllo qualità in cui viene esercitata l’applicazione. Ma è anche essenziale negli ambienti degli sviluppatori, dove può valutare il codice scritto di recente come parte della richiesta pull e del processo di revisione.

Come al solito, torniamo alle persone, al processo, al prodotto…

  • Persone: educare, abilitare ed entusiasmare i team di sviluppatori per promuovere il coinvolgimento con il problema,
  • Processo: implementa gli strumenti e coinvolgi i team in modo che la sicurezza diventi parte della soluzione e
  • Prodotto: trova strumenti (come Contrast Assess) che massimizzino i guadagni e riducano al minimo il dolore.

Fare clic qui per ulteriori informazioni sulla valutazione del contrasto.

Andrew Stickland, Direttore dei servizi ai clienti (internazionale), Contrast Security

Andrew Stickland, Direttore dei servizi ai clienti (internazionale), Contrast Security

Andrew Stickland è il Direttore dei servizi ai clienti di Contrast Security e vanta oltre tre decenni di esperienza nell’arena dello sviluppo software. Con ruoli da Application Developer a Development Manager, Technical Account e Enterprise Account Manager, ha creato applicazioni e supportato la loro realizzazione di valore nel corso degli anni. Andrew è un appassionato sostenitore della sicurezza delle applicazioni e rende il mondo un posto più sicuro. Considera la sicurezza delle applicazioni una sfida di qualità e ritiene che, come i bug, le vulnerabilità (e quindi AppSec) debbano davvero essere di proprietà dei team di sviluppo: AppSec è sempre stata una parte intrinseca della premessa DevOps, ma abbiamo molta strada da fare.

Come sviluppatore, ti è mai stato detto che tuo figlio è brutto?

Hai sudato sangue e lacrime costruendo quell’applicazione rivoluzionaria o creando la funzionalità rivoluzionaria solo per sentirti dire che non puoi rilasciarla?

L’approccio tradizionale (e ancora prevalente) all’Application Security (AppSec) consiste nel creare un team di specialisti della sicurezza e sanzionarli con il gatekeeping. In queste situazioni, i test di sicurezza vengono comunemente implementati come una funzione di gating pre-release o una regolare revisione e analisi formale del codice.

In entrambe le circostanze, i team di sicurezza che svolgono semplicemente il loro lavoro hanno il “piacere” di dire ai team di sviluppo che il loro codice presenta difetti di sicurezza.

“Sviluppatori, il tuo bambino è brutto!”

Indipendentemente da quanto sia ben e con delicatezza erogato, questo processo crea una resistenza significativa e persino risentimento tra i team di sviluppo.

Inutile dire che questo ricorda le pratiche di test tradizionali in cui il controllo qualità (QA) aveva il potere di interrompere il flusso di prodotti con messaggi simili.

Agile, e successivamente DevOps, hanno fatto enormi passi avanti nell’area dei test integrando i test nel ciclo di vita dello sviluppo e rendendolo una pratica collaborativa e inclusiva.

Sfortunatamente, i passaggi per “spostare a sinistra” i test di AppSec non hanno avuto successo. In parte, ciò è dovuto alle sfide degli strumenti più tradizionali, ma c’è anche un problema con il team di AppSec in corso.

L’implementazione degli strumenti SAST (static Application Security Testing) diventa un ostacolo per i team di sviluppo, con livelli elevati di falsi positivi che aggiungono carichi di lavoro non necessari e non pianificati. Di solito è un processo lento che riduce le velocità di sviluppo dell’integrazione continua/distribuzione continua (CI/CD). Il test dinamico della sicurezza delle applicazioni (DAST) e il test di penetrazione portano avanti i problemi degli approcci tradizionali ad AppSec, poiché sono implementazioni “a posteriori” anche se automatizzate.

In questi scenari, i team di sviluppo stanno, infatti, esaminando le pratiche e dicendo comunemente ai team di sicurezza che il loro bambino è brutto. È così che il problema si perpetua.

Inoltre, i team di sicurezza sono ancora disconnessi dai team di sviluppo e hanno un ruolo di “supervisione” e “autoritario” nelle organizzazioni. Sono spesso visti come un problema e non come parte della soluzione.

I “manifesti” Agile e DevOps non hanno mai escluso AppSec. In DevOps, c’è sicuramente più di un cenno in quella direzione. Nessuno dei due, tuttavia, è stato particolarmente disponibile sulla questione.

Quindi, come possiamo sbarazzarci della “Sindrome del bambino brutto” e crescere?

Per me, ci sono due soluzioni: una tecnica, una relativa alle persone.

Per quanto riguarda le persone, mentre AppSec rimane un ambito altamente complesso che richiede alcune competenze specialistiche, le organizzazioni dovrebbero scegliere di abilitare i team di sviluppo attraverso l’apprendimento contestuale. Questo concetto coglie l’opportunità di una vulnerabilità rilevata per fornire formazione basata sul contesto situazionale agli individui su detto tipo di vulnerabilità. Gli individui apprendono in modo più efficace quando viene fornito come parte del lavoro quotidiano e, risolvendo la vulnerabilità prima della revisione tra pari, ottengono complimenti sociali per il codice pulito. Lavorando all’interno del team, la condivisione delle conoscenze da parte di individui abilitati aggiunge un elemento distribuito e di grande impatto che non si trova nei tradizionali corsi di sicurezza. Questo aiuta a incorporare la sicurezza come parte del ciclo di vita dello sviluppo e aumenta la consapevolezza e il coinvolgimento di tutti.

Dal punto di vista tecnico, gli strumenti devono essere appropriati per l’odierno mondo in rapida evoluzione dello sviluppo di applicazioni. Strumenti come l’Interactive Application Security Testing (IAST) che possono integrarsi facilmente nel ciclo di vita dello sviluppo aggiungendo valore con un impatto minimo stanno diventando essenziali.

A differenza di SAST (che deve indovinare dal codice sorgente) o DAST e test della penna, che devono indovinare dall’esterno, IAST funziona all’interno dell’applicazione. In quanto tale, ha una conoscenza intima e dettagliata dell’applicazione e può prendere decisioni informate e informate sulle vulnerabilità.

L’implementazione multipunto di IAST è un must, secondo me. È essenziale nell’elaborazione automatizzata dei test e nel controllo qualità in cui viene esercitata l’applicazione. Ma è anche essenziale negli ambienti degli sviluppatori, dove può valutare il codice scritto di recente come parte della richiesta pull e del processo di revisione.

Come al solito, torniamo alle persone, al processo, al prodotto…

  • Persone: educare, abilitare ed entusiasmare i team di sviluppatori per promuovere il coinvolgimento con il problema,
  • Processo: implementa gli strumenti e coinvolgi i team in modo che la sicurezza diventi parte della soluzione e
  • Prodotto: trova strumenti (come Contrast Assess) che massimizzino i guadagni e riducano al minimo il dolore.

Fare clic qui per ulteriori informazioni sulla valutazione del contrasto.

Leave a Comment

Your email address will not be published. Required fields are marked *