Scan code
Veracode Static Analysis is a Static Application Security Testing (SAST) solution that enables you to quickly identify and remediate application security findings (flaws) in source code. It can analyze major frameworks and languages without requiring source code, so you can assess the code you write, buy, or download, and measure progress within your development workflows.
The Veracode Static Analysis Engine scans and analyzes the compiled binary code or bytecode of an application that you upload as a packaged artifact. The patented Veracode methodology creates a complete model of the application’s control and data flow from the executable binary. It then tests the model to detect flaw patterns.
With Veracode Static Analysis integrated with your development tools and workflows, and by using our one-on-one remediation advice, your development teams can write secure code and assess the security of web, mobile, desktop, and back-end applications.
Static Analysis Engine
For updates on the Static Analysis Engine releases, see Static Analysis updates.
Code scanning solutions
Veracode Static Analysis is available in the following solutions that you can use in several products.
Upload and Scan
Use Upload and Scan to get a complete risk assessment of your applications, including source code and open-source risk. These scans perform both Static Analysis and Software Composition Analysis (SCA), to test the security of both your first-party code and open-source libraries and components, in a single operation.
Scan in the Veracode Platform, your IDEs, CI/CD pipelines, SCM repositories, and review the results in these tools. Run policy scans to assess the results against security policies and use development sandboxes to scan during testing, outside production environments. If you have previously run Static Analysis scans on an application, the SCA results for that application are available immediately after you activate your SCA license.
See the supported languages.
Pipeline Scan
Use Pipeline Scan to run Static Analysis scans in your IDEs, CI/CD pipelines, SCM repositories, and review the results in these tools. The scans are faster than Upload and Scan, and you can configure them to run frequently, such as every commit, every push or pull request, or every build. To detect new findings during scanning, create a baseline of security findings, and set builds to break based on security thresholds or specific CWEs. To fix flaws with suggested code patches automatically, use or integrate Veracode Fix.
See the supported languages.
Packaged artifacts
To upload your application for scanning, you must package your code into an artifact, such as a WAR, TAR, or ZIP file. The artifact must meet the packaging requirements, which might involve compiling your code, of the coding language in which the application is written.
To simplify the packaging process, we recommend using auto-packaging.
To generate language-specific packaging guidance for Static Analysis, you can use the Veracode Packaging Cheat Sheet.
Prescan verification
After you upload a packaged artifact of your application for scanning, we automatically perform a prescan verification. The prescan conducts an initial analysis of the application to verify that it's packaged correctly and to identify the top-level modules you can scan. For Upload and Scan, prescan also uses hashes to produce an inventory of open-source components and associated vulnerabilities.
A prescan fails if the uploaded application has fatal or blocking errors. During scanning, you might receive warning or error messages about the uploaded files.
Top-level modules
A prescan verification of your application code identifies the top-level modules. A module represents a discrete component of the uploaded application that we analyze during scanning. The top-level modules are the components that have entry points for external data. Entry points are typically modules that include first-party code. Prescan also identifies any dependencies or supporting files in top-level modules. You can only select the top-level modules for scanning.
- In Java code, uploaded WAR and EAR files are always the top-level modules. Uploaded JAR files usually are top-level modules, except when they are dependencies of other Java artifacts.
- In .NET code, the uploaded EXE files are usually the top-level modules. If they are not a dependency for another part of the application, uploaded DLL files can be top-level modules.
- In C++ code, the uploaded main application is the top-level module.
- In code for Apple Platforms, Ruby on Rails, PHP, and other supported languages, the top-level modules are the uploaded files.
Prescan status messages
If the prescan verification identifies problems in your application modules, it provides error and warning messages that help you resolve the problems before attempting to run a full scan.
If you are using Upload and Scan, you can review the prescan results in the Veracode Platform. You can also access these messages with the getprescanresults.do API call.
If you are using Pipeline Scan, you can review the prescan results at the command line or in your Pipeline Scan integrations.
Warnings or errors detected during prescan might be due to one or more of the following issues.
Corrupt headers
The module appears to have corrupt headers, and may have been modified after compilation. Try to recompile the module.
Deprecated platform
The module is built with a platform, such as a compiler, that Veracode does not actively support. Results from the analysis of this module are not as accurate as results produced from supported platforms. Attempting to analyze this module may cause the analysis to fail. If it is a primary module, try to recompile the module for a supported platform. For example, a primary module may be an executable rather than a supporting library.
Incrementally linked libraries
The module is built with incremental linking turned on. In some cases, this condition can impair the quality of the analysis and increase scan times. If possible, try to recompile the module without incremental linking.
JSP compilation errors
Veracode cannot analyze JSP files that cannot be compiled. If you receive this message, verify that you include all files and classes on which the JSP files depend. Upload any missing files and classes. For more information, see Java packaging.
Missing debug information
If Veracode shows any modules as missing debug information, in red, you must recompile the associated binaries according to the packaging requirements and upload them again. Veracode does not require debug information for every language. However, failing to include debug information may result in lower quality findings and increased scan times. Veracode also requires debug information to report the source file and line number for findings.
Missing entry point
For a successful static scan, each application or executable module needs a starting point. For a C application, this entry point might be a main() function and for a web application, it might be one or more JSP or ASPX pages.
No precompiled files located
To analyze ASP.NET applications, Veracode requires you to precompile the dynamically generated pages, which are typically prepared at runtime by the application server. If you do not submit precompiled forms, the scan might produce incomplete or incorrect results. For more information, refer to ASP.NET packaging.
To prepare your .NET application for uploading and scanning, we recommend you use Veracode Static for Visual Studio.
Obfuscated or optimized code
Veracode cannot analyze code compiled with optimizations, or code that has been obfuscated. Recompile the binaries without optimizations or obfuscation and resubmit.
Supporting files missing
Carefully review the list of missing files shown as Not Found. Ensure that none of the files you want to analyze are missing. If you identify any missing supporting files, select Add Files and add the libraries containing the dependencies.
For C/C++ applications, supporting files are required. If you do not upload the supporting files for a module, you cannot scan that module.
Unsupported architecture, platform, or compiler
If any modules show an Unsupported Architecture, Platform, or Compiler message, in red, Veracode cannot analyze these modules. If you see this message, review the list of supported platforms and compilers. If possible, try to recompile the binaries with a supported compiler or platform. For example, for a Linux binary, try compiling on a Red Hat platform. For a 64-bit Windows binary, try compiling for 32-bit.
Unsupported frameworks (non-blocking)
This message is informational only, which means that your scan proceeds even if your scan request is for an application that has one or more unsupported frameworks. After the scan of an unsupported framework, Veracode typically produces an incomplete list of the findings in the application. These findings are valid, but because the use of the unsupported frameworks can prevent Veracode from creating a complete model of the application before scanning, parts of the application were not scanned, which leads to an incomplete findings list.
Support issue
Veracode detected one or more of the following issues with the submission that may impact results quality or scan performance. In the Veracode Platform, expand the module details for more information about a specific issue.
Mismatched PDB files
Veracode could not load the debug information included for this module as they are not artifacts of the same compilation as the matching binary. Include the debug files you generated at the same time as the binary. You may need to perform a clean rebuild of the application.
Parse failure
The source files indicated by this warning may contain syntax errors that prevent Veracode from analyzing them. Review the code to ensure it is syntactically correct for the language, that it is a supported dialect. Ensure that you include any required dependencies in the submission. Veracode cannot scan files with parse failures. Veracode excludes these files from analysis if you choose to proceed.
Minified files
The JavaScript or TypeScript source files indicated by this warning are minified, obfuscated, or both. Upload only JavaScript or TypeScript source files without any post-processing. Veracode cannot scan minified files and excludes them from analysis.
Uploaded source code without binaries
The submission contains source code files, but no corresponding compiled binary. Veracode analyzes compiled binary executables, rather than source code. For specific formatting instructions, refer to the packaging requirements.
Web.xml errors
If you are uploading a Java web archive (WAR) for analysis, you may receive one of several messages regarding a missing, empty, or incorrect WEB-INF/web.xml filepath. As detailed in the packaging guidance for WAR, EAR, and JAR files in the Java packaging requirements, the WAR must contain a valid XML deployment descriptor. Review the instructions and resubmit with a correct WEB-INF/web.xml filepath.
About static flaws
Flaws are security findings in your application code found by static analysis that represent potentially dangerous code paths. Generally speaking, these fall into two categories: vulnerabilities and potential vulnerabilities. Vulnerabilities are exploitable weaknesses in the application, with a code path that can be found and exploited by an attacker to impair the confidentiality of the application, integrity, or availability. Potential vulnerabilities represent weaknesses in the application code that may not be exploitable by an attacker at the present time, either because the code path is unreachable or because some mitigating factor is in place in the code base. However, potential vulnerabilities may become true vulnerabilities in the future if the code architecture or deployment method of the application changes, or if the flawed code is called in another program.
Veracode Static Analysis uses debug information to report the source file and line number on which the flaw exists, aiding in remediation. Java and .NET applications can be analyzed in non-debug form, but the resulting flaws from a non-debug analysis do not have source file and line number information. Instead, information about the location of the flaw is given relative to the module, class path, function name, and approximate location within the function body. See the compilation instructions for information on how to build your application with debug information.
Veracode's rules for data retention and archiving
We retain your uploaded binaries according to specific retention rules for user-provided and system-generated data.
User-provided data
You upload your application files to the Veracode Platform for analysis. Veracode recognizes these application files as binaries, which include the ZIP archives of JavaScript and other source languages. After you upload binaries, Veracode retains them for a number of days to:
- Perform results-quality investigations upon request
- Support rescan without re-uploading modules with issues or errors
Veracode sets these default retention periods for these files:
- 45 days for binaries for a submitted scan.
- 90 days for scans you started, but did not submit. This status can occur if:
- The prescan completed, but you did not select Submit.
- The prescan did not complete because it found errors.
- You created the scan, but did not upload any files.
These periods are subject to change. Veracode may decrease these retention periods for your Veracode account.
When Veracode deletes an uploaded binary, it adds an entry to the activity log for the scan. The activity log identifies the binaries deleted for a specific scan. After deleting the uploaded binary, Veracode cycles the encryption key.
Template files
A template file consists of an application file provided as source code. For example, the application file might be a JSP, JavaScript, or Python file. Veracode retains template files for a number of days to allow you to view the results of a static scan in the Triage Flaws page. Veracode does not require you to select the source file in the browser.
Veracode sets the default retention period for template files to 60 days, but this period is subject to change. Veracode may decrease this retention period for your Veracode Platform account.
Veracode-generated data
Veracode generates a datapath for certain types of static findings. This datapath includes a list of source files and line numbers in the application through which your data passes to the potentially-vulnerable line. Veracode retains this datapath information by keeping either of these collections, whichever has the larger number of scans:
- The last three scans
- All scans from the last three months
If a scan is older than the retention timeframe, Veracode automatically removes its datapath information. If the finding remains open, you can view the datapath in results for the latest scan.
Sandbox scan results
Veracode retains sandbox scan results according to the time-to-live setting for the sandbox. After the time-to-live period expires, Veracode archives sandbox scan results to Veracode Analytics.
After you delete sandbox information, you cannot recover it.
Pipeline Scan data
When you use Pipeline Scan to upload your application files to the Veracode Platform for analysis, Veracode only retains the uploaded application files during the scan. When the scan is complete, Veracode immediately deletes the uploaded application files. Veracode retains Pipeline Scan results files for 24 hours after scan completion.
About complementary user entity controls
Veracode takes responsibility for ensuring the security of your information when it is under Veracode’s control. However, some Veracode products and solutions depend on administrative controls within your organization or rely on infrastructure deployed in your environment. Therefore, your organization is responsible for implementing additional controls related to the use of Veracode products.
Veracode agreements document these shared responsibilities. The following is not a comprehensive list of all relevant security controls:
Communication and information
- Your organization must report any identified security violations related to the Veracode Platform products as soon as they are discovered.
- Your organization must communicate applicable security and confidentiality provisions to individuals who access Veracode products and services.
- Your users are responsible for reading Veracode documentation to stay current with product and service updates.
Monitoring activities
Your users are responsible for monitoring Veracode products and services for notifications and status information.
Logical and physical access
- Organizations that use the Virtual Scan Appliance, Application Perimeter Monitoring, Veracode Discovery, Veracode Dynamic Analysis, or Veracode Internal Scanning Management are responsible for managing their network and server infrastructure.
- Your organization must ensure that access to Veracode products and services is limited to authorized individuals and that secure user IDs and passwords are used.
- Your organization is responsible for reviewing employee access, including contractors, and notifying Veracode of any discrepancies.
System operations
Your organization is responsible for reporting any security or confidentiality breaches, as well as availability incidents, that impact Veracode products and services.