Veracode Upload and Scan
Use Veracode Upload and Scan to get a complete security assessment of your application by testing the source code, open source libraries, and assessing the test results against security policies, in a single operation. Upload and Scan performs Static Analysis scans, to find flaws in source code, and Software Composition Analysis (SCA) scans, to identify vulnerable libraries. You upload a packaged artifact of your application to the Veracode Platform, we prescan or scan your code, and generate scan results that list the discovered findings with remediation guidance.
By default, Upload and Scan performs both Static Analysis and SCA scans, but you must have licenses for these products to access the results.
Alternatively, test your code faster with Veracode Pipeline Scan.
How does Upload and Scan work?
- Uploads a packaged artifact of your application code to the Veracode Platform.
- Performs a prescan verification of your code and identifies open source components.
- Performs Static Analysis and Software Composition Analysis (SCA) scans, which can also run in a development sandbox, to detect security findings in source code and open source libraries.
- Analyzes the results of your code against security policies to assess the application's compliance with your organization's security requirements.
- Provides scan results that you can review in the Veracode Platform, download and review in your IDEs, or access using the APIs.
To access the results from different scans of the same application from one location, you can link the results to application profiles.
How can I use Upload and Scan?
You can use Upload and Scan in the following products.
Veracode Platform and services
Integrations
- Static-only IDE plugins and extensions: these are older plugins and extensions that only support Static Analysis scans, but they also support mitigating findings. We aren't updating them with new features. We recommend you use the Veracode Scan plugins and extensions, which support Static Analysis and SCA scans, automatic code packaging, and Veracode Fix.
- SCM integrations
- CI/CD integrations
- XML APIs and API wrappers
Supported languages
Upload and Scan supports several languages for Static Analysis and SCA scans.
Prerequisites
To use Upload and Scan, you must have:
- An active Veracode Static Analysis or SCA license.
- For Static Analysis, you must have the Creator, Submitter, or Security Lead role. For SCA, you must have the Executive, Security Lead, or Administrator role.
- An artifact of the application you want to scan that meets the packaging requirements.
The products that support Upload and Scan also have specific prerequisites.
Packaged artifacts
To upload your application for scanning, you must package your code into an artifact. The artifact must meet the packaging requirements of the coding language in which the application is written. The packaged source files must not exceed the upload limits.
To simplify the packaging process, we recommend using the autopacker.
To generate language-specific packaging guidance for Static Analysis, you can use the Veracode Packaging Cheat Sheet.
Limits for uploaded files
We enforce the following limits for files you upload in a packaged artifact.
| Upload limit | Value |
|---|---|
| Largest individual file you can upload | 2 GB |
| Total maximum size of all the uploaded files that we can analyze in a single scan | 5 GB |
| Total number of files that we can analyze in a single scan | 50,000 files |
Prescan verification
After you upload your application for Static Analysis, we automatically perform a prescan verification. The prescan conducts an initial analysis of the application to verify you have packaged the application correctly. A prescan fails if the uploaded application has fatal or blocking errors. Prescan uses hashes to produce an inventory of open-source components and associated vulnerabilities.
During a Static Analysis, you might receive warning or error messages about the uploaded files.
Top-level modules
A prescan of your application code to identifies the top-level modules, scans any dependencies, and notifies you about any fatal or blocking errors to resolve before starting a Static Analysis scan.
A module represents a discrete component of the uploaded application that we analyze during scanning. The top-level modules are the components identified during prescan that have entry points for external data. Entry points typically are modules that include first-party code. You can only select the top-level modules for scanning.
Prescan validation can identify dependencies or supporting files in top-level modules. We scan dependencies resulting from scanning the selected top-level modules that depend on them.
- In Java, 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, 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++, the uploaded main application is the top-level module.
- In Apple Platforms, Ruby on Rails, PHP, and other supported languages, the top-level modules are the uploaded files.
Prescan status messages
If the prescan operation identifies problems in your application modules, or determines that the application does not contain any problems, it provides error and warning messages.
Prescan status in the Veracode Platform
The Application page shows the following messages in the Status column.
: prescan identified one or more problems that prevent Veracode from proceeding with the scan.
: prescan identified one or more problems that might degrade the quality of the scan results, but do not prevent Veracode from proceeding with the scan.
: prescan did not identify any problems and Veracode can proceed with the scan.
Prescan status in the APIs
Use the following API call: getprescanresults.do
Potential issues
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 an issue with the submission that may impact results quality or scan performance. Expand the module details for more information about the specific issue. Veracode detects these common support issues:
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.
Veracode Mobile Behavioral Analysis
Veracode Mobile Behavioral Analysis find static flaws in mobile applications. Veracode examines the permissions that the submitted mobile application requests, which can provide valuable insights into the behavior of the application.
A common security risk with mobile applications is called over-permissioning. Over-permissioning occurs when mobile applications request permissions that are unnecessary for the application to function. These permissions might be requested accidentally by the developers, or requested by a third-party component included with the application.
A consolidated list of permissions that the application is requesting can help both developers and end users understand what the application is capable of doing, and the risk the permission may present.
Developers and security leads should review the list of permissions that the application requests, and validate that these permissions meet their expectations.
Mobile Behavioral Analysis is available when analyzing native Android applications built as APK files, and Apple Platform applications packaged as xcarchive bundles. Mobile Behavioral Analysis is not available for mobile applications built using Titanium, PhoneGap, Cordova, or Xamarin.
When the scan is complete, a list of permissions requested by the application will be available by viewing the Mobile Behavioral Analysis link in the Veracode Platform.
You can review the permissions listed in the table and determine if the permission settings are appropriate for your application. Mobile Behavioral Analysis findings do not impact your policy score.
Estimated scan completion time
We compute the estimated completion time for prescans and Static Analysis scans of applications based on historical delivery times for applications of similar size and language.
Considerations for large applications
The amount of time that it takes to deliver results for a static scan depends on many factors, including the language or platform in which the application was written, the size of the application, and whether the application is being scanned on behalf of a third party.
Large applications may take additional time to process. The actual processing time can vary by language, platform, and unique behaviors of the submitted code. For example, applications submitted with missing dependencies, or with dependencies compiled without debug symbols, can take longer.
Veracode makes every effort to deliver results as soon as possible. Therefore, if applications complete analysis sooner than the estimated delivery window, Veracode publishes the results sooner.
Scans under investigation
If we encounter a technical issue during scanning, the Estimated Delivery field shows the Under Investigation status, indicating that Veracode is working to resolve the issue.
How we match filenames between scans
The Veracode Platform attempts to match uploaded application files that appear to be related to a source file, but might have different build or version numbers. By matching these files, the Veracode Platform can track flaws across different builds without falsely reporting any new flaws because the name of the container changes between scans.
The matching scheme examines only the last characters of the filename preceding the file extension. Consider these sample files:
myapp-123.dllmyapp-124.dll
Veracode recognizes these files as different versions of the same file because they contain the same base name, myapp. Only the trailing numbers 123 and 124 at the end of the filename are different.
These filenames do not match the previous filenames because the final part of the names contain alphabetic characters:
myapp-123-test.dllmyapp-124-test.dll
In some circumstances, this filename matching scheme may encounter problems. You might upload files that appear to match and Veracode does not match them. Consider an application that has multiple, similar files in the build, such as:
function-1.dllfunction-2.dllfunction-3.dll
In this scenario, flaw matching can encounter problems between scans when Veracode matches them as versions of the same file although they are unrelated. Depending on which file the Veracode Platform finds first, the module listing for the scan identifies code added or removed because these files contain different code.
We recommend that you append alphabetic characters to the end of the filename to avoid ending the filename with numerals.