Application security policies

You can define and enforce a uniform application security policy across all applications across your entire application portfolio, including applications you develop and third-party applications. You can use built-in Veracode policies or create your own custom policies to enforce the security rules of your organization.

These are the tasks for configuring and enforcing policies:

1. Create custom policies or select built-in policies
2. Configure policy constraints
3. Set default policies
4. Set a policy for an application
5. Review policy adherence

Security policy elements

The elements of an application security policy include:

• Target Veracode Level: the Veracode Level the application must meet to comply with the policy.
• Restricted findings: findings that must not be present in the application. You can restrict findings by severity, CWE category, CWE ID, license risk, CVSS score, or by standard, including OWASP, OWASP Mobile, CWE Top 25, or PCI.
• Minimum security score: the lowest Veracode security score an application can have and still comply with the policy.
• Component blocklist: a list of open-source components that are not allowed, based on Veracode SCA findings.
• Required scan types and frequency: the types of scans and how often they must occur to meet policy requirements.
• Evaluation timeframe: the period during which findings can impact policy compliance.
• Grace period: the amount of time you have to fix policy-related findings before they affect compliance.

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

You can also manage policies with the Policy API.

note

You are not required to create custom policies because the Veracode Platform provides built-in policies that you can use when implementing your security requirements.

Policy constraints

You can apply the following policy constraints: rules, required scans, evaluation timeframes, and remediation grace periods.

Evaluating applications against a policy

When you evaluate an application against a policy, the application receives one of these four assessments:

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.

Setting SCA policies

You can design policies specifically for rules related to Software Composition Analysis (SCA). For more information, see Include SCA findings in policy.

Include SCA findings in policy

You can restrict an application from using vulnerable third-party components by adding Veracode Software Composition Analysis (SCA) requirements to your policy.

You can also assign a policy to a workspace used for SCA agent-based scans.