Secure Coding in Java

Secure Code (Java)
- Correct Modules (CMo)
  - CMo.1 Adhere to API specifications.
    - CMo.1.a Avoid calling Thread.run [26:543].
    - CMo.1.b Ensure a clone method calls super.clone [26:580].
    - CMo.1.c Ensure implementations of readObject and writeObject of Serializable classes are private.
    - CMo.1.d In EJB, avoid using Socket connections [26:577].
    - CMo.1.e In EJB, avoid performing ClassLoader operations [26:578].
    - CMo.1.f In EJB, avoid performing SecurityManager operations [26:578].
    - CMo.1.g In J2EE, use web application container mechanisms to obtain connections to resources [26:245].
    - CMo.1.h In J2EE, avoid using Socket connections [26:246].
    - CMo.1.i In J2EE, ensure classes that extend validation forms override the inherited validate method and call super.validate [26:103].
    - CMo.1.j In J2EE, ensure form beans extend an ActionForm subclass of the validator framework [26:104].
    - CMo.1.k Ensure a finalize method calls super.finalize.
    - CMo.1.l Ensure the serialPersistentFields member of Serializable classes is private, static, and final.
  - CMo.2 Follow safe programming practices.
    - CMo.2.a Avoid using deprecated APIs.
    - CMo.2.b Avoid omitting break statements in switch statements [26:484].
    - CMo.2.c Always account for the default case in switch statements [26:478].
    - CMo.2.d Avoid comparing classes by name.
    - CMo.2.e Check preconditions of public methods and throw exceptions when not true.
- Understandability (U)
  - U.1 Remove unused or obsolete functionality from modules.
    - U.1.a Remove unused classes, imports, interfaces, methods, parameters, and fields.
    - U.1.b In J2EE, remove fields from validation forms that do not map to fields in action forms [26:110].
    - U.1.c In J2EE, remove unused validation forms [26:107].
  - U.2 Avoid using confusing language constructs when more understandable alternatives exist.
    - U.2.a Avoid using static initializer blocks to initialize class variables - consider using private final static methods instead.
    - U.2.b Avoid using instance initializer blocks to initialize instance variables - consider using private or protected final methods instead.
  - U.3 Avoid giving confusing, inconsistent, or duplicate names to entities.
    - U.3.a Class names should not include the names of other classes -- unless it is a subclass of them.
    - U.3.b In J2EE, ensure validation forms have unique names [26:102].
- Reduced Complexity (RC)
  - Economy of Mechanism (EoM)
    - Minimized Security Elements (MSE)
      - MSE.1 Employ as few security-critical modules as possible.
        
        MSE.1.a Invoke AccessController.doPrivileged minimally.
        
        MSE.1.b Minimize the number of distinct classes with privileged code.
    - Isolated Security Elements (ISE)
      - ISE.1 Separate security-critical modules from other modules.
        
        ISE.1.a Consider making all Permission classes belong to the same package.
        
        ISE.1.b Consider making all PrivilegedAction and PrivilegedActionException classes belong to the same package.
        
        ISE.1.c Consider making all privileged code belong to the same package.
        
        ISE.1.d Avoid utilizing anonymous PrivilegedAction classes when invoking AccessController.doPrivileged - create classes for distinct PrivilegedActions instead.
    - Small Modules (SM)
      - SM.1 Keep all modules, especially security-critical modules, small.
        
        SM.1.a Limit the number of lines of code within privileged code blocks to 10 lines.
        
        SM.1.b Limit the number of lines of code within all methods to 60 lines.
  - Information Hiding (IH)
    - IH.1 Limit entity accessibility.
      - IH.1.a Declare class entities (fields, methods, nested classes, nested interfaces) private.
        
        IH.1.a.a Declare mutable static fields private.
        
        IH.1.a.b Declare lock variables private.
        
        IH.1.a.c Wrap privileged code blocks in private methods.
        
        IH.1.a.d Avoid native methods; if they are required, declare them private.
        
        IH.1.a.e Declare class initialization fields private and transient (for Serializable classes).
        
        IH.1.a.f Declare the serialVersionUID field of Serializable classes private.
        
        IH.1.a.g Declare transient fields private.
      - IH.1.b Declare classes and interfaces package - unless they are documented in a public API.
      - IH.1.c Avoid making subclass constructors more accessible than superclass constructors.
      - IH.1.d Avoid increasing the accessibility of inherited methods.
      - IH.1.e Avoid inner classes; when used, ensure an inner class is no more accessible than its enclosing class.
    - IH.2 Limit entity extensibility.
      - IH.2.a Declare classes final.
        
        IH.2.a.a Declare Permission and BasicPermission subclasses final.
        
        IH.2.a.b Declare PrivilegedAction and PrivilegedActionException subclasses final.
      - IH.2.b Declare methods final.
        
        IH.2.b.a Declare methods that contain privileged code final -- especially in non-final classes.
        
        IH.2.b.b Declare methods that enforce SecurityManager checks final -- especially in non-final classes.
    - IH.3 Limit internal object state exposure.
      - IH.3.1 Limit exposure when accessing object entities.
        
        IH.3.1.a Avoid providing multiple accessor methods for the same field.
      - IH.3.2 Limit exposure making objects persistent.
        
        IH.3.2.a If default serialization is used, declare sensitive fields transient.
        
        IH.3.2.b Ensure sensitive fields, including transient fields, are not written to writeObject, writeReplace, or writeExternal streams.
        
        IH.3.2.c Ensure sensitive fields, including transient fields, are not stored in the serialPersistentFields array.
        
        IH.3.2.d Make sensitive classes prevent deserialization by providing a final readObject method and throwing exceptions.
        
        IH.3.2.e Make sensitive classes prevent serialization by providing a final writeObject method and throwing exceptions.
      - IH.3.3 Limit exposure when copying objects.
        
        IH.3.3.a Consider providing clone functionality for public mutable classes only.
        
        IH.3.3.b Make sensitive classes prevent cloning by providing a final clone method and throwing exceptions.
  - Low Coupling (LC)
    - LC.1 Minimize module dependencies.
      - LC.1.a Minimize references to global entities (e.g., public class fields, external files, etc.).
      - LC.1.b Minimize calling methods on other class instances.
      - LC.1.c Require as few class method parameters as possible.
      - LC.1.d Consider making class method parameters have interface types.
  - High Cohesion (HC)
    - HC.1 Keep related data and behavior in the same module.
      - HC.1.a Maximize references to private or protected entities (e.g., fields and methods) from private or protected methods within the same module.
- Continuous Protection of Information (CPoI)
  - Secure Defaults (SDe)
    - SDe.1 Ensure the default configurations of modules are secure.
      - SDe.1.a In J2EE, ensure session identifiers are configured to be at least 128 bits in length [26:6].
  - Strong Protection Mechanisms (SPM)
    - SPM.1 Utilize secrets securely.
      - SPM.1.1 Avoid hard-coding passwords in source code -- consider storing encrypted passwords in external configuration files instead [43].
        
        SPM.1.1.a Avoid using hard-coded passwords in the getConnection method of the DriverManager class.
    - SPM.2 Use cryptographically strong algorithms.
      - SPM.2.a Use an AES Cipher when using SealedObject.
      - SPM.2.b Use a SHA-256, SHA-384, or SHA-512 algorithm when using MessageDigest.getInstance to perform cryptographic hashing [43].
      - SPM.2.c Use the RSA algorithm when using KeyPairGenerator.getInstance and specify (i.e., calling KeyPairGenerator.initialize) a key size of at least 1024 bits [43].
    - SPM.3 Generate truly random numbers.
      - SPM.3.a Use the SecureRandom class to generate random numbers.
  - Secure Initialization (SI)
    - SI.1 Ensure modules are securely initialized.
      - SI.1.a All default class initialization that occurs in constructors for Serializable classes should also occur within readObject and readObjectNoData.
      - SI.1.b Avoid throwing exceptions in constructors, especially in public, non-final classes.
  - Defense in Depth (DiD)
    - Fail-safe Defaults (FsD)
      - FsD.1 Deny access to objects unless entities have explicit access permission.
        
        FsD.1.a Install a SecurityManager by invoking System.setSecurityManager - do not rely on the -Djava.security.manager command line execution argument.
        
        FsD.1.b Enforce a default-deny security policy when granting permissions (i.e., Permission subclasses) to external code bases.
    - Self Analysis (SA)
      - SA.1 Ensure objects are used only when operating in valid, secure states.
        
        SA.1.a Consider enforcing class initialization checks (e.g., using an initialized flag) in public and protected methods -- especially in sensitive non-final classes and Serializable classes.
        
        SA.1.b Ensure the readExternal method of Externalizable classes is invoked once during deserialization (e.g., using an initialized flag).
        
        SA.1.c Check all method return values.
    - Least Privilege (LP)
      - LP.1 Ensure external code bases have minimal privileges.
        
        LP.1.a Grant explict permissions (i.e., Permission subclasses) to external code bases only as needed and enforce them using SecurityManager checks.
        
        LP.1.b Never grant java.security.AllPermission to external code bases.
      - LP.2 Ensure module entities have minimal privileges.
        
        LP.2.a Remove unnecessary classes, imports, interfaces, methods, parameters, and fields.
        
        LP.2.b Ensure privileged code blocks only have access to code that is necessary to perform sensitive operations.
        
        LP.2.c Consider making parameters of public constructors and methods final - especially when handling critical data values.
        
        LP.2.d Consider making class fields final - especially when handling critical data values.
    - Complete Mediation (CMe)
      - CMe.1 Authorize all instantiations of sensitive objects.
        
        CMe.1.a Consider enforcing SecurityManager checks within public and protected constructors (or public factory methods) of sensitive classes -- especially when SecurityManager checks are present within clone, readObject, or readObjectNoData.
        
        CMe.1.b Ensure all SecurityManager checks that occur in constructors of Cloneable classes also occur within clone (or methods that provide clone-like functionality).
        
        CMe.1.c Ensure all SecurityManager checks that occur in constructors of Serializable classes also occur within readObject and readObjectNoData.
      - CMe.2 Authorize all accesses to the internal state of sensitive objects.
        
        CMe.2.a Consider enforcing SecurityManager checks before setting internal state in all public and protected mutator methods of sensitive classes.
        
        CMe.2.b If a Serializable class invokes a SecurityManager check before internal state can be modified (e.g., in public mutator methods), enforce the same check within readObject.
        
        CMe.2.c Consider enforcing SecurityManager checks before retrieving internal state in all public and protected accessor methods of sensitive classes.
        
        CMe.2.d If a Serializable class invokes a SecurityManager check before internal state can be retrieved (e.g., in public accessor methods), enforce the same check within writeObject.
        
        CMe.2.e Consider enforcing SecurityManager checks during the retrieval of sensitive objects using GuardedObjects.
      - CMe.3 Authorize all accesses to sensitive communication channels.
        
        CMe.3.a Consider enforcing SecurityManager checks prior to transferring or retrieving sensitive information over Sockets
    - Separation of Privilege (SoP)
      - SoP.1 Require multiple permissions before granting access to modules.
        
        SoP.1.a Consider requiring permission for untrusted code to access sensitive packages using the package.access security property.
        
        SoP.1.b Consider requiring permission for untrusted code to join sensitive packages using the package.definition security property.
        
        SoP.1.c Consider requiring permission for untrusted code to subclass sensitive public, non-final classes by enforcing SecurityManager checks in constructors.
    - Trust Boundaries (TB)
      - Reluctance to Trust (RtT)
        
        RtT.1 Assume input data is maliciously crafted.
        
        RtT.1.1 Validate all input data (i.e., parameters).
        
        RtT.1.1.a Validate untrusted input before passing it to privileged code blocks.
        
        RtT.1.1.b Perform validation checks on defensive copies rather than on original mutable objects.
        
        RtT.1.1.c Ensure all input validation checks that occur in constructors of Serializable classes also occur within readObject and readObjectNoData.
        
        RtT.1.1.d In J2EE, ensure action forms have associated validation forms [26:108].
        
        RtT.1.1.e In J2EE, ensure all form fields, whether populated with data or not, are validated [26:105].
        
        RtT.1.2 Securely interact with external modules using input data.
        
        RtT.1.2.a Validate and encode untrusted input before using it as command parameters when invoking Runtime.exec and ProcessBuilder.start.
        
        RtT.1.2.b Use absolute file paths when opening files with untrusted input.
        
        RtT.1.2.c Validate and encode untrusted input before saving it to log files.
        
        RtT.1.3 Keep input data and control information separate.
        
        RtT.1.3.a Make use of data value placeholders in parameterized statements when executing database queries using java.sql.PreparedStatement.
        
        RtT.1.3.b Use XPath variables when evaluating XML queries using javax.xml.xpath.XPathVariableResolver [43].
        
        RtT.2 Assume interactions with fragile module entities are malicious.
        
        RtT.2.a Only call final methods within privileged code blocks of non-final classes.
        
        RtT.2.b Only call final methods within synchronized blocks of non-final classes.
        
        RtT.2.c Only call final methods within readObject and readObjectNoData of non-final Serializable classes.
        
        RtT.2.d Only call final methods within constructors of non-final classes.
        
        RtT.2.e Only call final methods within clone of non-final classes.
        
        RtT.2.f Only invoke clone on instances of final classes.
        
        RtT.3 Assume requests from external sources are malicious.
        
        RtT.3.a Avoid invoking methods that bypass SecurityManager checks depending on the immediate caller's ClassLoader on behalf of untrusted code -- especially with untrusted input [2].
        
        RtT.3.a.a Avoid invoking Class.newInstance with untrusted input.
        
        RtT.3.a.b Avoid invoking Class.getClassLoader with untrusted input.
        
        RtT.3.a.c Avoid invoking Class.getClasses with untrusted input.
        
        RtT.3.a.d Avoid invoking Class.getField(s) with untrusted input.
        
        RtT.3.a.e Avoid invoking Class.getMethod(s) with untrusted input.
        
        RtT.3.a.f Avoid invoking Class.getConstructor(s) with untrusted input.
        
        RtT.3.a.g Avoid invoking Class.getDeclaredClasses with untrusted input.
        
        RtT.3.a.h Avoid invoking Class.getDeclaredField(s) with untrusted input.
        
        RtT.3.a.i Avoid invoking Class.getDeclaredMethod(s) with untrusted input.
        
        RtT.3.a.j Avoid invoking Class.getDeclaredConstructor(s) with untrusted input.
        
        RtT.3.a.k Avoid invoking ClassLoader.getParent with untrusted input.
        
        RtT.3.a.l Avoid invoking ClassLoader.getSystemClassLoader with untrusted input.
        
        RtT.3.a.m Avoid invoking Thread.getContextClassLoader with untrusted input.
        
        RtT.3.b Avoid invoking methods that use the immediate caller's ClassLoader to perform operations on behalf of untrusted code -- especially with untrusted input [2].
        
        RtT.3.b.a Avoid invoking Class.forName with untrusted input.
        
        RtT.3.b.b Avoid invoking Package.getPackage(s) with untrusted input.
        
        RtT.3.b.c Avoid invoking Runtime.load with untrusted input.
        
        RtT.3.b.d Avoid invoking Runtime.loadLibrary with untrusted input.
        
        RtT.3.b.e Avoid invoking System.load with untrusted input.
        
        RtT.3.b.f Avoid invoking System.loadLibrary with untrusted input.
        
        RtT.3.b.g Avoid invoking DriverManager.getConnection with untrusted input.
        
        RtT.3.b.h Avoid invoking DriverManager.getDriver(s) with untrusted input.
        
        RtT.3.b.i Avoid invoking DriverManager.deregisterDriver with untrusted input.
        
        RtT.3.b.j Avoid invoking ResourceBundle.getBundle with untrusted input.
        
        RtT.3.c Avoid invoking methods that perform accessibility checks using the immediate caller's ClassLoader on behalf of untrusted code -- especially with untrusted input [2].
        
        RtT.3.c.a Avoid invoking Constructor.newInstance with untrusted input.
        
        RtT.3.c.b Avoid invoking Field.set* with untrusted input.
        
        RtT.3.c.c Avoid invoking Field.get* with untrusted input.
        
        RtT.3.c.d Avoid invoking Method.invoke with untrusted input.
        
        RtT.3.c.e Avoid invoking AtomicIntegerFieldUpdater.newUpdater with untrusted input.
        
        RtT.3.c.f Avoid invoking AtomicLongFieldUpdater.newUpdater with untrusted input.
        
        RtT.3.c.g Avoid invoking AtomicReferenceFieldUpdater.newUpdater with untrusted input.
        
        RtT.4 Avoid invoking less trusted modules from within more trusted modules.
        
        RtT.4.a Avoid invoking methods on dynamically loaded code within the scope of privileged code blocks.
        
        RtT.4.b Avoid invoking native methods -- especially with untrusted input.
      - Controlled Sharing (CS)
        
        CS.1 Perform atomic operations on shared data.
        
        CS.1.a Use the synchronized keyword on private lock variables to provide mutual exclusion in multithreaded modules.
        
        CS.1.b Open file streams using file handles (e.g., File objects) instead of file names, especially within the same module.
      - Least Common Mechanism (LCM)
        
        LCM.1 Define separate namespaces for dynamically loaded code.
        
        LCM.1.a Ensure code from different code bases is dynamically loaded using separate ClassLoader instances.
        
        LCM.2 Minimize information sharing through module interfaces.
        
        LCM.2.a Pass defensive copies of private mutable objects as parameters.
        
        LCM.2.b Return defensive copies of private mutable objects from methods.
        
        LCM.2.b.a Ensure implementations of clone (i.e., Cloneable) return defensive copies.
        
        LCM.2.b.b Ensure public factory methods that implement clone-like functionality return defensive copies.
        
        LCM.2.c Defensively copy public mutable input parameters -- especially when assigning to private fields.
        
        LCM.2.d Avoid referencing public mutable fields, even those final and static -- if required, make defensive copies.
        
        LCM.2.e Declare public static fields that are objects final and make them immutable.
        
        LCM.2.f Declare public static fields that contain primitive values final.
        
        LCM.2.g Create defensive copies of mutable fields in readObject of Serializable classes during deserialization.
  - Secure Transfer (ST)
    - ST.1 Protect objects that are transferred over communication channels or to persistent storage.
      - ST.1.a Consider sealing sensitive objects that require mobility or persistence using SealedObject.
      - ST.1.b Consider signing sensitive objects that require mobility or persistence using SignedObject.
      - ST.1.c Consider using SSLSockets instead of normal Sockets.
      - ST.1.d Consider using CipherInputStream and CipherOutputStream when persisting objects.
  - Secure Failure (SF)
    - SF.1 Handle all errors securely.
      - SF.1.a Avoid catching overly-broad exceptions, such as java.lang.Exception [26:396].
      - SF.1.b Avoid throwing overly-broad exceptions, such as java.lang.Exception [26:397].
      - SF.1.c Avoid catching unchecked exceptions, such as java.lang.NullPointerException -- unless they are caught at the top-most level [43].
      - SF.1.d Avoid returning (i.e., using the return keyword) inside finally blocks.
      - SF.1.e In J2EE, catch java.lang.Throwable at the top-most level [43].
      - SF.1.f In J2EE, ensure default error pages are enabled [26:7].
    - SF.2 Always release allocated resources.
      - SF.2.a Always invoke close on objects that open resource streams (e.g., FileReader, FileInputStream, PreparedStatement, Statement, etc.) in finally blocks.
    - SF.3 Prevent leaking sensitive information during failures.
      - SF.3.a Consider throwing new exceptions of the same type but with a sanitized message.
      - SF.3.b Consider throwing different types of exceptions (i.e., user-defined exceptions) entirely.
  - Secure Disposal (SDi)
    - SDi.1 Minimize the lifetime of secrets that are stored in memory.
      - SDi.1.a Store sensitive data in mutable objects, such as character arrays rather than immutable objects, such as Strings, so that they can be explicitly cleared (e.g., using Arrays.fill) when no longer needed.
        
        SDi.1.a.a Use JTextField.getPassword when processing passwords in Swing code.
        
        SDi.1.a.b Use Console.readPassword when requesting passwords from console input streams.
    - SDi.2 Employ secure object disposal mechanisms.
      - SDi.2.a Avoid explicitly calling finalize [26:486].
      - SDi.2.b Consider making sensitive non-final classes prevent finalizer attacks by providing an empty finalizer method and declaring it final.
      - SDi.2.c Avoid using finalizers to perform time or security-critical operations -- if required for classes that are public and non-final, utilize the finalizer idiom.
  - Secure Shutdown (SS)
    - SS.1 Employ secure application shutdown mechanisms.
      - SS.1.a Invoke System.exit( ) minimally.
      - SS.1.b In J2EE, avoid calling System.exit( ) [26:382].
- Accountability (Ac)
  - Ac.1 Employ a logging scheme.
    - Ac.1.a Consider logging every caught exception -- especially security-relevant exceptions, such as SecurityException, AccessControlException, and SSLException.
    - Ac.1.b Avoid utilizing output streams for logging purposes -- use a well-known logging API instead, such as java.util.logging or Apache log4j [55].
      - Ac.1.b.a Avoid writing log events using System.out.
      - Ac.1.b.b Avoid writing log events using Console.printf.
      - Ac.1.b.c Avoid writing log events using System.err.

Correct Modules
The principle of correct modules states that designs with modules that meet specifications and that are made by following safe programming practices are better.

Understandability
The principle of understandability states that designs with modules that are easier to understand are better.

Reduced Complexity
The principle of reduced complexity [8] states that designs with modules that are less complex are better.

Economy of Mechanism
The principle of economy of mechanism [1] states that designs with modules that are simple and small are better.

Minimized Security Elements
The principle of minimized security elements [8] states that designs that have a minimal number of security-critical modules are better.

Isolated Security Elements
The principle of isolated security elements states that designs that isolate modules that provide security-critical functionality are better.

Small Modules
The principle of small modules [10] states that designs with small modules are better.

Information Hiding
The principle of information hiding [10, 12] states that designs with modules that shield the details of their internal structure and processing from other modules are better.

Low Coupling
The principle of low coupling [10] states that designs that minimize the degree of connection between pairs of modules are better.

High Cohesion
The principle of high cohesion [10] states that designs that maximize the degree to which a module�s parts are related to one another are better.

Continuous Protection of Information
The principle of continuous protection of information [8] states that designs that perform operations that continuously protect sensitive information in every system state are better.

Secure Defaults
The principle of secure defaults [8] states that designs with modules that have secure initial configurations are better.

Secure Initialization
The principle of secure initialization states that designs with modules that perform initialization functionality in a secure manner are better.

Strong Protection Mechanisms
The principle of strong protection mechanisms states that designs with modules that provide protection in the most secure manner possible are better.

Defense in Depth
The principle of defense in depth [3] states that designs that establish protective barriers across multiple dimensions of a module are better.

Fail-safe Defaults
The principle of fail-safe defaults [1] states that designs with modules that deny access to objects unless entities have been granted explicit access permissions are better [4].

Self Analysis
The principle of self analysis [8] states that designs with modules that assess their own internal state are better.

Least Privilege
The principle of least privilege [1] states that designs with modules that do not have access to unneeded resources are better [10].

Complete Mediation
The principle of complete mediation [1] states that designs with modules that check every access to sensitive objects for authorization are better.

Separation of Privilege
The principle of separation of privilege [1] states that designs with modules that require two or more conditions to be met before an action is permitted are better.

Trust Boundaries
The principle of trust boundaries [5] states that designs that clearly establish domains of trust between interacting modules that exchange or manipulate data are better.

Reluctance to Trust
The principle of reluctance to trust [9, 50] states that it is better to have designs with modules that assume all interactions with external entities are malicious.

Least Common Mechanism
The principle of least common mechanism [1] states that designs with modules that minimize the number of shared access paths to information are better.

Controlled Sharing
The principle of controlled sharing states that designs whose modules share information in a controlled manner are better.

Secure Transfer
The principle of secure transfer states that designs with modules that protect information that is transferred outside complete control of a software system are better.

Secure Failure
The principle of secure failure [8] states that designs with modules that do not jeopardize security when failures occur are better.

Secure Disposal
The principle of secure disposal [45] states that designs with modules that dispose of sensitive information when it is no longer needed are better.

Secure Shutdown
The principle of secure shutdown [45] states that designs with modules that do not jeopardize security when performing shutdown or termination functionality are better.

Accountability
The principle of accountability [8] states that designs that record security-relevant sequences of actions and trace them to the entity (e.g., module or user) that caused the actions to occur are better.

Bibliography

[1] M. D. Schroeder, and J. H. Saltzer, �The Protection of Information in Computer Systems,� in Proceedings of the IEEE, vol. 63, no. 9, 1975, pp. 1278-1308. Available: http://web.mit.edu/Saltzer/www/publications/protection.

[2] Sun Microsystems, Inc., "Secure Coding Guidelines for the Java Programming Language, version 2.0," Sun Microsystems, Inc. [Online]. Available: http://java.sun.com/security/seccodeguide.html. [Accessed: Aug. 30, 2007].

[3] S. Redwine, Jr., Ed., Software Assurance: A Guide to the Common Body of Knowledge to Produce, Acquire, and Sustain Secure Software, Workforce Education and Training Working Group, U.S. Department of Homeland Security, Draft Version 1.1, September 2006.

[4] M. Bishop, Introduction to Computer Security. Boston, MA: Addison-Wesley, 2005.

[5] M. Howard and D. Lipner, Writing Secure Code, 2nd ed. Redmond, Washington: Microsoft Press, 2003.

[6] G. McGraw, "Software Security," IEEE Software and Privacy, vol. 2, no. 2, pp. 80-83, March/April 2004.

[7] S. Redwine, Jr. and N. Davis, Eds., Processes to Produce Secure Software: Towards more Secure Software, National Cyber Security Summit, Software Process Subgroup of the Task Force on Security across the Software Development Lifecycle, vol. 1, March 2004.

[8] T. V. Benzel, C. E. Irvine, T. E. Levin, G. Bhaskara, and P. C. Nguyen, �Design Principles for Security,� Naval Postgraduate School : Monterey, California, Tech Rep. NPS-CS-05-010, September 2005. Available: http://handle.dtic.mil/100.2/ADA437854. [Accessed: Sept. 5, 2007].

[9] J. Viega and G. McGraw, Building Secure Software: How to Avoid Security Problems the Right Way. Indianapolis, IN: Addison-Wesley, 2002.

[10] C. Fox, Introduction to Software Engineering Design: Processes, Principles, and Patterns with UML2. Boston, MA: Addison-Wesley, 2006.

[11] J. Bloch, Effective Java Programming Language Guide. Prentice Hall, 2001.

[12] D. L. Parnas, �On the Criteria To Be Used in Decomposing Systems into Modules,� in Communications of the ACM, vol. 15, no. 12, 1972, pp. 1053-1058.

[13] M. Graff and K. van Wyk, Secure Coding: Principles and Practices. Sebastopol, CA: O'Reilly, 2003.

[14] Sun Microsystems, Inc., �White Paper: The Java Language Environment,� Sun Microsystems, Inc., 1997. [Online]. Available: http://java.sun.com/docs/white/langenv/Security.doc5.html. [Accessed: October 1, 2006].

[15] G. McGraw and E. Felton, Java Security: Hostile Applets, Holes, and Antidotes. Canada: Wiley Computer Publishing, 1997.

[16] Sun Microsystems, Inc. �News and Updates: Chronology of security-related bugs and issues,� Sun Microsystems, Inc., 2002. [Online]. Available: http://java.sun.com/sfaq/chronology.html. [Accessed: October 4, 2006].

[17] L. Gong, G. Ellison, and M. Dageforde, Inside Java 2 Platform Security: Architecture, API Design, and Implementation, 2nd ed. Boston, MA: Addison-Wesley, 2003.

[18] J. Gosling, B. Joy, G. Steele, and G. Bracha, �The Java Language Specification,� 3rd ed. Sun Microsystems, Inc. [Online]. Available: http://java.sun.com/docs/books/jls. [Accessed: December 11, 2007].

[19] Sun Microsystems, Inc. �Security Managers and the Java SE SDK,� Rev. 1.7, Sun Microsystems, Inc.. [Online]. Available: http://java.sun.com/javase/6/docs/technotes/guides/security/smPortGuide.html. [Accessed: March 13, 2008].

[20] L. Gong, �Java 2 Platform Security Architecture,� Ver. 1.2, Sun Microsystems, Inc. 1997-2002. [Online]. Available: http://java.sun.com/javase/6/docs/technotes/guides/security/spec/security-spec.doc.html. [Accessed: March 13, 2008].

[21] Sun Microsystems, Inc. �Default Policy Implementation and Policy File Syntax,� Rev. 1.6, Sun Microsystems, Inc. [Online]. Available: http://java.sun.com/javase/6/docs/technotes/guides/security/PolicyFiles.html. [Accessed: March 11, 2008].

[22] D. Dean, E. Felton, D. Wallach, �Java Security: Web Browsers and Beyond,� in Proceedings of the 1996 IEEE Symposium on Security and Privacy (SP '96), 1996.

[23] G. McGraw and E. Felton, Securing Java: Getting Down to Business with Mobile Code. John Wiley & Sons, Inc., 1998. [Online]. Available: http://www.securingjava.com. [Accessed: March 13, 2008].

[24] R. Alexander, J. Bieman, and J. Viega, �Coping with Java Programming Stress,� IEEE Computer, vol. 33, no. 4, pp. 30-38, April 2000.

[25] G. McGraw, Software Security: Building Security In. Boston, MA; Addison-Wesley, 2006.

[26] The MITRE Corporation, �Common Weaknesses Enumeration: A Community-Developed Dictionary of Software Weakness Types,� Draft 7, The MITRE Corporation, 2007. [Online]. Available: http://cwe.mitre.org. [Accessed: October 28, 2007].

[27] Sun Microsystems, Inc. �API for Privileged Blocks,� Rev. 1.6, Sun Microsystems, Inc. [Online]. Available: http://java.sun.com/javase/6/docs/technotes/guides/security/doprivileged.html. [Accessed: October 5, 2007].

[28] Fortify Software Inc., �Fortify Taxonomy: Software Security Errors,� Fortify Software Inc., 2006. [Online]. Available: http://www.fortifysoftware.com/vulncat. [Accessed October 4, 2006].

[29] M. Howard, D. LeBlanc, and J. Viega, 19 Deadly Sins of Software Security: Programming Flaws and How to Fix Them. Emeryville, CA: McGraw-Hill/Osborne, 2005.

[30] R. P. Abbott, J. S. Chin, J. E. Donnelley, W. L. Konigsford, S. Tokubo, and D. A. Webb, D. �Security Analysis and Enhancements of Computer Operating Systems,� Institute for Computer Sciences and Technology, National Bureau of Standards, Tech. Rep. NBSIR 76-1041, April 1976. Available: http://cwe.mitre.org/about/sources.html.

[31] R. Bisbey II and D. Hollingsworth, �Protection Analysis: Final Report,� CA: University of Southern California Information Sciences Institute, Tech. Rep. ISI/RR-78-13, 1978.

[32] C. Landwehr, A. Bull, J. McDermott, and W. Choi, �A Taxonomy of Computer Program Security Flaws, with Examples,� in ACM Computing Surveys (CSUR), vol. 26, no. 3, September 1994, pp. 211-254.

[33] M. Bishop and D. Bailey, �A Critical Analysis of Vulnerability Taxonomies,� University of California at Davis, Tech. Rep. CSE-96-11, September 1996.

[34] S. Weber, P. Karger, and A. Paradkar, �A Software Flaw Taxonomy: Aiming Tools At Security,� in ACM SIGSOFT Software Engineering Notes, vol. 30, no. 4, July 2005.

[35] Open Web Application Security Project, �The free and open application security community,� [Online]. Available: http://www.owasp.org. [Accessed: March 1, 2008].

[36] CERT, �CERT Statistics,� Software Engineering Institute: Carnegie Mellon. [Online]. Available: http://www.cert.org/stats. [Accessed: October 3, 2007].

[37] CERT, �Secure Coding,� Software Engineering Institute: Carnegie Mellon. [Online]. Available: http://www.cert.org/secure-coding. [Accessed: December 12, 2006].

[38] ISO/IEC JTC 1/SC 22/OWG: Vulnerabilities, �Guidance for Avoiding Vulnerabilities through Language Selection and Use,� [Online]. Available: http://www.aitcnet.org/isai. [Accessed: October 24, 2007].

[39] K. Arnold, J. Gosling, D. Holmes, The Java Programming Language, 4th ed., Upper Saddle River, NJ: Addison-Wesley, 2005. [Online]. Available: http://proquest.safaribooksonline.com/0321349806. [Accessed: September 25, 2007].

[40] D. Piliptchouk, �Java vs. .NET Security � Part 3,� O�Reilly ONJava.com, [Online]. Available: http://www.onjava.com/pub/a/onjava/2004/01/28/javavsdotnet.html?page=2. [Accessed: October 15, 2007].

[41] R. Seacord, �Secure Coding Standards,� in Proceedings of the Static Analysis Summit, NIST Special Publication 500-262, July 2006. Available: http://samate.nist.gov/docs/NIST_Special_Publication_500-262.pdf.

[42] S. McConnell, Code Complete, 2nd ed. Redmond, Washington: Microsoft Press, 2004.

[43] B. Chess and J. West, Secure Programming with Static Analysis. Boston, MA: Addison-Wesley, 2007.

[44] K. Goertzel Ed., T. Winograd, H. McKinley, P. Holley, Security in the Software Lifecycle: Making Software Development Processes � and Software Produced by Them � More Secure, US Department of Homeland Security, Draft Version 1.2, August 2006.

[45] S. Redwine Jr., �Towards an Organization for Software System Security Principles and Guidelines,� Institute for Infrastructure and Information Assurance, James Madison University: Harrisonburg, VA, Tech. Rep. 08-01, Version 1.0, February 2008.

[46] K. Tsipenyuk, B. Chess, G. McGraw, �Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors,� in NIST Workshop on Software Security Assurance Tools, Techniques, and Metrics, Long Beach, CA, November 2005.

[47] A. Carzaniga, G. Picco, G. Vigna, �Is Code Still Moving Around? Looking Back at a Decade of Code Mobility,� in Companion to the proceedings of the 29th International Conference on Software Engineering, 2007, pp. 9-20.

[48] CLASP, �Comprehensive Lightweight Application Security Process,� Secure Software, Inc., Version 2.0, 2006. [Online]. Available: http://searchsoftwarequality.techtarget.com/searchAppSecurity/downloads/clasp_v20.pdf. [Accessed December 5, 2007].

[49] A. J. Riel, Object-Oriented Design Heuristics. Addison-Wesley, 1996.

[50] S. Barnum and M Gegick, �Reluctance to Trust,� Build Security In: Setting a Higher Standard for Software Assurance, Cigital Inc., 2005. [Online]. Available: https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/355.html. [Accessed: January 17, 2008].

[51] C. Lai, �Java Insecurity: Accounting for Subtleties That Can Compromise Code,� IEEE Software, vol. 25, no. 1, pp. 13-19, January/February 2008.

[52] S. Liang, The Java Native Interface: Programmer�s Guide and Specification, Palo Alto, CA: Sun Microsystems Inc., 2002. [Online]. Available: http://java.sun.com/docs/books/jni/html/titlepage.html.

[53] S. Barnum and M Gegick, �Design Principles,� Build Security In: Setting a Higher Standard for Software Assurance, Cigital Inc., 2005. [Online]. Available: https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/358.html?branch=1&language=1. [Accessed: January 17, 2008].

[54] CERT, �Top 10 Secure Coding Practices,� Software Engineering Institute: Carnegie Mellon. [Online]. Available: https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices. [Accessed: February, 16, 2008].

[55] Apache Software Foundation, �Logging Services: log4j,� Apache Software Foundation, [Online]. Available: http://logging.apache.org/log4j/1.2/index.html. [Accessed: February 18, 2008].

[56] Sun Microsystems, Inc. �Java SE 6,� Sun Microsystems, Inc. [Online]. Available: http://java.sun.com/javase/6.

[57] Sun Microsystems, Inc. �Java EE at a Glance,� Sun Microsystems, Inc. [Online]. Available: http://java.sun.com/javaee.

[58] Howard and Lipner, The Security Development Lifecycle: SDL: A Process for Developing Demonstrably More Secure Software, Microsoft Press, June 2006.[Online]. Available: http://proquest.safaribooksonline.com/0735622140. [Accessed: January 28, 2008].

[59] B. Chess and G. McGraw, �Static Analysis for Security,� IEEE Security and Privacy, pp. 32-35, vol. 2, no. 6, pp. 76-79, November/December 2004.

[60] O. Burn, �Checkstyle 4.4,� [Online]. Available: http://checkstyle.sourceforge.net. [Accessed: March 1, 2008].

[61] S. Gutz and O. Marquez, �TPTP Static Analysis Tutorial Part 1: A Consistent Analysis Interface,� [Online]. Available: http://www.eclipse.org/tptp/home/documents/process/development/static_analysis/TPTP_static_analysis_tutorial_part1.html. [Accessed: February 10, 2008].

[62] D. Hovemeyer and W. Pugh, �Finding Bugs is Easy,� in SIGPLAN Notices, vol. 39, no. 12, December 2004, pp. 92-206.

[63] Fortify Software Inc., �Fortify Source Code Analysis (SCA),� Fortify Software Inc. [Online]. Available: http://www.fortify.com/products/sca.

[64] utils.com, �Lint4j,� [Online]. Available: http://www.jutils.com.

[65] InfoEther, �PMD,� [Online]. Available: http://pmd.sourceforge.net.

[66] QJ-Pro, �Code Analyzer for Java,� [Online]. Available: http://qjpro.sourceforge.net.

[67] R. Martin, S. Barnum, S. Christey, �Being Explicit about Security Weaknesses,� presented at Black Hat DC 2007, 2007. Available: http://cwe.mitre.org/about/documents.html.

[68] The SANS Institute, �SANS Software Security Institute,� The SANS Institute. [Online]. Available: http://www.sans-ssi.org. [Accessed: March 7, 2008].

[69] National Institute of Standards and Technology, �SAMATE: Software Assurance Metrics and Tool Evaluation,� National Institute of Standards and Technology. [Online]. Available: http://samate.nist.gov. [Accessed: February 5, 2008].

[70] Jlint, �About Jlint,� [Online]. Available: http://jlint.sourceforge.net.

[71] N. Rutar, C. Almazan, and J. Foster, �A Comparison of Bug Finding Tools for Java,� in Proceedings of the 15th IEEE International Symposium on Software Reliability Engineering, France, November 2004.

[72] S. Wagner, J. Jurjens, C. Koller, P. Trischberger, �Comparing Bug Finding Tools with Reviews and Tests,� in Proceedings of the 17th International Conference on Testing of Communication Systems, 2005, pp. 40-55.

[73] S. Wagner, F. Deissenboeck, J. Wimmer, M. Aichner, M. Schwab, �An Evaluation of Two Bug Pattern Tools for Java,� to appear in Proceedings of the 1st IEEE International Conference on Software Testing, Verification and Validation, 2008.

[74] N. Ayewah, W. Pugh, J. Morgenthaler, J. Penix, Y. Zhou, �Evaluating Static Analysis Defect Warnings On Production Software,� in Proceedings of the 7th ACM SIGPLAN-SIGSOFT workshop on Program analysis for software tools and engineering, 2007, pp. 1-8.

[75] T. Aslam, �A taxonomy of security faults in the unix operating system,� M.S. Thesis, Purdue University, 1995.

Key:
		Design Principle
		Design Heuristic
		Coding Heuristic

Bibliography

Custom FindBugs Detectors