What is an Application Profile and what to consider when creating one?

Application Profiles are important to your AppSec program. They describe your application, identify policies for evaluation, and provide vital metadata for deeper analysis of security performance. In this article, we will discuss what a Veracode Application Profile is, how you might structure an application and its Application Profile, and what you should keep in mind when organizing your Veracode Application Profiles.

What is a Veracode Application Profile?

In the context of a Veracode scan, an application is a collection of logically related software components performing a coordinated set of functions, and an Application Profile is used to organize assessments of an application within the Veracode Platform.

Under this definition, a single script less than a KiB with "echo 'Hello World';" can be an application. An application can also be a grouping of an iOS app, an Android app, a Gb of JavaScript, and many more Gb of Java, .NET, and C++ binaries.

Let’s look at some examples of application structures and how they can translate to an Application Profile.

Examples: Application Structures and Their Application Profiles

• Monolith/Single Application
  A single application will naturally translate to a single Application Profile.

• Frontend + Backend
  Depending on the results and license this will typically result in two Application Profiles.

• N-Tier Architecture
  A typical N-tier/multi-tier architecture where the presentation layer uses method calls to get data from a services/business layer, etc., can be treated like a Monolith/single application. Typically, this would be scanned as one Application Profile. If, however, API calls are used between layers, then please use the guidance for Micro-Services.

• Micro-Services
  Depending on the results and license, this will typically result in many Application Profiles.

• Many Customized Versions of the Same Codebase
  This will typically result in many Application Profiles.

• Application Suite
  This will typically result in many Application Profiles.
  

Seven Things to Keep in Mind When Organizing Veracode Application Profiles

For the Veracode Static Analysis purposes, we recommend keeping in mind the following constraints when determining what to upload to your Application Profiles:

1. Policy: policy applies the same for all binaries in 1 Application Profile.

2. Flaws and mitigations: these are stored in an Application Profile.

3. Entry points: an Application Profile should have at least 1 network or user-facing component.

4. No more than one library version: libraries should be unique per scan, and you should not have a library with multiple versions.

5. Licensing: you may be constrained by the number of your license with Veracode in the number of Application Profiles.

6. Consistency: roughly the same thing should be uploaded every single scan

7. Speed: the smaller the scan, the faster it will likely run

Now, let’s go into each concern separately.

Policy Results

A policy is applied to an Application Profile. You cannot apply policy accross parts of an application profile. You can use the Collections feature to review policy for multiple Application Profiles. Please contact your Veracode Customer Success Manager if you do not yet have access to the Collections menu item under the My Portfolio menu.

Bottom line:Policy can only be applied on a per Application Profile basis. We recommend choosing smaller profiles over larger profiles where possible.

Flaws and Mitigations

As you rescan the same application, Veracode attempts to maintain the flaw identifier for a flaw using ; you can find more on this process in our documentation: flaw matching. A Veracode-identified flaw can also be annotated with a comment or a mitigation, describing some mitigating control. You can learn more about this process in our documentation : About Mitigating Flaws.

Flaw information and associated annotations like comments and mitigations are part of an Application Profile’s data and are non-transferrable to another Application Profile (note that there are several Community Projects that do allow you to copy some of this information).

This means that if a binary or set of source files is part of multiple Application Profiles, you will have to re-propose any mitigations.

Bottom line:A binary or set of source files should not be part of multiple Application Profiles unless it is used as a library or framework.

Entry Points

Veracode Static Analysis requires that applications are compiled and/or packaged per the Veracode Packaging Requirements. Typically, this requires that you submit all linked/imported/required libraries and frameworks.

Many Veracode analyses require an “entry point”— something that represents the launching of the application (main functions) or point of connection or communication (web page, restful, etc.) and requires the ability to trace data through all invocations in the application.

See also the article: What are Modules and how do my results change based on what I select?

While Veracode Static Analysis will often allow scanning of a library or framework, the results will typically be less actionable (higher rate of false positives).

Bottom line: If the binary or source code cannot be separately accessed (internally or externally), it should not be scanned separately.

No More Than One Version of the Same Library

A technical limitation of Veracode Static Analysis is that for compiled languages, such as C, C++, Java, and .NET, if you have multiple versions of the same library in the root of a scan, we may not be able to determine which library is used by which app and may generate incorrect results.

You can safely have multiple versions of the same library in two different WAR files in one scan or multiple versions of the same library statically compiled into 2 C/C++ apps. However, you may experience issues if you have multiple versions of the same library at the root of the scan.

Bottom line: Separate .NET, C, C++, and Java applications into different Application Profiles.

Licensing

Some of the licenses for Veracode Static Analysis depend on the number of Application Profiles in use. Please contact your Veracode Customer Success Manager if you're unsure about your license with Veracode or if you wish to discuss alternate licensing.

Bottom line: Ensure you understand your license with Veracode before creating a new Application Profile.

Consistency

Various features around Application Profiles rely on consistency of upload. Most importantly of these Flaw matching.

If your first upload contains:

• myapp-api.jar
• myapp-frontend-javascript.zip
• myapp-desktop-exe-and-dlls.zip

you could for example add an Android app:

• myapp-api.jar
• myapp-frontend-javascript.zip
• myapp-desktop-exe-and-dlls.zip
• myapp-android-apk.zip

or you could add new JavaScript files within myapp-frontend-javascript.zip but you should not scan other components not related to this application:

• hrapp-ios-app.zip
• hrapp-website.zip

Bottom line: Ensure you are consistently uploading roughly the same thing.

Speed

The more you upload for a single scan, the longer the scan is likely to take.
Please keep in mind that the relationship between scan size and scan time is a complex one, smaller, more complex applications may take longer than larger more simple applications. But in general, it's a good idea to reduce scan size as much as possible.

Bottom line: When in doubt, go for smaller uploads and distribute scanning over more application profiles.