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 |
|
License Obligations |
|
Architectural Rules |
|
Other |
|
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.