Lifecycle Best Practices; Remediation Tips, part 2

Hi, folks!

Ready to talk more about remediation? In the last post, we talked about the best-case remediation scenario. In this post, I’ll share some best practices for more tricky remediation scenarios. And in the third post, we’ll give you some tips for when remediation just doesn’t seem possible.

As an overarching best practice, make sure your developers are equipped with our IDE plugins. They provide you with meaningful intelligence, all in the context of your actual code. Make sure your developers know about the plugins. Help them become familiar with it.

The most common tricky remediation situation is to have a severe vulnerability in a transitive dependency. Why are they common? Because the web of transitive dependencies in your app can be huge! Why are they tricky? Because you (usually) don’t have direct control over transitive dependencies.

The best way to fix issues with your transitive dependencies is to upgrade your direct dependencies. Like I said last time, OSS maintainers don’t want vulnerabilities in their code any more than you. For that reason, newer versions often upgrade to better dependencies.

Another tricky situation is when there isn’t an upgrade that avoids policy violations. In these situations, you’ll need to establish some mitigating controls yourself. The best practice here is to focus on Sonatype’s recommendations from your IDE or in the Violation Details page. Our goal is to make remediation easy, so these recommendations are designed to be direct, clear, and actionable.

If our advice doesn’t solve the issue, the next best practice is to check the official website for the project, if it has one. Good OSS projects alert users to vulnerabilities and provide instructions on how to fix them. If a new, patched version isn’t available, they’ll provide mitigating controls. Sometimes, it’s as easy as flipping a configuration option on or off.

Have you done any tricky remediation recently? Struggled with a transitive dependency? Regardless of where you are in your remediation journey, I want to hear about it. I’m especially interested to hear about your IDE usage. Sound off in the comments below!

And for other resources, head to


IDE Plugin for IDEA

IDE Plugin for Visual Studio

IDE Plugin for Eclipse

Remediation Best Practices

Component Remediation in Lifecycle interactive course


I would add a shift-left suggestion here, as option 0, where you would validate the required dependency up front using lifecycle’s policy, prior to implementing a dependency in your project.


That’s a good point, Ingmar – the best way to solve policy violations is to pick good components that don’t have any! Usually that’s a job for the Chrome plugin, but there are some other ways. The key is to make sure that the act of validating is easy and contextual.

Maybe that will be our next Best Practice topic?

Out of curiosity; how do you encourage your developers to validate dependencies upfront? Are you mandating that at all?