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

Technical Documentation