We are updating our C, C++ and C# coding standards to include security requirements. I know there are coding standards based on the following:
What is the difference bet these and the CERT C secure coding standard?
Thanks
CERT C is specific guiance on writing "secure and resilient software in C and C++". The focus is on language specific advice on what to do and what not to do with what is a very powerful language that assumes you know what you are doing. Note that these languages are often used in writing low level code for infrastructure devices, or for embedded systems, so it is vital that they are well written.
PCI-DSS is specific to the payments industry and is a mixture of practice and policy statements that are not code specific. Worth reading if you store credit card information, or for general information on good security practice, but not directly related to you otherwise.
The CWE Top 25 is a list of the most common software mistakes made by people writing software regardless of language or purpose.
The OWASP Top 10 is the list of most common vulnerabilities in web based applications, which includes non-coded vulnerabilities.
NIST SAMATE is part of a software assurance framework. It details the processes and practices around ensuring that a software product does only what is intended, and is free from tampering.
So in short, DO use CERT C for your C and C++. And read and incorporate the Top x as appropriate to your software products.SAMATE is far bigger than your task at hand.
Last time I was starting out greenfields (2006) we used a book called "The Elements of C# Style" as our standards bible. We only used it to settle disputes where the team could not agree on an approach. I don't know if it reflects the latest version of C# though.
For the reasons described above by @DodgyG33za, the CERT C Coding Standard will communicate most effectively with developers. As an aside, The CERT Java Coding Standard is split into two sections: Java Rules and Java Coding Guidelines. There are numerous other references available commercially by Gary McGraw, John Viega, Jason Grembi, Mike Howard, etc. Having worked on them, I am partial to the DHS Software Assurance Pocket Guide Series.
The OWASP Top 10 provides a start but the OWASP Developers Guide v2.9 (2005) gives more detail and discussion. "Unfortunately, the OWASP Developer Guide never really took off with the intended audience: developers." Currently under revision, the Developer Guide was more a how to perform a web application penetration test, material now better covered in the OWASP Testing Guide. The Testing Guide came out in 2014 and gives the Breaker Perspective. The OWASP Code Review Guide provides updated material from the Defender's Perspective. By the way, PCI cites the OWASP Top 10 as one criteria for compliance.
The Common Weakness Enumeration is more an analytical tool for the "use of software security tools and services that can find these weaknesses in source code and operational systems as well as better understanding and management of software weaknesses related to architecture and design." The mitigations in the CWE can provide insight but not specifics for code remediation. Likewise the NIST SAMATE Project "is dedicated to improving software assurance by developing methods to enable software tool evaluations, measuring the effectiveness of tools and techniques, and identifying gaps in tools and methods." Like the CWE, SAMATE does not provide developers with coding guidelines. Rather SAMATE is a research project that supports the tool makers and academics with the Software Assurance Reference Dataset (SARD) and the Static Analysis Tool Exposition (SATE). These are valuable contributions to Software Assurance but they not resources one would provide directly to developers.
