Skip to main content

Policy Enforcement Best Practices

Policy action and enforcement parameters are rules that you set so that Lifecycle knows how to effectively deal with component policy violations occurring in your applications and repositories. Some approaches are better than others, of course. Sonatype has collected a list of the best practices for policy action and enforcement that have proven to be very effective for our most successful customers.

Enable continuous monitoring to regularly check for violations

  • Turn on the continuous monitoring feature to ensure your legacy and highest-priority applications are regularly checked for new violations.

  • This is one of the easiest and best things you can do to continually monitor applications that are not in active development or that are not built regularly.

Have a remediation plan in place to quash vulnerabilities efficiently and effectively

  • Create a remediation plan to reduce your organization's risk with open-source components.

  • Preparation and proactivity put you one step ahead when there is a vulnerability detected.

  • Instead of wasting precious time wondering what to do, your team will already be in action mode thanks to a thoughtful and previously socialized plan.

Analyze your metrics based on your organization's priorities and goals

  • Care about your metrics and use them to your organization's advantage.

  • Use your organization's metrics to benchmark continuous improvement and to monitor the value you're returning.

  • The degree to which an organization can share and make visible its metrics is a sign of a mature organization that reflects good process alignment.

Map and align your policy action/enforcement with the software development lifecycle/workflow

  • Design your policy action/enforcement so that it follows your software development lifecycle.

  • Having enforcement in place that corresponds with your software development workflow places quality gates in and around the flow of artifacts.

Strive to stop builds for specific threat levels...but only if you can deal with the disruption

  • Follow the practice of more mature organizations and stop builds for 9-10 threat levels – or, better yet, for 7-10 threat levels.

  • Automatic enforcement of your governance policies during builds should be an organization's ultimate goal.

  • However, it must be executed only when the organization's developers are able to handle the ensuing disruption.