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
- Import in 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 results 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.