Resources Blog DevSecOps Delivered: Fix an Open Source Vulnerability from ...

DevSecOps Delivered: Fix an Open Source Vulnerability from within the IDE

Stefania Chaplin kicks off the DevSecOps Delivered Series on how to detect and fix open source vulnerabilities in your applications.

Hi. I'm Stefania Chaplin and as part of the DevSecOps Delivered series, I'm going to show you how to fix a critical security vulnerability within your IDE. You can see here, I have Eclipse. And if I click in the bottom on the component info tab, and make it a bit bigger, what we have here is a software bill of materials for all of the components within the application. You can see it is slightly grayed out, so that means it's a transitive dependency.

And then I have these colors. So we've got red, orange, and blue. Red means there is a critical violation of company policy and blue means there are none. If I have a look at commons collection, for example, when I click on we get all this enriched metadata, so I've got GAV, licensing, and then I've got these nine, security threat. That means that is a known and documented security vulnerability out there, and the policy is what my company thinks of it.

When I click on the view details button, what I can see is even more information.

You can see here, security high. This is an example policy that my company has set up with a high risk CVSS score. So that means a common vulnerability scoring system between zero and 10. I'm not sure if you're familiar with Heart Bleed from a few years ago. That was only a five. So anything higher than a seven is going to be even worse.

I have information around licensing, so you can see here it's liberal, but when I look at security issues, remote code execution. Now you're speaking a language that I, the developer, understand and I know I don't want to use a component that leaves me at risk of this. So how do I fix it?

Going back here to the bottom, I have this histogram. Along the bottom, version history, so one to two to the current version, 3.21. Red triangle is security vulnerability so that's a known and documented vulnerability and licensing. Blue, liberal, or I do not so get, and then green is popularity based on total downloads from Maven Central.

If I click to this version, 3.22, there's no red, blue, and still a lot of green and all of a sudden my red nines disappeared. So when I click on view details, policy violations, none. My company does not have a problem with it. Security issues, none. There are no known and documented security vulnerabilities, so this is the version that I want to use.

If I click down here on this migrate button, you can see it dynamically updates the POM from 3.2.1 to 3.2.2. I would obviously always recommend regression testing because even with a point, point-one change there may be some unknown changes and then I click on finish.

All of a sudden, this red becomes a blue, and within a couple of minutes we have fixed a critical security vulnerability within the IDE.

Picture of Stefania Chaplin

Written by Stefania Chaplin

Stefania Chaplin was a Solutions Architect at Sonatype. She was responsible for helping customers understand and implement DevSecOps across the EMEA region. Stefania has a history as a Python/Java developer and enjoys the challenge of improving the quality of software across different languages and ecosystems.