Hi all, Tim Jarrett, Sr. Director of Product Management for Veracode Platform here. I wanted to let you know that we're making some important changes to the way sandbox scanning works for static scans, based on your feedback and use of sandboxes.

 

This feedback is meant to address the following:

  • Customers who create sandboxes as part of their automation can end up with an unmanageable number of sandboxes, making it difficult to work with the application or review results. 
  • It's challenging to find scans in progress across multiple sandboxes
  • Customers running several sandbox scans in an application at once may run into situations where some scans run longer because of queuing
  • There are few ways to automatically delete a sandbox
  • Sandbox scans remain and are redundant after promoting a sandbox scan to policy
  • Large numbers of sandbox scans can cause delays in publishing new scans, leading to unpredictable scan times.

 

Over the next few releases, we'll add a number of features that will help address these issues. These include:

  • A new API call for deleting sandboxes. Released in December, the deletesandbox.do API call removes a sandbox and the scans inside.
  • Option to delete sandbox upon promotion. Released on January 28, 2020, this option allows you to cause a sandbox to be deleted when promoting a scan from the sandbox to policy. The option is available both through the UI and API.
  • Increased simultaneous sandbox scan limits. Coming soon, you will be able to conduct more sandbox scans in parallel, but the ability to queue additional scans after the maximum number is reached will be removed.
  • Better sandbox list UI. Coming soon, you will see everyone's sandboxes by default and will see the state of the latest scan in each sandbox.
  • Time to live for sandboxes. Coming soon, by default, newly created sandboxes will have a time to live, after which they will be automatically deleted. Some important notes on this feature:
    • If you have a pipeline that always scans into a sandbox with a fixed name (e.g. Release Candidate), you can set this sandbox to automatically recreate itself when it expires so your automation is not interrupted.
    • Data for deleted sandboxes and their scans will still be available in Veracode Analytics, so you can continue to track sandbox usage even after the sandboxes are deleted from the Veracode Platform.
  • Maximum number of sandboxes. Coming soon, Veracode will enforce a maximum number of sandboxes per application (25 by default).

 

Together, these features will provide a balance of improved sandbox manageability, easier to find results, and better performance for all users of sandbox scans.

 

If you have applications with more than the maximum number of sandboxes, your Veracode program manager will reach out to you to discuss how this functionality will be rolled out and to ensure that your Veracode scanning will not be disrupted. Please feel free to ask questions here as well!


  • TCasey063603 (Community Member)

    Hi @Tim J (Veracode PM) (Veracode)​ , thanks for the heads up and some usable improvements. There is one statement that causes me concern though...

    Time to live for sandboxes. Coming soon, by default, newly created sandboxes will have a time to live, after which they will be automatically deleted.

    • If you have a pipeline that always scans into a sandbox with a fixed name (e.g. Release Candidate), you can set this sandbox to automatically recreate itself when it expires so your automation is not interrupted.
    • Data for deleted sandboxes and their scans will still be available in Veracode Analytics, so you can continue to track sandbox usage even after the sandboxes are deleted from the Veracode Platform

    This implies that all sandbox data, including scan results, will be deleted a set number of days after sandbox creation and presumably every x days after that. We encourage users to scan in sandboxes which are centrally created and have been encouraged by Veracode to scan subsets of large applications in sandboxes before long policy scans (I believe that you were on the call about this a couple of days ago?). Would it be possible to have permanent scan boxes, or sandboxes that expire if not used so that we can avoid the risk of losing current scan data at regular intervals?

     

    Expand Post
  • HemantShah (Community Member)

    I agree to @TCasey063603 (Community Member)​ , @Tim J (Veracode PM) (Veracode)​  It's worth to have permanent sandboxes. Not sure how much it will be effective to have just results in Veracode Analytics and not the actual sandboxes, it looks like chaotic if distributed team is working on the platform.

  • Hi @tcasey063603 and @hemantshah, thanks for the feedback!

     

    We recognize that different customers use sandboxes differently and have a couple different ways that we can recommend that you take advantage of the new features, depending on your individual use cases.

     

    One thing to bear in mind is that, if you are scanning frequently, your later sandbox scans will have a copy of any findings still open as of your most recent scan and will pull forward any proposed (or accepted or rejected) mitigations. So you will not lose any data regarding open findings. Once a new scan has been created, the old scan results are rarely if ever useful for this reason.

     

    If you'd like to discuss further and get some recommendations for accommodating your specific workflows, please feel free to contact me at tjarrett at veracode dot com and I'll be happy to talk with you in more detail.

    Expand Post
  • Hi all, just wanted to mention that we made an error in the original post and that the final version of the "time to live" feature does not allow for editing the time to live. The original sentence, with the erroneous sentence struck through, is below. We regret the error, which is due to implementation changes between the time the post was written and the time the feature was released.

    Time to live for sandboxes. Coming soon, by default, newly created sandboxes will have a time to live, after which they will be automatically deleted. You will be able to update the time to live at sandbox creation.

    Expand Post
  • AUB-1 (Community Member)

    @Tim J (Veracode PM) How do we set up a sandbox to recreate itself automatically from a Jenkins Pipeline? We use "createSandbox" parameter in Jenkins Pipeline to create sandboxes automatically, for example. We would like to do something similar to automatically recreate the sandbox itself. It does not look like it is documented. Please advise. Thank you.

    • Hi @AUB-1 (Community Member)​ , the auto_recreate parameter for createsandbox.do and updatesandbox.do is not yet available in the Java API Wrapper which powers the Jenkins integration. There are a few options available, mostly involving running a second script within the pipeline or on a timed basis.

       

      Here's a sample script that shows updating the sandboxes for a single application or an entire account to auto-recreate. This might be a starting point, though I suspect you'll want to be a little more targeted than setting every sandbox to this option. https://github.com/tjarrettveracode/veracode-sandbox-auto-recreate

       

      Hope this gets you going in the right direction!

      Expand Post
  • Syazwan (Community Member)

    May I know what will happened on the excess sandbox, like we already have more than 25 sandboxes in an application, do Veracode will remove the excess ?

    • Hi @Syazwan (Community Member)​ , good question! Over time some of the excess sandboxes will expire based on their expiration dates (see the section "Developer Sandbox Expiration" in the sandbox documentation for details), but you may need to remove some of the excess ones yourself if you are over 25 and find you need to create a new one.

Topics (4)

Ask the Community

Get answers, share a use case, discuss your favorite features, or get input from the community.

Trending Topics