Security policy constraints
The policy constraints set the compliance requirements for one or more applications. You apply the policy to all, or individual, application profiles. To pass a security policy, the applications must comply with the following constraints.
You can configure these constraints when creating 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.
| Rule | Description | Applies to Static Analysis, Dynamic Analysis, and Manual Penetration Testing scans | Applies to Software Composition Analysis (SCA) scans |
|---|---|---|---|
| Minimum Scan Score | Enter a value between 1 and 100. To pass policy, applications must meet or exceed the specified score value. | X | |
| 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. | X | |
| 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. | X | |
| Findings in CWE Category | Select one or more CWE categories. To pass policy, applications must not contain CWEs in the specified categories. | X | |
| Findings within Scan Type | Select one or more of these 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. | X | |
| 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. | X | SCA upload scans only |
| Component Blocklist Enforcement | To pass policy, applications must not contain any findings from your organization blocklist. The list of blocklisted components appears after you add this rule. | SCA upload scans 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 scans only | |
| Vulnerability Severity1 | Select the severity rating to disallow. In the Advanced Options section, you can apply these additional configurations:
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:
| Both SCA upload scans 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:
| SCA agent-based scans only |
1 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.
Remediation grace period
A remediation grace period is the amount of time in which you 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. Veracode monitors grace periods as a date associated with each finding that persists across application scans.
For a custom policy, you can configure the Minimum Scan Score, Component Blocklist Enforcement, Component Licenses, and Vulnerability CVSS Score rules. You can also specify grace periods by severity that apply to Findings by Severity, Security Standard, Findings by CWE ID, and Findings in CWE Category rules.
If you set a grace period of 0 for a certain severity or rule, Veracode evaluates applications with findings that violate the rule immediately as failing the policy.
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 apply a new policy to the application, Veracode recalculates the grace period due date for findings.
For Veracode SCA rules, see Apply grace periods to Veracode SCA policy rules.
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
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 of the Add New Policy page.
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.