Skip to main content

Scan code in a sandbox

Your teams can use development sandboxes to use Upload and Scan to run Static Analysis and SCA scans of application code during testing, outside production environments. They can also scan against security policies to ensure that their code complies with your organization's security requirements. These policy scans do not affect the policy compliance of the entire application.

As a developer, you can create sandboxes within existing application profiles and submit the code for analysis while still in development. At the same time, you can still run a static policy scan of the same application code. Unlike a Policy scan, after completing a sandbox scan, the value of the policy_compliance_status parameter changes to Conditional Pass. You can promote that sandbox scan to a policy scan that counts toward your policy compliance score.

Using sandbox scans can reduce application security risk by allowing you to obtain feedback about your in-development applications. Sandbox scans do not degrade the policy status and flaw metrics for the production versions of those applications. You can analyze multiple versions of the same application at the same time as part of a branch or trunk-based development strategy.

The Veracode Platform matches flaws found in sandbox scans with those in policy scans to ensure any mitigations you have previously entered persist across all scans of the same application. Therefore, the code scanned within a sandbox is similar to the code the policy scan assesses.

For applications that comprise several microservices, we recommend that you do not scan these in isolation within separate sandboxes. This method inhibits the ability of your team to promote the sandbox scan to a policy scan, which impacts the effectiveness of progress reporting. Instead, if you must scan microservices in isolation, we recommend you create a separate application profile and use the sandbox and policy scan capabilities. This strategy facilitates the branching of the microservices as development progresses and enables you to perform mitigations as you create new versions of a microservice.

You can use metadata to tag application profiles by using custom fields in the metadata page or using the Veracode Applications API so that you can group applications as one microservice. You can, then, view the collective results in Veracode Analytics to track the security posture of a set of microservices.

The development sandbox is a temporary store of your security analysis. We retire this data based on the data retention setting that you apply. The policy scan is the true, audit-compliant record of analysis results.

How can I use development sandboxes?​

You can create and manage sandboxes in the following products.

Pipeline Scan does not support sandboxes.

About sandbox data retention​

The Veracode Platform retires data in sandboxes based on the data retention setting that you apply at the account level.

You can choose one of these data retention modes for sandboxes:

Time-to-Live Mode: in this mode, we automatically set an expiration date for development sandboxes when you create them. By default, we set the expiration date to 90 days after the sandbox creation date. After the sandbox expires, you cannot initiate any subsequent scans in the sandbox. However, you can still approve mitigations or promote scans from the sandbox for up to seven calendar days after the sandbox expires. After the seven-day period elapses, we delete the sandbox and its scans.

Rolling-Histories Mode: this mode preserves the last 15 scans you have prepared, on a rolling basis. The first scan in the sequence is the first scan to retire from your results after 15 scans have run. The sandbox itself never expires.

The rolling-histories mode is the default mode that we set at the account level for all new accounts since October 2020. If you want to switch modes, contact Veracode Technical Support.

About sandbox data expiration​

We archive information about expired sandboxes and scans before deleting these sandboxes and scans.

Before deleting an expired sandbox or an expired scan, the Veracode Platform archives all information about the sandbox scans and the most recent state of all the findings in the sandbox. You can view information about expired sandbox data in Veracode Analytics dashboards and queries.

You can automatically recreate a sandbox when it expires if you are in time-to-live mode. You can enable the auto-recreate setting when you create the sandbox using the Veracode Platform, or by using the createsandbox.do API call. When you set auto-recreate to true, the Veracode Platform:

  • Renames the expired sandbox by appending expired to the original filename
  • Creates a new sandbox with the sandbox name

A development pipeline that uses a sandbox for scanning can continue to operate without interruption.

In general, when in the rolling-histories mode, the sandbox data retention is more conducive to the continuous integration use case because the Veracode Platform never deletes the entire sandbox.

For information about the development sandbox expiration date and auto-recreate status, see the Sandbox page in the Veracode Platform. You can also call the getsandboxlist.do API to view this sandbox expiration date and auto-recreate status.

Last updated on