metriche di sicurezza sui software sviluppati

Dì che tutte le metriche che hai elencato nella tua domanda riportano zero. Significa che il tuo software è sicuro? Trovare 0 bug significa che non ci sono bug?

Il motivo per cui hai difficoltà a trovare metriche solo software è perché il software non esiste nel vuoto. Ecco una domanda altrettanto difficile: quanto vale un valore

Ci sono diverse domande che vorrei chiedere se qualcuno mi ha appena consegnato un rapporto con le metriche che hai elencato qui.

Quali politiche di sicurezza vengono valutate con le tue metriche? Per quanto io disprezzi l'argomento (BOOOOORING !!!!), la sicurezza in qualsiasi organizzazione - e quindi il suo software - deve basarsi su una solida politica di sicurezza. E concentrarsi sul solo software come si vuole fare nella tua domanda è di sottrarre un pezzo che non dovrebbe essere aggirato. E ricorda che le policy possono determinare la gravità di alcuni bug rispetto agli altri.

Detto questo:

OWASP ha una presentazione qui che potrebbero interessarti.

Avvertenze dalla presentazione: Metriche sulla sicurezza del software

• Le metriche sono sensibili al contesto e dipendenti dall'ambiente
• Affidabilità dell'architettura
• L'aggregazione non può portare a forza

Ecco alcune metriche che elencano:

• Dimensioni e complessità
• Debolezza / LOC (CWE)
• Debole (gravità, tipo) nel tempo (CVSSv2, CWE)
• Costo per difetto
• Superficie di attacco (numero di interfacce)
• Livelli di sicurezza
• Design Flaws (CWE)

E questo articolo , sebbene non sia un riferimento unico, fa presentare un metodo per ponderare specifici tipi di difetti di sicurezza, che potrebbero essere utilizzati per sviluppare un sistema di punteggio che è possibile applicare a sviluppatori / applicazioni.

E infine, una statistica molto importante che penso che dovresti prendere in considerazione è il numero di falsi positivi, sia con gli strumenti di test AND che con i tester umani.

E poi c'è CVSS .

Andy Ozment ha proposto un'interessante metrica di sicurezza per il software nel suo articolo Aste dei bug: i mercati delle vulnerabilità sono stati riconsiderati (WEIS 2004) . In parole povere, la sua idea è che un fornitore di software si ponga un premio per la prossima vulnerabilità da trovare. Il premio inizia da un importo fisso (ad esempio 100 $) e cresce ogni giorno (ad esempio 10 $ / giorno). Quando un cacciatore di vulnerabilità (cappello bianco / nero) ha trovato una nuova vulnerabilità, gli viene assegnata l'attuale quantità di denaro e il premio viene riportato all'ammontare iniziale e aumenta di nuovo. Ora dopo un po ', il fornitore del software può utilizzare il premio corrente come metrica di sicurezza per il suo software . Quindi, se il premio ora è di 10000 $, significa che anche con tale incentivo, i cacciatori non riescono ancora a trovare una nuova vulnerabilità e quindi il software è abbastanza sicuro. Ci sono alcune analisi economiche nel documento per mostrare i vantaggi e gli svantaggi di questa idea.

Il documento contiene anche alcune citazioni relative alle metriche di sicurezza del software che potrebbero essere utili. Potrebbero essere vecchi però.

Grazie.