Software systems can be validated as conforming to the CERT Oracle Secure Coding Standard for Java. Source code analysis tools, including compilers and static analysis tools, can be certified as able to validate source code as conforming to this coding standard.
Normative vs. Non-normative Text
Portions of this coding standard are intended to be normative; other portions are intended as good advice. The normative statements in these guideline are the requirements for conformance with the standard. Normative statements use imperative language, for example, "must," "shall," "require," etc. Normative portions of each guideline must be analyzable, although automated analysis is infeasible for some guidelines.
...
Entirely non-normative guidelines are not included in this coding standard, but will be covered in a follow on publication: Recommendations for Secure Coding in Java.
Source Code Conformance
Conformance to The CERT Oracle Secure Coding Standard for Java can be used as as security indicator or metric. While conformance does not guarantee the absence of vulnerabilities (for example, vulnerabilities resulting from design flaws), it does guarantee the absence of coding errors that are commonly found to be the root causes of vulnerabilities.
The easiest way to validate code as conforming to The CERT Oracle Secure Coding standard for Java is to use a validated source code analysis tool.
Levels
Guidelines in this standard are classified into three levels (see Priority and Levels). Emphasis should be placed on conformance Level 1 (L1) guidelines. Software systems that have been validated as complying with all Level 1 guidelines are considered to be L1 Conforming. Software systems can be assessed as L1, L2, or fully conforming depending on the set of guideline to which the system has been validated.
Deviation Procedure
Strict adherence to all guidelines is unlikely. Consequently, deviations associated with individual situations are permissible.
...
To claim compliance with this standard, software developers must be able to produce on request documentation as to which systematic and specific deviations have been permitted during development.
Third-party Libraries
Static analysis tools such as FindBugs! that analyze Java bytecode can frequently discover violations of this secure coding standard in third party libraries in addition to custom code. Violations of secure coding rules in third-party libraries are treated in the same manner is if they appeared in custom code.
Unfortunately, developers are not always in a position to modify third-party library code, or perhaps even convince the vendor to modify the code. This means that the system cannot pass conformance testing unless the problem is eliminated (possibly by replacing the library with another library or custom developed code) or by documenting a deviation. The deviation procedure for third-party library code is also the same as for the custom code, that is, the developer must show that the violation does not cause a vulnerability. However, the economics may be different. For custom code it may be more economic to repair the problem where for third-party libraries it might be easier to document a deviation.