Policies

Use Veracode Platform security policies to define and enforce a uniform application security policy for all applications across your entire application portfolio, including applications you develop and third-party applications.

You assign a policy to one or more application profiles. After the Veracode Platform scans the application, it assesses the scan results against the policy. To pass a security policy, a application must comply with the constraints defined in the policy.

We provide built-in policies, which have pre-configured constraints, that you can assign to application profiles. You can also create and assign custom policies to configure the constraints that enforce specific security requirements for your organization.

To use policies with Veracode Package Firewall, see manage custom policies for Veracode Package Firewall.

Benefits

Security policies provide several benefits, such as:

• A Veracode Level that applications must comply with to pass the policy. Each level has a minimum security score.
• Rules that define findings that an application must not have, such as findings included in security standards, such as OWASP, OWASP Mobile, CWE Top 25, or PCI.
• For SCA scan results, rules that define open-source components that are not allowed.
• Required types of scans to run on an application and how often they must occur to meet policy compliance.
• Evaluation timeframes that establish the period during which findings, if not resolved, can impact policy compliance.
• Grace periods that establish the amount of time your teams have to resolve findings before impacting policy compliance.

You can also manage policies with the Policy API.

Prerequisites

To create or manage policies, you must have the Policy Administrator role.

Assign a policy to an application

Assign a built-in policy or a custom policy to an application profile. Assigning multiple policies to the same application profile is not supported.

When you select the business criticality for the application, the Veracode Platform automatically assigns a policy to an application, based on the default policy rules of the organization.

note

Changing the policy for an application applies to all future scans and updates the policy assessment of the most recent scan for this application.

To complete this task:

1. Sign in to the Veracode Platform.
2. On the Applications page, select the application name to open the application overview.
3. In the left navigation menu, select Edit Profile.
4. In the Policy field, select the policy you want to set for the application from the dropdown menu.
5. Optionally, to see details about the selected policy, select View Policy Details.
6. To assign the selected policy, select SUBMIT.

Built-in policies

To help organizations begin evaluating their applications against security standards, we provide pre-configured built-in policies. There are two sets of built-in policies for Static Analysis and Dynamic Analysis scans, and one built-in policy for SCA agent-based scans.

You can set a built-in policy as the default policy for a given business criticality.

Veracode recommended policies

Recommended policies assess your applications based on their business criticality. Once your teams are familiar with these policies, consider creating your own custom policies.

The following table lists the recommended policies. To learn about the Target VL (Veracode Levels), see About Veracode Levels.

note

The recommended policies are named after Veracode's business criticality ratings, not finding severity ratings.

Policy name	Target VL	Flaw severities	Minimum score	Scan requirement
Veracode Recommended Very High	VL5	No Medium or above	90	Static (quarterly) Manual (annually)
Veracode Recommended Very High + SCA	VL5+SCA	No Medium or above	90	Static and SCA (quarterly) Manual (annually)
Veracode Recommended High	VL4	No Medium or above	80	Static (quarterly)
Veracode Recommended High + SCA	VL4+SCA	No Medium or above	80	Static and SCA (quarterly)
Veracode Recommended Medium	VL3	No High or above	70	Static (quarterly)
Veracode Recommended Medium + SCA	VL3+SCA	No High or above	70	Static and SCA (quarterly)
Veracode Recommended Low	VL2	No Very High or above	60	Any (semi-annually)
Veracode Recommended Very Low	VL1			Any (once)
Veracode Recommended Mobile Policy				Static (quarterly)
PCI 3.2.1		No High or above OWASP Top 10 CWE Top 25 CERT		Any (once)

Veracode transitional policies

Transitional policies are no longer recommended. They were originally created to establish a baseline Security Quality Score for applications without policies.

note

Transitional policies don't support grace periods. Without a grace period, the Security Quality Score is effective as soon as the scan results are published.

The following table lists the transitional policies. To learn about the Target VL (Veracode Levels), see About Veracode Levels.

Policy name	Target VL	Minimum score	Scan requirement
Veracode Transitional Very High	VL1	90	Any (Once)
Veracode Transitional High	VL1	80	Any (Once)
Veracode Transitional Medium	VL1	70	Any (Once)
Veracode Transitional Low	VL1	60	Any (Once)
Veracode Transitional Very Low	VL1	50	Any (Once)

Built-in policy for SCA agent-based scans

By default, Veracode applies the Veracode Recommended SCA Very High policy to SCA agent-based workspaces.

The following table lists the rules in this policy.

Rule type	Requirement	Advanced options
Findings by Severity	Low and above are not allowed	Not applicable. This rule does not apply to SCA agent-based scans.
Vulnerability Severity	Very High are not allowed	Vulnerable Methods: Any Dependency: Any Fix Available: Any Build Action: Warning Override Severity: No
Vulnerability Severity	High are not allowed	Vulnerable Methods: Any Dependency: Any Fix Available: Any Build Action: Warning Override Severity: No
Vulnerability Severity	Medium are not allowed	Vulnerable Methods: Any Dependency: Any Fix Available: Any Build Action: Warning Override Severity: No
Vulnerability Severity	Low are not allowed	Vulnerable Methods: Any Dependency: Any Fix Available: Any Build Action: Warning Override Severity: No
Component License	High	Dependency: Direct Non-OSS Licenses Unrecognized Licenses: Allowed Component with Multiple Licenses: All licenses must meet requirements Build Action: Warning Override Severity: No
Component Version	Outdated	Dependency: Direct Build Action: Warning Override Severity: No

Custom policies

Create custom policies and configure them to meet the specific security requirements for your applications. We provide built-in policies that you can assign to your applications. You can't change the built-in policies, but you can copy them to create custom policies, and then configure the copies.

You can also manage policies with the Policy API.

Create a custom policy

Policies must include one or more constraints that define the security requirements that scanned applications must meet to pass the policy.

To complete this task:

1. In the Veracode Platform, select Policies > Policies.

2. Select Add New Policy.

3. Enter the name of the new policy. This policy name appears in these locations:

   • Applications list
   • Application profile
   • Reports
   • Results from the Results and Archer APIs

4. Enter a detailed description of the policy. This policy description appears in the application scan results report.

5. Optionally, to use this policy to calculate scan results that vendors share with you, select Use as Vendor Policy.

6. Select Next.

7. Add the policy constraints that you want to include in the policy.

8. Select Next.

9. Select the scan requirement frequency for either all scan types or specific scan types.

10. Select Finish.

After you successfully create the policy, the Veracode Platform displays a confirmation message.

Copy a policy

If you want to create a new policy that is similar to an existing policy, you can copy that policy and make the changes you want. Copying a policy can simplify the process of creating a new policy.

To complete this task:

1. In the Veracode Platform, select Policies > Policies.
2. Find the policy you want to copy from the Policies table.
3. From the Actions menu, select Copy Policy.
4. Edit the policy name and description and select Next.
5. Add, delete, or edit any of the policy constraints and select Next.
6. Make any necessary changes to the scan requirements and select Finish. The new policy is available in the Veracode Platform.

Edit a custom policy

You can edit a custom policy at any time. If you edit a policy that is assigned to any applications, Veracode automatically re-evaluates the applications against the updated policy.

To complete this task:

1. In the Veracode Platform, select Policies > Policies.
2. Find the policy you want to edit from the Policies table.
3. Select the Actions menu and select Edit Policy.
4. Make any necessary changes to the policy name or description and select Next.
5. Add, delete, or edit any of the policy constraints and select Next.
6. Make any necessary changes to the scan requirements and select Finish.

After you successfully edit the policy, the Veracode Platform displays a confirmation message and sends an email to members of the team associated with any applications to which the policy is assigned.

Delete a custom policy

You can delete any custom policy, but you cannot delete the built-in policies.

To complete this task:

1. In the Veracode Platform, select Policies > Policies.
2. Find the policy you want to delete from the Policies table.
3. Select Actions > Delete Policy.
4. If the policy is assigned to any applications, select another policy from the Select New Policy dropdown menu to replace it, and select Next.
5. Select Delete.

Policy constraints

The policy constraints specify the compliance requirements for applications to which the policy is assigned. You can configure these constraints when creating or editing a custom policy in the Veracode Platform or using the Policy API. The constraints are pre-defined in the built-in policies, which you can't change, but you can create a copy of a built-in policy and configure the constraints in the copy.

Rules

Policy rules define the types of findings that must not be in the application for it to pass policy. You can restrict findings by severity, CWE category, CWE ID, component, such as a library, license risk, CVSS score, or a common security standard, including OWASP, OWASP Mobile, CWE Top 25, or PCI.

General rules

The following rules apply to SAST, DAST, and MPT scans.

Rule	Description	Scan types rule applies to
Minimum Scan Score	For Static Analysis scans or Dynamic Analysis scans (must be linked to application profiles) only. Enter a value between 1 and 100. To pass policy, applications must meet or exceed the specified score value.	Static Analysis, Dynamic Analysis, and Manual Penetration Testing
Security Standard	Select one or more of these security standards: PCI, OWASP, OWASP Mobile, CWE Top 25, or CERT. To pass policy, applications must not contain any findings defined in the selected standards. If you select the Auto-Update OWASP, Auto-Update CWE Top 25, or Auto-Update CERT requirement, Veracode automatically reassesses the application when it implements a new version of that specific standard. If you select the Auto-Update PCI requirement, Veracode automatically reassesses the application when it implements a new version of the OWASP, CWE Top 25, or CERT standards. CWEs that violate security standards provides the full list of CWEs that can prevent an application from passing security standard rules in policies.	Static Analysis, Dynamic Analysis, and Manual Penetration Testing
Findings with CWE ID	Search in the CWEs table and select one or more CWE IDs. To pass policy, applications must not contain the specified CWE IDs.	Static Analysis, Dynamic Analysis, and Manual Penetration Testing
Findings in CWE Category	Select one or more CWE categories. To pass policy, applications must not contain CWEs in the specified categories.	Static Analysis, Dynamic Analysis, and Manual Penetration Testing
Findings within Scan Type	Select one or more of the following scan types: Static Analysis, Dynamic Analysis, or Manual Penetration Testing. To pass policy, applications must not contain findings from one or more of the specified scan types.	Static Analysis, Dynamic Analysis, and Manual Penetration Testing
Findings by Severity	Select the scan type options and select a severity rating. To pass policy, applications must not contain any findings that meet or exceed the specified severity rating for the specified scan types.	SCA Upload and Scan, Static Analysis, Dynamic Analysis, and Manual Penetration Testing

SCA rules

The following rules apply to SCA scans.

Rule	Description	Scan types rule applies to
Component Blocklist Enforcement	To pass policy, applications must not contain any findings from your organization's blocklist. The list of blocklisted components appears after you add this rule.	SCA Upload and Scan only
Vulnerability CVSS Score	Select a CVSS score. To pass policy, applications must not contain any findings that meet or exceed the specified CVSS score. To avoid having conflicting requirements, do not include a Findings by Severity rule for Veracode SCA findings in your policy.	SCA Upload and Scan only
Vulnerability Severity1	Select the severity rating to disallow. In the Advanced Options section, you can apply these additional configurations: Vulnerable Methods Component Dependency Fix Available Build Action Override Severity. Note: You must create a separate Vulnerability Severity rule for each set of unique inputs. The inputs are Severity, Vulnerable Method, and Component Dependency. The outputs are Build Action, Create Issue, which is automatic and not configurable, and Override Severity of the created issue.	SCA agent-based scans only
Component Licenses	Select the license risk ratings to disallow. In the Advanced Options section, you can apply these additional configurations: Specify the type of component dependency.1 Specify the build action.1 Override severity ratings.1 Disallow non-OSS licenses. Disallow Unrecognized licenses. For components with multiple licenses, require one or all of the licenses to meet the rule requirements. Allow specific licenses that do not meet the other rule requirements. (This configuration only applies to findings from Veracode SCA upload scans.) Disallow specific licenses that do meet the other rule requirements.	Both SCA Upload and Scan and agent-based scans
Component Versions1	Create issues whenever an SCA agent-based scan finds an outdated library. In the Advanced Options section, you can apply these additional configurations: Component Dependency Build Action Override Severity	SCA agent-based scans only

¹ Rules and advanced options are available after activating the Unified Policy feature.

Required scans

Scan requirements define which scan types must run, and how frequently they must run, on an application for it to pass policy.

For a custom policy, you can set a single scan frequency requirement for all scan types or set the requirement for specific scan types. On the Scan Requirements page, you can define one or more required scan types and set the scan frequency for each type. You can select Any Scan Type, or specify one or more of the following scan types: Static Analysis, Dynamic Analysis, or Manual Penetration Testing.

You can select the following scan frequencies: once, weekly, monthly (30 days), quarterly (90 days), semi-annually (180 days), annually, every 18 months, every two years, or every three years.

Veracode uses the scan frequency and the date of the first scan of the application to determine the scan due date. When an application approaches the date defined in the scan requirement, Veracode sends a notification to members of the teams associated with the application.

If you do not scan the application as frequently as the requirement dictates, the application does not pass policy until it meets the requirement. If you change the policy of the application, Veracode recalculates the scan due dates based on the date of the first scan of the application and the new scan frequency rule.

Evaluation timeframe

The evaluation timeframe defines the dates on which findings can impact the policy compliance of your applications. Findings that are opened or reopened during the evaluation timeframe can cause an application to not pass policy.

For a custom policy, you can set an evaluation timeframe to apply to findings before or after a specific date. For example, if you are starting work tomorrow to update a legacy application and your goal is to avoid adding new security flaws, you can define the evaluation timeframe as on or after the current date. In this case, new findings can cause the application to fail policy, but old findings cannot.

Evaluation timeframes do not apply to Minimum Scan Score and Component Blocklist Enforcement rules or to SCA agent-based scans.

Grace periods

A grace period is the amount of time in which your teams can fix or mitigate findings or raise the score for the application. During the grace period, the application passes policy on the condition that you fix or mitigate the affected findings or the scan meets the minimum score rule. Veracode applies the grace period starting from the first found date or, if re-opened, the last re-opened date. After the grace period expires, if you have not fixed or mitigated the findings, the application no longer passes policy. The Veracode Platform monitors grace periods as a date associated with each finding that persists across application scans.

For a custom policy, you can configure several rules for policy compliance. For Veracode SCA rules, see Apply grace periods to Veracode SCA policy rules.

If you set a grace period of 0 for a certain severity or rule, the Veracode Platform evaluates applications with findings that violate the rule immediately as failing the policy.

note

Grace periods only apply to findings that a custom rule defines as not allowed. For example, unless you have a custom rule that specifies that Informational findings are not allowed, Veracode ignores any grace period value you set for Informational findings.

When a grace period approaches its expiration date, Veracode sends a notification to the team associated with the application. When you assign a new policy to the application, Veracode recalculates the grace period due date for findings.

First found date

Veracode uses the first found date for a finding to determine whether the finding is within its grace period. To calculate the first found date, Veracode uses the following information:

Static and Dynamic findings

Date when Veracode first identifies a finding in any sandbox within an application, regardless of whether you have promoted the sandbox or evaluated it against a policy.

SCA findings

The date when one of the following events occurs:

• A Veracode scan detects a library with a vulnerability.
• A CVE for a vulnerability within a library is published in any sandbox within an application, regardless of whether you have promoted the sandbox or evaluated it against a policy.

If the vulnerable library is removed then later re-added, the first found date resets to the date the library was re-added.

Custom severities for CWEs

You can customize the severity levels of findings by giving them a higher or lower severity than the Veracode standard. Custom severities apply immediately, changing the results of the latest scan for all applications assigned to this policy.

For a custom policy, in the Veracode Platform, select Add New Custom Severity on the Rules page. The CWEs table lists the standard Veracode severity for each supported CWE ID. From the Custom Severity dropdown menu, select the new severity for the CWE ID you want to customize.

After you select Save, the custom severities appear in the Rules section on the Add New Policy page.

note

Existing applications assigned to this policy automatically have custom severity additions applied to the latest static and dynamic scan results. This change may impact policy compliance status for these affected applications.

Default policies

Set existing policies as default policies that the Veracode Platform automatically assigns to newly created applications for a given business criticality.

You can set either built-in policies or custom policies as defaults.

Set default policies for an application

This setting ensures consistent policy enforcement across all application profiles.

To complete this task:

1. Select Policies > Policy Settings.
2. For each business criticality, select the policy to be assigned to an application by default.
3. Select Save.
4. Optionally, you can subscribe to or unsubscribe from Veracode Platform notification emails related to events that impact your policies on the Notification Settings page.

Set default policies for an SCA workspace

If your organization has activated the Unified Policy feature, which replaces SCA agent rules, you can assign a default policy to SCA agent workspaces. This setting ensures consistent policy enforcement across all workspaces.

To complete this task:

1. Select Policies > Policy Settings.
2. Select the default policy to assign to a workspace.
3. To assign all existing workspaces to the selected policy, select Update Existing Workspaces on Save.
4. Select Save.

Apply grace periods to Veracode SCA policy rules

You can set distinct grace periods for each of your Veracode Software Composition Analysis policy rules in the same policy in which you define grace periods for other scan types. You can also set grace periods for specific CVSS score ranges.

note

Grace periods only apply to findings in the score range that the Vulnerability CVSS Score rule defines as not allowed. For example, if your policy disallows findings with a score of 8.0 and above, the grace periods for findings below 8.0 have no effect.

Before you begin:

For Veracode SCA findings, Veracode evaluates newly-announced vulnerabilities as new findings, so grace periods apply from the announcement date. For example, SCA Upload and Scan identifies a component on May 1 and, then, a vulnerability with a CVSS score of 8.0 is announced in that component on June 15. If you have a 30-day grace period for findings with a score of 8.0 and above, you must resolve the vulnerability by July 15 to pass policy.

To complete this task:

1. From the Rules screen in the Add New Policy page, select Grace Periods > Software Composition Analysis.

2. Select the rule types for which you want to apply a grace period. If your policy does not include a rule for the selected rule types, the grace period has no effect on your policy compliance.

   note

   To avoid having conflicting requirements or grace periods, do not include both a Vulnerability CVSS Score rule and Findings by Severity rule that applies to SCA in your policy. We recommend using only Vulnerability CVSS Score to determine the allowed severity for Veracode SCA vulnerabilities.

3. Enter the number of days to allow before findings can cause your policy to fail policy.

4. To set different grace periods for different CVSS score ranges:

   a. Select Add Another under the Vulnerability CVSS Score option to create up to five grace periods. b. Edit the first value in each score range to define the low end of the range. The high end of the first range is automatically 10.0. The high end of additional ranges is automatically 0.1 below the low end of the range above it. The low end of the last range is automatically 0.0. c. Enter the number of days to allow for each CVSS score range.

Add components to an SCA blocklist

You can create a list of third-party software components that are known to contain unacceptable security vulnerabilities. Components on the blocklist are third-party software code that the organization prohibits.

When Veracode finds blocklisted components in applications during a scan, the scan results report a scan policy violation. You can label the policy violations as mitigated or replace or fix the vulnerable component.

Before you begin:

You must have the Security Lead role.

To complete this task:

1. In the Veracode Platform, select Scans & Analysis > Software Composition Analysis.
2. Find the component that you want to blocklist.
3. In the Blocklist column, move the switch from OFF to ON.
4. Optionally, in the Blocklisted Component window, enter the remediation advice you want to provide for fixing the vulnerability.
5. Select Save.

You can change the remediation advice for any component at any time by selecting Edit at the end of the remediation advice line, and changing the text in the Blocklisted Component window.

About Veracode Levels

Veracode determines the Veracode Level (VL) of an application by the type of testing it performs on the application and the severity and types of flaws it detects. A minimum security score is required for each level.

There are five standard Veracode Levels: VL1, VL2, VL3, VL4, and VL5. VL1 is the lowest level, achieved by demonstrating that automated static or dynamic security testing is used during the software delivery lifecycle. VL5 is the highest level, achieved by performing both automated and manual testing and removing all significant flaws. VL2, VL3, and VL4 form a continuum of increasing software business criticality between VL1 and VL5.

For example, a web application tested with static analysis that has no Very High or High severity flaws and a score of at least 70 achieves VL3. To achieve VL4, you must also remediate all Very High, High, and Medium severity flaws. To achieve VL5, you must perform manual testing in addition to remediating all Very High, High, and Medium severity flaws.

There are three Veracode Levels that contain the same requirements as the Veracode Levels, plus Veracode Software Composition Analysis. The levels are denoted as VL5 + SCA, VL4 + SCA, and VL3 + SCA.

For IT staff operating applications, you can use Veracode Levels to set application security policies. You should use different VLs for deployment scenarios of varying business criticality. For example, the policy for applications that manage credit card transactions, and, therefore, have PCI compliance requirements, should be VL5. A medium business-critical, internal application could have a policy requiring VL3.

Software developers can decide which VL they want to achieve, based on the requirements they are given. Developers of software that is mission-critical want to achieve VL5. Developers of general-purpose software may target VL3 or VL4. Veracode Level can be communicated to the clients through a Veracode report.

Veracode Level requirements

The following table defines the requirements for achieving each Veracode Level. Dynamic is only an option for web applications and REST APIs.

Veracode Level	Flaw severities not allowed	Testing required	Minimum score
VL5 + SCA	V.High, High, Medium	Static, Manual, and Software Composition Analysis	90
VL5	V.High, High, Medium	Static and Manual	90
VL4 + SCA	V.High, High, Medium	Static and Software Composition Analysis	80
VL4	V.High, High, Medium	Static	80
VL3 + SCA	V.High, High	Static and Software Composition Analysis	70
VL3	V.High, High	Static	70
VL2	V.High	Static, Dynamic, or Manual	60
VL1		Static, Dynamic, or Manual

When multiple scan techniques are used, it is likely that not all testing are performed on the exact same scan. If that is the case, the latest scan results from a particular technique are used to calculate the current Veracode Level. After six months, test results are deemed out of date and no longer used to calculate the current Veracode Level.

SCA findings do not override higher Veracode Level achievements. For example, if an application contains zero Medium Static Analysis findings, but does contain Medium SCA findings, the application still achieves VL4.

Notification events

The Veracode Platform can send notifications automatically when specific policy-related events occur. Whether you receive policy notifications depends on your notification settings.

note

The Veracode Platform does not send notifications that contain sensitive information about your application, including the policy status, Veracode Level, or any other information about the application that could identify a weakness in your application or your organization.

The Veracode Platform automatically sends policy-related notifications to the team assigned to the application, to any users with the Security Lead role, and to the Business Owner email address identified on the application profile.

The Veracode Platform sends notifications for three events: policy changes, upcoming scans required, and grace period expirations.

Policy change

The Veracode Platform sends this notification when the policy for an application changes, either a new policy assignment or an update to an existing policy assignment. The Veracode Platform sends the notifications immediately when the new policy assignment or update occurs.

Upcoming scan required

The Veracode Platform sends this notification when a required scan is due in approximately 30 days, based on the schedule defined in the policy for the application. The Veracode Platform checks once a day during the night to send any Upcoming Scan Required notifications.

Grace period expiring soon

The Veracode Platform sends this notification when a finding approaches the expiration date of the grace period set in the policy. The Veracode Platform sends the notification a specific number of days ahead of the actual expiration date, on a sliding scale ranging from a day ahead to 30 days ahead based on the length of the grace period.

Setting SCA policies

You can design policies specifically for rules related to Software Composition Analysis (SCA) agent-based scans. To restrict an application from using vulnerable third-party components, add SCA requirements to your policy.

You can also assign a policy to a workspace.

Review policy adherence

ou receive includes a summary of how well the application adheres to the policies assigned to it.

To complete this task:

1. Sign in to the Veracode Platform.
2. On the Applications page, select the application name to open the application overview.
3. In the left navigation menu, under Results, select View Report. The Detailed Veracode Report opens.
4. Select the Policy Control tab. This tab lists the names and descriptions of the assigned policies and details how the application complies with the following policy rules:

• Veracode Level rule and any custom rules, including blocklist rules
• Scan requirements
• Remediation levels

Policy assessment status

When you evaluate an application against a policy, the application receives one of the following statuses.

Not Assessed

The application has not yet had a scan published.

Passed

The application has passed all the aspects of the policy, including rules, required scans, and grace period.

Did Not Pass

The application has not completed all required scans; has not achieved the target Veracode Level; or has one or more policy relevant flaws that have exceeded the grace period to fix.

Conditional Pass

The application has one or more flaws related to a policy and these flaws have not yet exceeded the grace period to fix. All sandbox scans also have this status.