Security policy constraints

The policy constraints specify the security requirements, such as scans that must be run on the application, the minimum scan score the application must receive, or specific severities of the findings that the application must not have. The application must comply with these requirements to pass the policy.

You can configure these constraints when creating or editing a custom policy in the Veracode Platform or using the Policy API.

note

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.	Container and IaC, 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. You can manually add components found using SCA Upload and Scan to a blocklist.	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.	Container and IaC, SCA Upload and Scan
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 Scan 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 SCA Agent-based Scan
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 Scan only

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

Required scans

Scan requirements define which scan types, such as SAST and SCA, 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.

Include SCA vulnerabilities in your policy

Restrict an application from using vulnerable third-party components by adding policy constraint requirements to your security policy. You can also enforce that the application must not exceed maximum CVSS scores or license risk and must meet grace period requirements to pass policy.

If you add an SCA policy rule to a policy already assigned to applications, the Veracode Platform recalculates their policy compliance status. This change can cause applications that we haven't rescanned to change from a passing status to a failing status.

To complete this task:

1. To add SCA findings in your policy, create a custom policy or edit an existing custom policy.

2. In the Rules section, add one or more of the following SCA rules.

   • Component Blocklist Enforcement
   • Component Licenses
   • Vulnerability CVSS Score

3. Set the grace periods to apply to SCA rules.

4. Finish creating or editing the policy.

Apply grace periods to SCA policy rules

You can set distinct grace periods for each of your SCA 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.