Criteri per la valutazione degli strumenti di analisi statica

Ecco le cose sulla mia lista, che uso per i miei clienti (inclusi alcuni di quelli che hai menzionato):

• Copertura (secondo ciò che l'org richiede oggi e si aspetta di usarlo in futuro)
  • Lingua
  • Architettura (ad esempio alcuni strumenti sono ottimi per le app Web, ma non tanto per i rich client o persino per i servizi / demoni di Windows)
  • Framework (ad esempio supporto per ASP.NET ma non MVC, o Java ma non Spring)
  • Librerie standard (ad esempio riconoscendo Hibernate, log4j o AntiXSS, per nominarne alcune problematiche) necessarie
• Prestazioni di scansione . In questo includo entrambi:
  • Velocità
  • Scalabilità a codebase di grandi dimensioni (inclusi LoC, sottosistemi / progetti e riferimenti esterni)
• Completezza - vale a dire regole / script inclusi nella scansione, sufficienti a fornire confidenza nell'output o, in altre parole, a ridurre i falsi negativi.
  • Si noti che questo è sia l'elenco delle regole fornite (ad esempio controlli per "SQL Injection");
  • E la qualità di questi controlli, cioè in realtà cattura le iniezioni SQL. (Ad esempio, un certo leader nel campo, che rimarrà senza nome, può essere facilmente confuso da molte forme di codeflow, quindi mancano i difetti di iniezione di base.)
• Precisione dei risultati . Questo vale per i risultati che vengono riportati (al contrario di quelli mancanti, trattati in "Completezza"). Scarsa precisione può essere visto in:
  • Numero elevato di falsi positivi
  • duplicati
  • Miscategorizations
  • Misprioritizzazione (ad esempio etichettare un bug a impatto molto basso come "Rischio elevato")
  • Risultati irrilevanti (ovvero un difetto di codice che è accurato, ma completamente irrilevante per l'applicazione o l'architettura, ad esempio ricerca di XSS in un'applicazione non HTML, non HTTP e non interattiva, o SQL Injection su un'applicazione client).
• Personalizzazione - come hai detto, personalizzando fonti, sink e filtri; riferisce anche; ma anche, nientemeno, personalizzando regole / script e aggiungendo logica personalizzata (non solo source- > filter- > sink). Nota che molti strumenti ti permettono di "personalizzare" le loro regole, ma questo è veramente limitato solo all'aggiunta di sorgenti / sink / filtri.
• Sostenibilità / ripetibilità - con questo mi riferisco alla gestione delle scansioni ripetute. Come gestisce i cambiamenti? Problemi precedentemente contrassegnati come falsi positivi? Ricevo confronti?
• Modello di distribuzione , ad es. combinazione di solito di:
  • stazione di auditor singolo
  • server condiviso, accessibile tramite remoto
  • accesso web
  • plug-in per sviluppatori
  • build server pluggability
  • (e ovviamente la possibilità di impostare una politica diversa per ciascuna)
• Usabilità . Ciò comprende:
  • UI (inclusi tasti di scelta rapida, ecc.)
  • capacità di filtraggio degli auditor
  • fornendo un contesto sufficiente evidenziando abbastanza del codeflow
  • testo statico, come spiegazioni, descrizioni, rimedi, collegamenti a fonti esterne, ID in OWASP / CWE, ecc.
  • funzioni utente aggiuntive - ad es. posso aggiungere un risultato manuale (non trovato dalla scansione automatica)?
• Report : entrambi flessibili per progetto in base alle esigenze (non dimenticare i dettagli dettagliati per gli sviluppatori e i responsabili di alto livello) e il cross-project aggregato. Inoltre confronti, ecc. Ecc.
• Sicurezza (nel caso di un modello server) - protezione dei dati, gestione delle autorizzazioni, ecc. (proprio come qualsiasi app del server ...)
• Costo . Questo include almeno:
  • hardware
  • licenza - uno o tutti i seguenti:
    • per posto - revisore
    • per postazione - sviluppatore
    • per postazione - segnala l'utente
    • per server
    • per progetto
    • per linee di codice
    • licenza del sito
  • Manutenzione
  • servizi - ad es. implementazione, tuning, integrazione personalizzata, ecc.
  • training (sia il trainer che il tempo del revisore / degli sviluppatori)
• Integrazione con:
  • controllo del codice sorgente
  • bug tracker
  • ambiente di sviluppo (IDE)
  • build server / CI / CD
  • automazione

Considerando questo aspetto, penso che sia più o meno nell'ordine di preferenza: a partire dai requisiti di base, fino all'applicabilità, alla qualità, alla facilità di implementazione, all'efficienza, al piacere di avere ...

Ecco la cosa più importante da sapere su come valutare uno strumento di analisi statico:

Provalo con il tuo codice.

Lo ripeterò di nuovo. Provalo sul tuo codice. Devi eseguire una versione di prova, in cui la utilizzi per analizzare un tuo codice rappresentativo, quindi analizzarne l'output.

La ragione è che gli strumenti di analisi statica variano in modo significativo nell'efficacia e la loro efficacia dipende dal tipo di codice che tende a essere scritto nella tua azienda. Pertanto, lo strumento che è meglio per la tua azienda potrebbe non essere lo stesso di quello che è meglio per un'azienda in movimento.

Non puoi passare da un elenco di funzioni. Solo perché uno strumento dice che supporta Java non significa che sarà utile nell'analizzare il codice Java, o comunque di analizzare il tuo codice Java e trovare i problemi che ti interessano.

La maggior parte dei fornitori di analisi statiche sarà lieta di aiutarti a creare una versione di prova gratuita in modo che tu possa provare il loro strumento con il tuo codice, quindi prendi in considerazione la loro offerta.

Gary McGraw e John Steven hanno scritto un buon articolo su come scegliere uno strumento di analisi statica della sicurezza . Oltre a cogliere il punto in cui è necessario provare gli strumenti sul proprio codice per vedere quale è il migliore, sottolineano anche che è necessario tenere in considerazione il modo in cui lo strumento può essere personalizzato per il proprio ambiente e le esigenze e il budget per questo costi.

Un lungo elenco di criteri ha la stessa probabilità di distrarti in quanto ti aiuta a trovare una buona soluzione.

Prendi, ad esempio, la questione dei "falsi positivi". È un problema inerente con questi strumenti. La soluzione a lungo termine sta imparando come vivere con loro. Significa che i tuoi programmatori dovranno imparare a codificare attorno allo strumento di analisi statica, apprendere che cosa causa l'attivazione di un falso positivo e scrivere codice in un modo diverso in modo che il falso positivo non venga attivato. È una tecnica familiare con coloro che usano la lanugine, o coloro che cercano di compilare il loro codice senza scaldarsi: modificate il codice finché il falso positivo non si ferma.

Il criterio più grande è capire il problema che stai cercando di risolvere. Vi è un enorme vantaggio nel far sì che i programmatori eseguano il passaggio di un analizzatore statico una sola volta, per rimuovere i maggiori problemi nel codice e imparando francamente cosa dovrebbero sapere sulla programmazione e non fare quegli errori. Ma il valore marginale degli analizzatori statici a funzionamento continuo è molto inferiore e il costo marginale è molto più alto.

Sono stato un grande fan del Gintel's PC-Lint nel corso degli anni per il codice C ++. I maggiori due fattori per me erano la copertura linguistica (nessuno l'aveva in quel momento, davvero) e la "vivibilità". Vivere con l'analisi statica è una specie di cosa soggettiva, come sai. Gimpel ha un capitolo nel loro manuale intitolato "Living with Lint" che fa un buon lavoro parlando attraverso i vari alti e bassi. Rendere vivibile comporta la possibilità di personalizzare gli avvisi e gli errori che vengono emessi, ma in un modo che non gli fa impazzire gli sviluppatori.

In relazione alla scalabilità, ho avuto problemi con gli strumenti di analisi che non sono in grado di far fronte a codice di terze parti - librerie, ecc. Pertanto, in un grande progetto, questa è certamente una considerazione.