Skip to main content

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


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


  • 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.