Obiettivi raggiunti

  • Processo di implementazione senza configurazione

  • Sfruttamento dei processi esistenti in SDLC

  • Record dettagliati delle vulnerabilità di sicurezza

To who

  • Settore: IT

  • Prodotti: HCL AppScan

  • Regione: Nord America/Stati Uniti

Panoramica

  • Parte 1

    Sfida

    Il nostro cliente si è trovato a dover affrontare le seguenti sfide aziendali:

    Miglioramento della protezione dei propri prodotti senza interrompere l'attuale processo SDLC.

    Riduzione della probabilità di problemi di sicurezza che potrebbero ritardare la spedizione delle nuove versioni.

  • Parte 2

    Soluzione

    Integrazione di IAST nel processo di controllo qualità esistente del cliente e utilizzo di test automatici, manuali e sanity test per estendere la copertura dei test di sicurezza delle applicazioni (AST) e trasformare DevOps in DevSecOps.

  • Parte 3

    Risultati

    Miglioramento della copertura AST e dei processi di correzione, grazie a record informativi dei problemi di sicurezza, come stack di chiamate completi ed esempi di exploit segnalati dall'agente IAST.

La sfida

Caso aziendale per IAST

L'azienda utilizzava già DAST come parte del proprio SDLC, principalmente nelle fasi finali. Questa pratica comune forniva buoni risultati, ma presentava diversi svantaggi:

  • Quando veniva scoperta una vulnerabilità di sicurezza significativa, si verificava un ritardo nel rilascio, poiché DAST veniva introdotto come uno degli ultimi passaggi prima della spedizione di una nuova versione. Le misure di correzione delle vulnerabilità di sicurezza erano elevate a causa delle informazioni meno dettagliate fornite dallo scanner DAST.
  • C'era un notevole intervallo di tempo tra la scrittura del codice e la scoperta delle vulnerabilità.

quote icon

Siamo rimasti sorpresi dal processo di implementazione. Ci aspettavamo qualcosa di più complicato dell'implementazione di un file WAR sul nostro Tomcat!

Technical Manager DevOps team

La soluzione

Integrating IAST

L'azienda dispone di un processo di controllo qualità (QA) molto articolato, data la dimensione e la complessità del proprio codice base. Il processo di controllo qualità comprende test automatizzati e manuali che spaziano da semplici scenari sanity a casi limite più complessi. Ogni nuova versione aggiungeva anche ulteriori funzionalità, quindi sono stati introdotti ulteriori test nel processo di controllo qualità.

L'infrastruttura di controllo qualità è basata su Docker e orchestrata utilizzando Jenkins. Poiché il team non voleva modificare i contenitori esistenti, ha deciso di integrare IAST usufruendo di un semplice script che utilizza le API di AppScan per scaricare e distribuire l'agente sul server web, dopo che le applicazioni sono state compilate e pubblicate con successo.

La quantità di informazioni che ricevo per ogni problema è utile per il processo di prioritizzazione e correzione.

System Architect

I risultati

Effects

Un vantaggio significativo segnalato immediatamente dagli sviluppatori è stata la quantità di informazioni contenute nelle vulnerabilità di sicurezza. Disporre della riga di codice che ha originato il problema, insieme a un esempio di exploit che lo ha attivato, ha ridotto significativamente gli sforzi di risoluzione. Poiché il processo di controllo qualità è adiacente al processo di sviluppo, le modifiche al codice che hanno portato a nuove vulnerabilità di sicurezza sono ancora ben impresse nella mente degli sviluppatori nell'avvicinarsi alla risoluzione dei problemi di sicurezza.

Un altro vantaggio segnalato dal team di sicurezza è stata la riduzione dei problemi rilevati nella scansione DAST, poiché il processo di controllo qualità ora contribuisce a risolvere i problemi in una fase precedente di SDLC.

Dal punto di vista della manutenzione, i team di sicurezza e DevOps sono rimasti impressionati dal fatto che l'integrazione dell'agente IAST richiede un solo semplice script e che l'agente stesso è evergreen (ovvero, si aggiorna automaticamente). Un altro aspetto positivo è che il team di controllo qualità può continuare ad aggiungere nuovi test per ogni nuova funzionalità sviluppata, mantenendo aggiornata la copertura AST con ogni nuova versione. Il processo continua a migliorare come sottoprodotto dello stesso SDLC.

Informazioni sull'azienda

Data la natura sensibile del settore della sicurezza informatica, l'azienda ha chiesto di rimanere anonima in questo specifico case study. Si tratta di un'azienda di software che opera nel mercato IT fornendo servizi alle PMI e alle grandi imprese.

Lo stack tecnologico utilizzato in questo case study è:

  • Java
  • Tomcat
  • Docker
  • Jenkins

Funzionalità correlate