The Veracode Platform enables you to create an application security policy against which you can evaluate and measure your applications. The elements of an application security policy include:
- The target Veracode Level for the application.
- Types of flaws that should not be in the application. You can restrict flaws by flaw severity, flaw category, CWE, or a common standard including OWASP, OWASP Mobile, CWE/SANS Top 25, or PCI.
- Minimum Veracode security score.
- Required scan types and frequencies.
- Grace period within which any policy-relevant flaws should be fixed.
Creating a Policy
Policies can comprise one or more of the following types of requirements to which an application must adhere: rules, scan requirements, and remediation grace periods. You define the requirements while creating a new policy.
To create a policy:
- Click Veracode Platform. at the top of the
- Click New Policy.
- Enter the name of the new policy. This policy name appears in the Applications list, on the Application Profile, in the Results and Reports pages, and in the Results and Archer API results for the application.
- Enter the detailed description of the policy. This policy description appears in the application scan results report.
- Select the Shared Results checkbox if you want to use this policy to calculate scan results shared with you by vendors.
- If you want to copy the rules from another policy, from the dropdown select the policy from which you want to copy and click Copy.
- From the Minimum Veracode Level dropdown menu, select the Veracode level you want to apply to the policy.
- Define the custom rules, scan requirements, remediation grace periods, and custom severities. (see below).
- Click Save.
A policy can have two types of rules: a minimum Veracode Level and one or more custom rules. To set a minimum Veracode Level for applications with this policy, choose the appropriate Veracode Level (VL1 - VL5) from the Minimum Veracode Level dropdown menu. Choosing a minimum Veracode Level automatically applies certain rules and requires scans based on the definition of the Veracode Level.To set one or more custom rules, in the Custom Rules section, select the rule type and requirement from the dropdown menus, and click Add. The types of custom rules you can add include:
- Meet Security Standard
- Choose one of several security standards (PCI, OWASP, OWASP Mobile, SANS
Top 25, and CERT Secure Coding Standards). An application with this rule in its
policy must not contain the flaws defined in the selected security standards.
For the full list of CWEs that can cause an application to fail policy rules requiring applications to meet security standards, see the CWEs that violate security standards.
- Disallow CWE ID
- Click Select Values, and choose a specific CWE ID. The CWE Values table indicates which testing techniques support each CWE ID. An application with this rule disallows flaws with this CWE ID.
- Disallow Category of Flaw
- A specific flaw category can be selected. An application with this rule cannot have any flaws in the selected category.
- Disallow Flaw Severity
- A specific severity can be selected. An application with this rule cannot have any flaws that are the selected severity or higher. For example, selecting Medium disallows Medium, High, and Very High.
- Meet Minimum Score
- A specific numeric score can be selected. An application with this rule must meet or exceed the minimum score for all scans performed.
Use the Rules section to define custom rules for an application policy.
Use the Legacy OWASP 2013 Policy Rule
If you do not want to use the latest OWASP 2017 Top 10 security standard when it is available from Veracode, you can proactively update your application security policy settings to use the legacy OWASP 2013 Top Ten standard in your policy instead. If you do not update your settings to use the legacy OWASP 2013 standard, when the latest OWASP 2017 Top Ten standard is available on the Veracode Platform, the OWASP security standard changes may impact the policy evaluation of your applications.
- Click .
- Under Custom Rules, select Meet Security Standard.
- For Requirement, select Legacy OWASP 2013.
- Click Save.
Adding SCA Rules
- Go to the Software Composition Analysis Rules section.
- From the dropdown menu, select a type of SCA rule:
- Disallow Component Blacklist
- Automatically prevents an application from passing policy if a scan detects blacklisted components. Click Blacklist to see which components are on the blacklist.
- Disallow CVSS Score
- Automatically prevents an application from passing policy if a scan detects any vulnerability with the specified CVSS score or higher.
- Disallow Vulnerabilities by Severity
- Automatically prevents an application from passing policy if a scan detects any vulnerability with the specified severity or higher.
- Disallow Component by License Risk
- Automatically prevents an application from passing policy if a scan detects any license with the specified license risk rating.
- Click Add.
Adding Components to a Blacklist
When reviewing the components that comprise a software application, you can add any component that contains an unacceptable vulnerability to the blacklist. You must have the Security Lead role to add components to the blacklist.
- Go to .
- Find the component that you want to blacklist, and in the Blacklist column, move the switch from OFF to ON.
- Optionally, in the Blacklisted Component popup, you can enter the remediation advice you want to provide for fixing the vulnerability.
- Click Save.
You can change the remediation advice for any component at any time by clicking
Edit at the end of the remediation advice line, and changing the
text in the Blacklisted Component popup.
In the Scan Requirements section you can define one or more required scan types and set the scan frequency for each type. Choose either Any Scan Type, or specify Static, Dynamic, or Manual Penetration Testing Scan Types.
Possible scan frequencies include Once, Weekly, Monthly (30 days), Quarterly (90 days), Semi-Annually (180 days), or Annually.
When a periodic scan frequency is selected, the team and business owner of the application receives a notification prior to the next required scan date. An application is non-compliant if it is not scanned by the chosen type of scan(s) as often as is dictated by the selected scan frequency. The exception to this compliance rule is when you first create a new application. A new application is conditionally passing (compliant) until all of its scans have run for the first time. The only other reason an application is conditionally passing is during its remediation grace period.
Remediation Grace Periods
In the Remediation section, you can define a remediation grace period for each possible flaw severity, and/or for the application score. A remediation grace period is time that allows developers to fix or mitigate flaws or raise the score for the application. During the grace period, the application is considered to pass the policy on the condition that the affected flaws are fixed (or mitigated), or the score is increased and verified before the grace period expires. Grace periods are tracked as a date on each flaw and persist across application scans.
Setting a grace period of 0 for a certain flaw severity or for the score rule means that an application with flaws of that severity are immediately considered not passing the policy.
When a grace period has been established, a notification can be sent to the team of the application when the grace period is nearly elapsed.
To change the Veracode default CWE severity, in the Custom Severities section, click
Add Custom Severity. Select the checkmark next to the CWE(s)
you want to change, and select the custom severity from the dropdown menu. Click
Editing a Policy
You can edit a policy at any time. When making changes to a policy that is assigned to one or more applications, the application is automatically re-evaluated against the changed policy. A notification can be sent out to the business owner and/or the team responsible for the application when the policy is updated.
To edit a policy:
- ClickPolicies at the top of the screen.
- Click the name of the policy to be edited in the Policies list.
- Make the changes to the policy.
- Click OK.
- If the policy is assigned to any applications, a confirmation dialog appears. Click Continue to save the policy and send a notification; click No thanks to save the policy without sending a notification.
Deleting a Policy
You can delete any policy that is currently not a default policy. When a policy that is assigned to one or more applications is deleted, those applications revert to the default policy.
To delete a policy:
- Click Policies at the top of the screen.
- Click the name of the policy to be deleted in the Policies list.
- Click Delete Policy.
- A confirmation dialog appears. Click Continue to delete the policy.