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

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.

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.

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.

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.

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

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.

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.

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.