Oh sì, ho letteralmente appena finito di triaging attraverso un rapporto pieno di falsi positivi (ho sollevato un biglietto legittimo da un rapporto DAST di 20 pagine). E con ciò intendo che, come nell'esempio di @BrianWilliams, lo strumento è corretto segnalarli perché potrebbero essere reali in alcuni scenari, ma è necessario un analista esperto per decidere se applicare o meno in questo scenario. Alcuni esempi che ho visto nell'ultima ora:
-
umask di default troppo ampio . La mia analisi: irrilevante perché si tratta di un dispositivo IoT in cui l'app viene eseguita come root comunque.
-
Le protezioni di ClickJacking su X-Frame non sono state impostate . La mia analisi: irrilevante perché è su pagine web statiche e non interattive.
-
Protezione CSRF mancante . La mia analisi: errata, una volta effettuato l'accesso, conta il token di autenticazione (non cookie), ma lo strumento cerca ciecamente un'intestazione chiamata "CSRF".
-
TLS 1.0 è abilitato . La mia analisi: Sì, ne abbiamo bisogno per compatibilità!
-
Partizione montata con opzioni deboli La mia analisi: irrilevante perché se riesci a entrare nel dispositivo per infettare la partizione, allora sei già all'interno del dispositivo ...
Sì, potremmo (e probabilmente dovremmo) correggerli solo per essere meno sciatti, ma non sono sfruttabili in questa applicazione, quindi non è più un problema di sicurezza e viene accorpato con altre attività di cancellazione del debito / codice tecnico.
Alla tua domanda:
Does DAST needs the same time and effort from developer and security analyst to filter out false positives?
Vuoi che gli sviluppatori facciano parte del processo in modo tale che migliorino costantemente le loro capacità di sicurezza e scriveranno un codice più sicuro! La quantità di hand-holding dipende dalle capacità dello sviluppatore.
Con alcuni team devo fare il 100% del triage dei rapporti e aprire ticket per cose specifiche che devono essere cambiate. Per gli altri team mi associo con gli sviluppatori, e per un team di sviluppatori veterani, fanno quasi il 100% del triage e firmo la loro analisi prima di ogni uscita.
Per me, un analista della sicurezza che chiede ciecamente che tutto in un rapporto SAST / DAST sia corretto è pigro o non ha alcuna conoscenza delle tecnologie che dovrebbero proteggere.
Sembra che devi impegnarti un po 'di più nel tuo processo di triage e, come analista della sicurezza, scavare un po' di più per capire quale delle due vulnerabilità segnalate sta per decidere se è davvero necessario avrà l'effetto collaterale di espandere le tue abilità).
Per parafrasare il grande Tanya Janca :
"The easiest way to create hostility between Dev and Security teams is to blindly throw automated reports at the developers and say FIX IT!" - Tanya Janca