Software systems can be validated as conforming to the CERT Sun Microsystems 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
Source Code Compliance
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.
The non-normative portions of a guideline are those where we describe good practice or useful advice. Non-normative statements do not establish conformance requirements. Non-normative statements use verbs such as "should," or phrases such as "we recommend" or "Good practice is to...". Non-normative portions of guidelines may be inappropriate for automated checking, because such checking would likely report excessive false positives when applied to existing code. Automated checkers for these non-normative portions might be useful when analyzing "new" code that has been developed to this coding standard.
The vast majority of guidelines have a normative component. Non-normative portions exist only when:
- there is well-known good practice to follow
- to describe an approach that, if universally followed, would both avoid violations where the normative part of the guideline applies, and would also be harmless when applied to code where the normative part of the guideline is inapplicable.
Although uncommon, some guidelines are entirely non-normative. The following guidelines, for example, are entirely non-normative:
- NUM52-J. Be aware of numeric promotion behavior
- EXP55-J. Use the same type for the second and third operands in conditional expressions
Source Code Conformance
Conformance to The CERT Oracle The CERT Sun Microsystems Secure Coding Standard for Java can be used as a measure of software security by determining the degree to which a software system complies with the guidelines in this standard. While compliance 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 compliant with the CERT Sun Microsystems conforming to The CERT Oracle Secure Coding standard for Java is to use a certified validated source code analysis tool.
Levels
Guidelines in this standard are classified into three levels (see Rec.: Priority and Levels). Emphasis should be placed on conformance Level 1 (L1) rulesguidelines. Software systems that have been validated as complying with all Level 1 rules guidelines are considered to be L1 Conforming. Software systems can be assessed as L1, L2, or fully conforming depending on the set of rules guideline to which the system has been validated.
Rules versus Recommendations
Conformance to secure coding rules must be demonstrated to claim compliance with this standard unless an exceptional condition exists. If an exceptional condition is claimed, the exception must correspond to a predefined exceptional condition and the application of this exception must be documented in the source code.
Deviation Procedure
Strict adherence to all guidelines is unlikely. Consequently, deviations associated with individual situations are permissible.
...
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. Rules Guidelines that have a high severity and/or a high likelihood require a more stringent process for agreeing to a deviation than do rules guidelines with a low severity that are unlikely to result in a vulnerability.
...