Contatta il reparto vendite 800 13.40.41 | Richiedi il Supporto Partner

Articoli

Icona delle News




Hai paura dei test di sicurezza nell'SDLC?

Hai paura dei test di sicurezza SDLC

08/07/21 CoreTech Blog

I DevOps hanno semplicemente paura di provare qualcosa di nuovo. Sono abituati ai Selenium Tests che intasano le condutture e forniscono risultati difficili da interpretare, ma allo stesso tempo spesso evitano i test DAST, che non sono affatto fastidiosi.

Di recente, ho avuto un'interessante discussione con un senior QA tester presso un'azienda di medie dimensioni che sviluppa applicazioni web avanzate per la pianificazione della supply chain B2B. Volevo semplicemente saperne di più sul loro processo di test QA. Sentivo che dovevano averlo gestito abbastanza bene perché questa azienda è rinomata per assumere i migliori laureati delle migliori università del paese. È noto per essere innovativo, agile e per il resto un buon esempio di come dovrebbero essere fatte le cose nel settore.

Sono rimasto scioccato nell'apprendere che il processo di controllo della qualità non è così facile e agevole come pensavo.

Banner

Poiché le loro applicazioni sono completamente sviluppate in Java, i loro processi di controllo qualità comportano tre tipi di test. Innanzitutto, ci sono semplici unit test scritti nello stesso Java. Fondamentalmente, un test accede a una singola funzione, la alimenta con dati di esempio, prende i valori di output e confronta i valori di output con i valori previsti. Niente di più.

Poi ci sono i test funzionali e di integrazione del Selenium. Questi test passano attraverso tutte le schermate e sostanzialmente tentano di far agire Selenium come un semplice crawler. Quel crawler, in base alla progettazione, non raggiunge affatto le schermate di amministrazione, configurazione o reporting.

La struttura DOM risultante da ogni azione Selenium viene confrontata con i dati previsti (registrati manualmente in precedenza). Se c'è una discrepanza, Selenium prende uno "screenshot" dell'applicazione e sostanzialmente dice allo sviluppatore "c'è un errore da qualche parte qui su questa schermata, trovalo e correggilo".

L'intero processo di test QA per il loro prodotto principale richiede... circa 4 ore. La maggior parte di questo tempo viene consumato dai test del selenio. Il processo richiederebbe almeno il doppio se non riducessero la creazione di nuovi contenitori Docker. Dopo ogni test, eseguono semplicemente una serie di comandi SQL e caricano il contenuto del database predefinito invece di caricare l'intero ambiente.

Prima di parlare con lui, la mia conoscenza dei test QA era piuttosto teorica. Dopo il discorso, mi sono sentito scioccato. Non mi sarei mai aspettato che i Selenium Tests impiegassero così tanto tempo e che il povero sviluppatore avesse solo uno screenshot come guida!

E poi, mi sono venute in mente due pensieri.

Il primo pensiero era in realtà una domanda. Perché i manager DevOps diffidano dei test DAST nell'SDLC? Perché dicono che ci vuole molto tempo quando i Selenium Tests richiedono molto più tempo? Perché si lamentano che DAST non punta a una riga di codice mentre i loro test Selenium danno agli sviluppatori solo uno screenshot dell'applicazione?

Posso solo immaginare che sia semplicemente perché i test DAST in SDLC sono nuovi per loro o hanno avuto alcune brutte esperienze nel tentativo di eseguire prodotti DAST gratuiti. Dal mio punto di vista un test DAST nell'SDLC richiederebbe una frazione del tempo consumato dal Selenium tTests e fornirebbe agli sviluppatori molte più informazioni sull'errore! Ciò, ovviamente, non risolverebbe i problemi, ma non occuperebbe le condutture più di quanto non lo siano già.

Il secondo pensiero che mi è venuto in mente è stato associato ad alcune proposte di marketing che ho letto, provenienti da un rinomato produttore di strumenti passivi IAST. Quei materiali di marketing promuovevano falsamente il loro prodotto come più completo di un IAST attivo/vero. Se i test dell'azienda di M. saltassero completamente tutte le schermate di amministrazione, configurazione e reporting, quanto sarebbe sicura la loro applicazione se fosse testata utilizzando IAST passivo? Dopotutto, i test di sicurezza ignorerebbero completamente una parte importante della funzionalità del prodotto.

Dopo il discorso, sono giunto a due conclusioni. Prima di tutto, non sono le capacità dei prodotti DAST il vero motivo per cui molte aziende non riescono a implementare i primi test. In secondo luogo, ho confermato la mia convinzione che IAST passivo non sia un buon modo per proteggere la tua applicazione.

 

articolo di di Tomasz Andrzej Nidecki


Articoli su Sicurezza

La 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
Ripe Ncc Member
vmware
CloudLinux
Plesk
HP
Microsoft