See Supported Languages and Platforms for instructions for other platforms.
Supported Java JREs and Compilers
Java SE, Java EE, JSP
|JRE 1.4–1.9, 10, 11, 12, 13, 14||
The Veracode Platform can analyze Java code with or without debug symbols. Providing debug builds of Java application code allows the Veracode Platform to provide source file and line number information about the location of findings found. For a successful scan, you cannot obfuscate Java applications.
Certain findings found in code compiled with an earlier compiler version may be mitigated when you run that code on a later runtime environment. In such cases, the finding descriptions contain a note describing the version dependency.
Supported Java Frameworks
|Adobe Experience Manager||6.4 and earlier||Veracode supports compiled Java code for Sling Servlets, OSGi services, and AEM custom components, packaged as a JAR file.|
|Apache CXF||2.7.0||Veracode only supports the parts of CXF that expand JAX-WS.|
|Apache Velocity||1.7||Veracode only supports the web rendering usage of the default Velocity servlet for binaries uploaded in a WAR file.|
|AWS SDK for Java||1.11, 2.0|
|Google App Engine||1.9.24|
|Google Web Toolkit (GWT)||2.8.0|
|Hibernate||1.x, 2.x, 3.x, 4.0|
|Java Portlets||1.0, 2.0|
|JDBC||4.2 and earlier|
|Liferay||6.x||Liferay applications that have been customized using Hook plugins are not supported.|
|Spring Boot||1.x, 2.x||Supports executable JARs, also known as Uber FAT JARs, and JARs with dependencies|
|Spring Core||1.x, 2.x , 3.x, 4.x, 5.x|
|Spring Data Access||5.x|
|Spring MVC||2.x, 3.x, 4.x, 5.x|
|Spring Security||3.x, 4.x, 5.x|
Compilation Guidance (for debug builds)
javac -g foo.java
<javac debug="on"> ... set of classes </javac>
<build> <plugins> <plugin> <artifactId>maven-compiler-plugin</artifactId> <configuration> <debug>true</debug> <debuglevel>lines,vars,source</debuglevel> </configuration> </plugin> </plugins> </build>
After making this change, use mvn compile and/or mvn package to build and package the project as usual, and it will include debug symbols with the application.
apply plugin: 'java' gradle build
- Add variable attributes to generated class files.
- Add line number attributes to generated class files.
- Add source file name to generated class files.
Packaging the Application as a WAR, EAR, or JAR
The Veracode Platform expects you to submit Java web applications in a standard WAR or EAR format. Specifically, the WAR must contain the following directories and be structured as follows:
- /WEB-INF/classes/ (contains all class files)
- /WEB-INF/lib/ (contains all supporting libraries)
Veracode determines the scope of analysis by examining the contents of the WAR or EAR file. All classes to be analyzed must be referenced in the /WEB-INF/web.xml file, or be present within the /WEB-INF/classes directory.
Veracode recommends that EAR files contain a /META-INF/application.xml file. If there are no WAR files within an EAR file, it is not required to include the /WEB-INF/ directory or the /WEB-INF/web.xml file.
For more information on how to prepare a WAR file, see the Java EE tutorial.
Veracode supports the scanning of JAR files that contain a web.xml file in the /WEB-INF/ directory. Veracode scans these JARs as if they were WAR files, which improves support for application servers and packaging methods that handle this deployment method, including OSGi.
Veracode automatically compiles JSP files that are uploaded prior to performing analysis on them. The Veracode Platform uses the Tomcat Jasper compiler (version 7), or the WebLogic compiler (version 12.x) for WebLogic applications.
JSP files that are part of the application must be included in a correctly structured WAR or EAR file. If JSP or other source files must undergo preprocessing during the build process, you must perform this preprocessing before you can submit files for a static scan. However, if artifacts contain precompiled JSP classes, ensure that the source is also included. Precompiled JSP files are not analyzed. Ensure that any JSP files generated from templates or components, such as include files, are in a successfully compilable state prior to submission.
- In the .tld file included with the WAR, update the value of any <rtexprvalue> nodes to true.
- In individual JSPs, set the taglib URIs to point to versions of the taglibs that explicitly support rt-expressions. For instance, rather than pointing to the namespace http://java.sun.com/jstl/core, point to the namespace http://java.sun.com/jstl/core_rt.
If JSP files are dynamically generated at runtime, they cannot be statically analyzed and will be identified as missing dependencies during prescan verification. Static instances of these files, or stubs, should be provided to facilitate analysis.
The Veracode Platform cannot scan JSP files that cannot be compiled. JSP compilation errors are reported as part of the prescan verification process. An application that has JSP compilation errors can be submitted for scanning, but JSP files with compilation errors will not be analyzed.
Apache Velocity Template Files
Before scanning .vm files that you upload in a WAR archive, the Veracode Platform automatically compiles them using a custom compiler. Veracode does not scan .vm files that are inside JAR files, therefore, before submitting your application, be sure to package these files within WAR or EAR archives. The Veracode Platform cannot scan .vm files that an Apache Velocity engine cannot compile. Veracode does not scan any applications that do not meet these requirements.
Apache Axis and Axis2
If you are including any Apache Axis web service code within your WAR file, you must make all .wsdd files available in the /WEB-INF/ directory of the WAR. For further information on the creation of .wsdd files, please see Apache Axis documentation.
You must upload Axis2 modules in the MAR format and server-side Axis2 applications in the AAR format.
- /META-INF/module.xml (contains all modules files)
- /class_files (contains all class files)
- /META-INF/services.xml (contains all services files)
- /class_files (contains all class files)
For applications that are deployed on WebSphere, a common cause of JSP compilation failure is missing standard WebSphere libraries that are in the WebSphere environment but not packaged with the application. In the event of JSP compilation failure combined with warnings about missing classes, you can check the standard WebSphere directories for your deployed version of the JAR containing these classes; this may include the <was>lib/app directory or the ws.ext.dirs.
You can use a resource such as FindJar.com to identify which jars contain the classes that are indicated as missing by the Veracode Platform. You may also find the JAR Class Finder Plugin for Eclipse helpful.
In some cases, Veracode can substitute a stock library for libraries that are not provided with the application. It is generally better to provide the version of the library that your project uses to ensure that the application model accurately represents the functionality of your application.
Packaging Spring Boot Applications
- /BOOT-INF/classes/ (contains all class files)
- /BOOT-INF/lib/ (contains dependencies)
Packaging AWS Lambda Applications
Veracode requires you to submit applications built for AWS Lambda according to the AWS Lambda Deployment Package formats. For information, see https://docs.aws.amazon.com/ and search for AWS Lambda Deployment Package in Java.
Identifying Lambda Handlers for JavaThe analysis of Lambda functions relies on the identification of Lambda Handler methods. Veracode uses this set of heuristics to identify methods that can be candidates for handler methods:
- Classes implementing com.amazonaws.services.lambda.runtime.RequestHandler:
- The method handleRequest that overrides com.amazonaws.services.lambda.runtime.RequestHandler.handleRequest
- Classes implementing
- The method com.amazonaws.services.lambda.runtime.RequestStreamHandler.handleRequest
- Deployment packages that reference AWS components or namespaces and classes that do not
implement an AWS class:
- All public functions that have up to two input parameters, where the second parameter is of type com.amazonaws.services.lambda.runtime.Context
- All public functions that have up to two input parameters that the Lambda Deployment package does not reference
Software Composition Analysis
If you have a Veracode Software Composition Analysis subscription, you can include third-party components in your static analysis submission to report on vulnerabilities in those components. To effectively scan third-party components, the submitted application must also meet the packaging requirements for SCA upload and scan.