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 standard.
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 00.7 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.
Deviations may occur for a specific instance, typically in response to circumstances that arise during the development process or for a systematic use of a particular construct in a particular circumstance. Systematic deviations are usually agreed upon at the start of a project.
For these secure coding guidelines to have authority, it is necessary that a formal procedure be used to authorize these deviations rather than an individual programmer having discretion to deviate at will. The use of a deviation must be justified on the basis of both necessity and security. Guidelines that have a high severity and/or a high likelihood require a more stringent process for agreeing to a deviation than do guidelines with a low severity that are unlikely to result in a vulnerability.
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.