Qual è la differenza tra lo standard di codifica sicuro CERT C e altri standard di codifica?

CERT C è una guida specifica per scrivere "software sicuro e resiliente in C e C ++". L'attenzione si concentra su consigli specifici del linguaggio su cosa fare e cosa non fare con quello che è un linguaggio molto potente che presuppone che tu sappia cosa stai facendo. Tieni presente che questi linguaggi vengono spesso utilizzati nella scrittura di codice di basso livello per i dispositivi dell'infrastruttura o per i sistemi incorporati, quindi è fondamentale che siano scritti bene.

PCI-DSS è specifico per il settore dei pagamenti ed è una combinazione di istruzioni pratiche e politiche che non sono specifiche del codice. Vale la pena leggere se memorizzi informazioni sulla carta di credito o per informazioni generali sulle buone pratiche di sicurezza, ma non direttamente correlate a te altrimenti.

La CWE Top 25 è una lista degli errori software più comuni commessi da persone che scrivono software indipendentemente dalla lingua o dallo scopo.

OWASP Top 10 è l'elenco delle vulnerabilità più comuni nelle applicazioni basate sul Web, che include le vulnerabilità non codificate.

NIST SAMATE fa parte di un framework di garanzia software. Descrive dettagliatamente i processi e le pratiche intorno assicurando che un prodotto software faccia solo ciò che è inteso e sia libero da manomissioni.

Quindi, in breve, usa CERT C per i tuoi C e C ++. E leggi e incorpora la Top x come appropriato ai tuoi prodotti software. SAMATE è molto più grande del tuo compito.

L'ultima volta che stavo iniziando a greenfields (2006) abbiamo usato un libro chiamato "The Elements of C # Style" come la nostra bibbia standard. L'abbiamo usato solo per risolvere le controversie in cui la squadra non era d'accordo su un approccio. Non so se riflette l'ultima versione di C # però.

Per i motivi descritti sopra da @ DodgyG33za, lo standard di codifica CERT C comunicherà in modo più efficace con gli sviluppatori. Per inciso, The CERT Java Coding Standard è suddiviso in due sezioni: Regole Java e Linee guida per la codifica Java . Vi sono numerosi altri riferimenti disponibili commercialmente da Gary McGraw, John Viega, Jason Grembi, Mike Howard, ecc. Avendo lavorato su di loro, sono parziale al DHS Software Assurance Pocket Guide Series .

Il OWASP Top 10 fornisce un inizio ma OWASP Developers Guide v2.9 (2005) fornisce maggiori dettagli e discussioni. "Sfortunatamente, la Guida per gli sviluppatori OWASP non è mai decollata con il pubblico previsto: sviluppatori." Attualmente in fase di revisione, la Guida per gli sviluppatori è stata più un modo per eseguire un test di penetrazione delle applicazioni Web, materiale ora meglio trattato nel OWASP Guida ai test . La Guida ai test è stata pubblicata nel 2014 e fornisce la Prospettiva dell'interruttore . La Guida alla revisione del codice OWASP fornisce materiale aggiornato da Prospettiva di Defender . A proposito, PCI cita la Top 10 di OWASP come un criterio per la conformità.

L' enumerazione delle debolezze comuni è più uno strumento analitico per "l'uso di strumenti e servizi di sicurezza del software che possono trovare questi punti deboli nella fonte codice e sistemi operativi, nonché una migliore comprensione e gestione delle debolezze del software legate all'architettura e al design. " Le attenuazioni in CWE possono fornire informazioni ma non specifiche per la correzione del codice. Allo stesso modo il NIST SAMATE Project "è dedicato a migliorare la sicurezza del software sviluppando metodi per abilitare la valutazione degli strumenti software, misurando l'efficacia degli strumenti e tecniche, e identificare le lacune in strumenti e metodi. " Come CWE, SAMATE non fornisce agli sviluppatori linee guida per la codifica. Piuttosto SAMATE è un progetto di ricerca che supporta i produttori di strumenti e gli accademici con il Dataset di riferimento Software Assurance (SARD) e il Static Analysis Tool Exposition (SATE). Questi sono contributi preziosi per Software Assurance ma non risorse che si fornirebbero direttamente agli sviluppatori.