Comments and Contributing

We provide access to the community members to contribute after subject matter expertise is verified.

If you want to provide a suggestion or comment and do not have an account, please submit feedback.

If you have an account but are having problems with access, also please submit a support request.

Accounts are regularly deactivated after extended periods of inactivity. 

The Java rules and recommendations in this wiki are a work in progress and reflect the current thinking of the secure coding community. Because this is a development website, many pages are incomplete or contain errors. As rules and recommendations mature, they are published in report or book form as official releases. These releases are issued as dictated by the needs and interests of the secure software development community.

Create a sign-in account if you want to comment on existing content. If you wish to be more involved and directly edit content on the site, you still need an account, but you'll also need to request edit privileges.   

Secure Java Coding Books

There are two books available that cover Java: one for rules and the other for guidelines.

The CERT Oracle Secure Coding Standard for Java provides rules for Java Platform Standard Edition 6 and Java SE 7.


Java Coding Guidelines: 75 Recommendations for Reliable and Secure Programs provides guidelines, recommendations, and examples to enable the creation of reliable, robust, fast, maintainable, and secure code.
Source Code Analysis Laboratory (SCALe)

SCALe offers conformance testing of Java language software systems against the CERT Oracle Secure Coding Standard for Java.

Contact Us

Contact us if you

  • have questions about the Secure Coding wiki
  • have recommendations for standards in development
  • want to request privileges to participate in standards development
Thank You!

We acknowledge the contributions of the following folks , and we look forward to seeing your name here as well.

Rules vs. Recomendations

This coding standard consists of rules and recommendations, collectively referred to as guidelines. Rules are meant to provide normative requirements for code, whereas recommendations are meant to provide guidance that, when followed, should improve the safety, reliability, and security of software systems. Learn more about the differences.

Linking to Our Pages

Link to guidelines using the Tiny Link under Tools→Link to this Page... (This URL will not change if the name of the guideline changes.)   

Information for Editors

  • To eliminate a section from the lists above, label it section and void.
  • To have a section listed as a recommendation, label it section and recommendation.
  • To have a section listed as a rule, label it section and rule.


  1. I would like to see a downloadable version of the Java Secure Coding Standard. Maybe a zip with HTML files or a all-in-one HTML file could be provided. PDF would also be nice. I am sure I am not the only one who is interested in this.

    1. PDF versions of The CERT Oracle Secure Coding Standard for Java are available from InformIT at

    2. Seconded. Confluence provides export facilities "out-of-the-box" (Space Tools > Content Tools > Export tab), but the export option has been disabled explicitly here. Kind request to the administrators: can you enable this option?

      1. We appreciate your feedback.  As you imply, we have chosen to explicitly not enable that option at this time, and we currently have no plans to enable the option.

  2. Hi,

    We have tried to setup PMD rules to automatically detect non-conformities to these rules. Do you have a list of rules that can be 100 percent detected automatically? For us, there are many rules which create false positives. Also, do you have any particular advice on implementing automated detection?



    1. Paul,

      We've implemented a few automated checkers for CERT rules. See I'd be happy to learn more about your project? Which rules does your tool support? Are your checkers open source?

    2. Hi Paul,

      No, we do not have any such list. One of the problems is, as you point out, that "detected automatically" is really a relative term, based on tolerance for false positives. However, we are actively investigating this question by attempting to develop (heuristic) checkers for as many rules as possible.

      Regarding particular advice -- some rules have specific textual comments regarding the possibilities for automatic detection which might be useful. If you have questions regarding particular rules, please let us know which ones, and we'd be happy to give you what advice we can regarding automatic detection.

      I should be upfront with one disclaimer: while all rules are rated with remediation levels, and the definition of the remediation levels involves the potential for automatic checking for rule conformance, you should take those interpretations with a grain of salt. That is, while we stand by the remediation difficulty ratings in the abstract, the specific interpretations (in the introduction) in terms of automatic/manual detection/correction are not always applicable.  Rather, it is best to go by what, if anything, about automatic detection is mentioned in the textual discussion of the rule.


  3. Es un excelente libro The.CERT.Oracle.Secure.Coding.Standard.for.Java los felicto , muchas gracias desde Piura-Perú.

  4. How to validate your rules for our java files? Is there any tool like findbugs / PMD?  Is there any wiki to check those things?

    1. Each rule has an "Automated Detection" section. This section lists tools (including PMD and FindBugs!) that can detect violations of the rule.

      1. But, few rules are not yet to implemented in the above mentioned tools ( PMD & FindBugs! ). How to validate whether our source code affects the above listed rules(violations).? Do you have any reference to implement it through commandLine?

        1. The Automated Detection section represents our public knowledge. If a rule has an empty AD section, then we do not have references for checking that rule. They may exist but be new, or not public.