Hello @SKannothu143902 (Community Member)​ ,

I would recommend reading the Veracode blog How do you organize application profiles? which has some great tips and an article on what to consider when creating an application profile.

In regards to the expiration of a sandbox, there is a Help Center Article on Understanding Veracode Rules for Data Retention and Archiving, with Veracode retaining sandbox scan results according to the time-to-live setting for the sandbox.

Jason

Veracode Support Engineer

To supplement what Jason wrote...

I view this as a bit tricky, because of licensing. Each application requires a license be bought/paid for, so it might be best to talk with your sales or technical account manager to determine whether your sub-applications are indeed applications under the terms of the licensing. I know there is a concept of a "small application" that is charged differently (for things like microservices, etc.)

If they are not, I would suggest that they should be uploaded as part of common payload containing all the entry points, as there really isn't a concept of "sub-applications" in the Veracode Platform at this time. I do believe there are ways to "group" top-level Applications for reporting purposes though (but we only have 1 application, so this is not something I've used).

As far as I can tell, Sandboxes are really intended for developers to upload "works in progress" (i.e. a private branch) of their work before submitting it to a main branch, or for your build server to push versions from different branches.

It's also important to note that you can only really perform "dynamic scans" and "manual penetration tests" against "policy" -- which means that Sandboxes are only effective for static scans. While you can easily ask the "dynamic scanner" to scan different URLs, you can only bind each scan to one application. So, if you have different "applications" with different URLs, you really need different "Applications" within the Veracode Platform.

@SKannothu143902 (Community Member)​ The Application Profile model on Veracode is dated and not designed for modern distributed applications/systems or shared private components. I have been told they are working on a new model for profiles that will better align with these needs. Sandboxes would not be the right approach for this in my opinion they are designed to test code changes and uploads before having them impact policy and reporting.

The best approach for this I have found is using a team, business unit, application tag, or custom field as a filter in data analytics to export what I need, but you can't get a nice report consolidated pdf report that way. You can also try using another system like DefectDojo or RiskSense to perform the appropriate aggregation.

I agree this is a tricky question to answer for several noted reasons above:

• Data retention on sandboxes
• Inability to commit more than one sandbox to policy (overwrites the existing policy)
• Components can exist within MULTIPLE applications
• Components are typically not built at the same time; never deployed in an "all or none approach" (some are built and live in dormant code change state)
• License costs contribute to applying the thoughts of a monolith on a micro-service/component; Especially across SAST, SCA and pipeline scanning offerings

If these are some of the same thoughts that you are wrestling with, then you are in a good space - because you are thinking of how to position your usage of the platform for legacy and modern application development practices.

There is a great reference document that was built last year to cover some of these use cases. You can find that reference document entitled "Static Analysis Reference Architecture: Best Practices for Pipeline Scan, Sandboxes, Application Profiles and Microservices" . I highly recommend reading this document before you begin.

The path/strategy that I've started down is the following:

• Build a process to determine a risk attribute based model that aligns to your company's security policy for scanning code
• <IF> the component is tall enough to meet the test of requiring a Policy Scan:
  • Create an Application Profile per component
  • Use Custom fields (like Product Name) to tie Application Profiles together.
  • Can use these fields to also tie in production/non-prod URLs and github repos, then leverage the API tie security scans together
• Use sandboxes
  • To test a new language/framework that you've not onboarded.
  • Integrate with Greenlight if you've purchased licenses
  • See if the effort provides value before creating the application and putting the developer on the ride
• If the component is <not tall enough> or a MVP (minimal viable product)
  • leverage the pipeline scanner where you can get great feedback if language is supported earlier in these development phases.
  • use the opportunity to give value back to developers early w/o burdening them with the reporting

Parting thoughts:

• Each company is different, certain industries require more rigor than others
• EVERYONE wants Security, most want something simple, quick and easy to understand. Few will build this, many will follow.
• I do not use the platform for reporting / analytics. For my case, I feel an aggregated reporting platform offers a single lens across all Security Scan engines (SAST, DAST, VM/OS Container, etc..) and can paint a better picture for Product/Project managers to help prioritize remediation efforts.
• There are pros/cons to maintaining multiple scan engines, but I feel better to define a process and align output to a single Vulnerability Assessment/Management platform.
• I agree 130% that the Application Profile licensing model is dated with @ig596 (Community Member)​. You will need a Risk based Inventory and work with your Account Manager to find the sweet spot for your organization.
• Know that during this time, others will be actively working to enable open source solutions to solve for their specific needs.
• It can be challenging to balance all needs - pick ones that you can provide value to be successful.

Hope that helps and thank you for asking within this Community.