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 versus Nonnormative 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 rules are the requirements for conformance with the standard. Normative statements use imperative language such as must, shall, and require. Normative portions of each rule must be analyzable, although automated analysis is infeasible for some rules and is not required.
The nonnormative portions of a rule describe good practices or useful advice. Nonnormative statements do not establish conformance requirements. Nonnormative statements use verbs such as should and phrases such as is recommended or is good practice. Nonnormative portions of rules may be inappropriate for automated checking because such checking would likely report excessive false positives when applied to existing code. Automated checkers for these nonnormative portions might be useful when analyzing new code (that is, code that has been developed to this coding standard).
All of the rules in this standard have a normative component. Nonnormative recommendations are provided only when
- there is well-known good practice to follow.
- the rule describes an approach that, if universally followed, would avoid violations where the normative part of the rule applies and would also be harmless when applied to code in which the normative part of the rule is inapplicable.
Entirely nonnormative guidelines are excluded from this coding standard, but the authors of this book plan a follow-on effort to publish these guidelines.
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 security indicator or metric. Although 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 Standard for Java is to use a certified validated source code analysis tool.
Levels
Guidelines in this standard are classified into three levels (see Rule: Priority and Levels). Emphasis should be placed on conformance Level 1 (L1) guidelines. Software systems that have been are validated as complying with all Level 1 guidelines are considered to be L1 Conformingconforming. Software systems can be assessed as L1, L2, or fully conforming depending on the set of guideline guidelines to which the system has been validated.
Rules versus Recommendations
Conformance to secure coding guidelines 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 codeis 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 as well as in 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, programmers are not always in a position to modify third-party library code or perhaps even to convince the vendor to modify the code. Consequently, 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, whereas for third-party libraries, it might be easier to document a deviation.