More Mature Secure Coding Standards

The idea is simple, yet very much needed. Defining coding standards for dev teams risks to become an sterile exercise of creating a confluence page that can be soon forgotten. Better than that is to invest in a secure coding training. Yet,usually, secure coding training, as well as many other resources are very generic, in both terms of field (web applications) and in term of languages (not even talk about specific frameworks. It results also in defining coding standards as apply OWASP TOP 10 and some SEI CERT coding standards. But what about a non-web application? Should you really care about XML External Entities (XXE) or Cross Site Scripting XXS? Imposing such a list on developers that are not dealing with XML or web applications will not make them feel understood and helped, and you will not be able to expect that those coding standards will improve the security of the project  code. 

Here's an approach that may improve the maturity of the definition of secure coding standards. By doing a threat model you are basically asking (among other thing): What can go wrong? The answer to that question should be in terms of design flaws but also in terms of (likely) secure coding failures.
If your project is about a shared system library, a specific protocol server: what can go wrong in it?
Can you have a classic buffer overflow? Probably yes if you are using a language that allows you to manage the memory allocation, e.g. C or C++. How is this impacting your coding standards, also based on the specific language?
Here the CWE (Common Weaknesses Enumeration) comes handy. Let's look at the example:
from http://cwe.mitre.org/top25/index.html#CWE-120

Here you can have some info about the context of this kind of vulnerability, including testing, architectural mitigation etc...

Here's how you can proceed in a structure approach:

1) Create a list of CWE impacting your project

     a) From formal Threat Model

     b) Iterating and picking applicable CWE from SANS-TOP 25

2) Based on your architecture, design, programming language, framework identify specific mitigations AND coding standards. Of course coding standards should be enforces with specific secure coding training and code review. But without a contextual, hand-pickerd list of coding standards and examples developers will feel overwhelmed and will not see value in it.

Of course SEI CERT will not cover all languages, but this approach is also applicable if a secure code SME (subject matter expert) helps to define the mitigation. By applying more mitigation to the same threat/vulnerability you will also apply "Defense in Depth" principle.