Best Practices for Mend SCA Policies
The following article is meant to describe common practices that are used to successfully implement Mend SCA policies.
Naming Convention
When reviewing Policy Violation alerts (alerts created by policies with the action Reject), the main field used for interpretation is the Description field, which displays the respective policy's name.
It is therefore important, when configuring your policies, to assign them with meaningful, self-explanatory names, so that it's easy to understand from within the report what was the reason for each of the libraries' violations.
Using match type, action, and scope prefixes
In the following example, each policy is identified by its match type, the action type, and it also includes the scope (Global, Organization, Product, Project), so it's easier to determine why it was a violation in a given context.
The [License] prefix is required at the start of the policy name for it to be interpreted in a repository integration.
Policy Names
[License] [Reject] [Org] Block CopyLeft Licenses
[License] [Approve] [Project] Allow CopyLeft Licenses - Internal Application
Action Items
Mend tasks are no longer recommended since communicating with developers via an issue tracker is the preferred way to assign violations for review and remediation. Due to this workflow, Reassign and Conditions actions are no longer recommended and all policies should either be a Reject, Approve, or Issue action.
Policy Actions
Designing Your Policy Scheme
Compliance Policies
Manage by Exception
When designing your compliance policy scheme, work with your legal advisor to devise a list of license types to be rejected at the organization level. Reviewing and approving every library & license that enters an organization is not a scaleable solution and puts an unnecessary workload on the legal team. Teams should request exceptions to the reject policy by one of two ways
An individual with Alert Ignorer access should ignore the policy violation alert
An individual with Product Administrator access should create an Approve policy action at the [Project] level that negates the reject policy
Multiple Licenses
When multiple licenses are detected for a library its recommended to choose the effective license for this library which will apply at the organizational level.
License Compatibility
Since license compatibility is analyzed at the [Product] level, it is recommended to group projects into a single [Product] similar to how the application would be packaged and deployed to comply with license regulations.
Security Policies
It is recommend to use the repository integration to enforce security policies through branch protection rules and the Mend Security Check that occurs on a valid push. This does not require any setup of policies within the Mend UI and allows both Security and Compliance Policies to coexist.
If you are running scans within the pipeline and without the repository integration then it is recommended to only configure Reject Compliance policies.
Policy Order
Mends policies are executed in the order they appear on your Policies page on a per library basis. Once a policy condition is met for a particular library, it executes the policy's action and stops processing the rest of the policies for that library. It is important to organize your policies according to the level of importance and to use only one policy per level so that they do not conflict.
For example, if you wanted to configure the following policies
[License] [Reject] Block CopyLeft Licenses
[License] [Approve] Allow CopyLeft Licenses - Internal Application
[License] [Approve] Allow Permissive Licenses
[Security] [Issue] Review Critical Vulnerabilities
The correct order would be:
[License] [Approve] [Project] Allow CopyLeft Licenses - Internal Application
[License] [Reject] [Org] Block CopyLeft Licenses
Security policy rules should be configured with the repository integration instead of the policy engine. Approve policies should only be used to provide exceptions for Reject policies that are enforced at a higher level.