Reference Policy Best Practices
Reference Policy Best Practices
Baseline your applications using the reference policy that comes with Lifecycle
Around 90-95% of our customers use the default reference policies out-of-box as they are a solid indicator of open source risk.
The reference policies are organized into 4 main categories listed below.
| Policy category | Details |
|---|---|
| Security Risk | - security policies aligned with the NIST National Vulnerability Database. - including Sonatype's exclusive identification of release integrity and namespace conflicting components |
| License Obligations | - Sonatype's legal team has reviewed each license for business-critical obligations - they are organized licenses into threat groups by legal obligations |
| Architectural Rules | - components flagged for cleanup or poor quality - including Sonatype exclusive hygiene rating |
| Other | - details around component identity or matching - proprietary or unknown components |
Customize policies to match your existing open-source governance practices
Around 90-95% of our customers use the default reference policies out-of-box.
Most variations are to better align with pre-establish governance policies or to prioritize specific architectural risks.
Rather than deleting the default policies, we recommend scoping them to an unused application category to make them easier to restore later.
Use application categories to create specific policies for a subset of your applications
Your applications may have different levels of risk aversion due to regulatory requirements or exposure.
Create and manage policies at the root organization while using application categories to scope them to these applications.
Turn on enforcement to block security-malicious components at every lifecycle stage
Malicious components should never be allowed in your applications.
Set your policy action to FAIL at all stages of development.
Do not waive these violations nor allow the components to remain in your application.
Sign up for Sonatype's policy workshop
Partner with a Sonatype Customer Success Engineer to design your open-source governance policies.
Our Customer Success Engineers will get your team up to speed with open-source governance best practices.
During the workshop, you will amend the reference policy based on your organization's needs and goals.
Modifying Policies in Production
Importing policies to a production instance is very destructive
All policy elements use internal IDs for violations, waivers, license threat groups, and component labels.
Importing policies will break any references to these IDs and destroy your governance data.
Only import policies into new instances.
Avoid deleting the reference policies
Replacing the reference policies later can be time-consuming and difficult.
Change the policy scope to an unused Application Category instead.
You can just change the scope again when you need it back.
Avoid creating multiple policies for the same risk
Multiple policies for the same threat result in wasted effort for your developers.
Reduce the noise by first testing complementing or competing policies in a test environment.
Frequent changes to policies will result in noisy violations and poor metrics
Adding and removing policies will pollute the metrics used to measure your efforts.
Appearing and disappearing violations will frustrate your developers; leading them to ignore future results.
Avoid making multiple changes to the policy in production environments.
When you must make a change, temporarily suspend notifications and socialize the expectations beforehand.
Document policy changes to production to later explain strange peaks and dips in metrics.
Making changes to a policy may reset the waivers associated with the violation
Waivers are scoped to the policy constraints at the time the waiver was created.
Changing enough of the policy's constraints may trigger a new violation not covered by the waiver.
Where possible, review changes to the policy in a test environment before enabling them in production.