Most developers agree that there is a need to write secure code, but often find that the pressures of getting something shipped can constrain their ability to do so. Others may just not know where to start. In either event having an established guide can be useful in improving their approach.
InfoQ had the opportunity to speak with the authors of Java Coding Guidelines to discuss how their new book helps developers write better code and provides a useful guide on what to look for.
InfoQ: Many developers may want to improve the quality of their code as it relates to security, but may not know where to start. Another developer may think they are great in theory, but they are stuck working on a legacy code base. What would you say to those programmers coming at it from such different situations?
Authors: How you use this book depends greatly on what you are doing. If you are at the beginning of a Java software development process, you might want to read the book through once to get the gist of the guidelines. Then, as you begin developing your system, you can go back and review individual guidelines as questions about their application arise.
On the other hand, if you are maintaining an existing system, you may want to review the guidelines until you find one that is “surprising,” review your code to see if the issue is present, and then refer to the guideline as you consider a remediation strategy.
InfoQ: Looking at the book, the contents are divided into security, defensive programming, reliability, program understandability, and programmer misconceptions. Of those, where do you think is the biggest need for programming focus?
Authors: The primary aim of Java Coding Guidelines is to help programmers make intelligent choices in the face of uncertainties about the proper application of particular programming concepts, constructs, or language features. Programmer Misconceptions addresses the specific issue [of] “What are common misunderstandings?” Program Understandability goes a long way toward ensuring that the code is free from ambiguities and is consequently easier to maintain. The Security, Defensive Programming, and Reliability chapters instill the need for building robust systems that are resilient to attack or failure.
InfoQ: How does your book relate to The CERT Oracle Secure Coding Standard for Java? Should this guide be used after reading that or in conjunction with it?
Authors: The CERT Oracle Secure Coding Standard for Java defines rules for secure coding in Java that, if violated, could result in exploitable vulnerabilities. Java Coding Guidelines contains recommendations that should generally improve the security and reliability of your software, although any particular violation of these recommendations doesn’t suggest a defect exists in the code. The two books are best used in tandem because they provide independent guidance, and you'll find little or no overlap between the two books. Most guidelines offer general coding principles to follow, whereas the coding standard enumerates errors to avoid. Java Coding Guidelines includes references to The CERT Oracle Secure Coding Standard for Java but was written so as to be self-contained.
InfoQ: To what degree do tools exist that automatically scan code for these types of errors? Can an automatic tool replace the need for a programmer to be familiar with these concepts?
Authors: Programmers should be familiar with the concepts in Java Coding Guidelines because it is easier to avoid introducing defects and vulnerabilities in code during development than it is to find and remediate them during test, or worse, after deployment. Most existing analysis is unsound and incomplete, meaning that these analyses may result in false negatives and false positives respectively. Developers therefore must be able to determine whether or not a diagnostic issued by a tool is a rule violation and also to avoid or eliminate other violations that are not diagnosed. CERT has created the Source Code Analysis Laboratory (SCALe), which uses a variety of static analyzers to evaluate code for violations of secure coding rules. Many of these tools have non-overlapping capabilities, so it is necessary to use a number of tools to get broad coverage. The SCALe process is only partially automated; human analysts still need to review the diagnostics to eliminate false positives.
InfoQ: Do you see teams setting aside one person as “the security person”? Should the whole team stay familiar with the security topics?
Authors: It is far better if the entire team understands secure coding. Everyone writing code needs to know how to code securely because the best time to get the code right is while it is being written. If one person on the team has additional security training, this information can be effectively disseminated through the use of code inspections and security audits. Development teams need to make a commitment to developing conforming code, for which the books can serve as a reference. Developers can also participate in and/or follow the evolution of our coding standards at www.securecoding.cert.org, through our newsletter, and through our LinkedIn Secure Coding Forum.
InfoQ: Is there a specific error that you see frequently repeated?
Authors: There are specific errors that occur frequently in Java because the language provides a great deal of latitude in how the programming construct can be applied. For example, the secure coding rule ERR-08-J Do not catch NullPointerException or any of its ancestors is frequently violated in an attempt to bypass the exception handling features provided by Java. An overly broad catch or throw statement in code frequently results in errors being silently ignored. Exception handling remains a challenging area because many Java application and web frameworks place the responsibility of handling exceptions and failure scenarios in the hands of the developer.
CERT analyzes Java software systems for conformance to The CERT Oracle Secure Coding Standard for Java. The leading rule violations we have recorded are:
A. EXP01-J. Never dereference null pointers
B. ERR01-J. Do not allow exceptions to expose sensitive information
C. ERR07-J. Do not throw RuntimeException, Exception, or Throwable
D. ERR08-J. Do not catch NullPointerException or any of its ancestors
E. FIO04-J. Release resources when they are no longer needed
F. ERR00-J. Do not suppress or ignore checked exceptions
About the Authors
 |
Fred Long is Senior Lecturer and Director of Learning and Teaching at Aberystwyth University’s Department of Computer Science, and SEI Visiting Scientist. |
 |
Dhruv Mohindra, is a technical lead in the security practices group that is part of the CTO’s office at Persistent Systems Limited, India, where he provides information security consulting solutions across various technology verticals. |
 |
Robert C. Seacord manages CERT’s Secure Coding Initiative, and is adjunct professor at CMU’s School of Computer Science. |
 |
Dean F. Sutherland , Senior Software Security Researcher at CERT, spent 14 years as a software engineer at Tartan, Inc. |
 |
David Svoboda, CERT Software Security Engineer, has been primary developer on multiple CMU development projects since 1991. |