Is Manual Remediation with Repository Health Check as Good as it Gets?

If you’re a Sonatype Nexus Repository admin, you understand the importance of keeping a repository healthy. We recently made a few changes to Repository Health Check (RHC) to help you in this quest. It now surfaces oft-used vulnerable components and gives the information you need to research and remediate those components.

Let’s talk about what RHC knows, how to remediate those components manually, and how to save a bunch of time and effort in the future by automating the research and remediation.

What does RHC know?

If enabled, RHC knows a few things about a given repository:

1. It knows what vulnerable OSS components exist in that repository.
2. It knows how many and how severe the vulnerabilities are.
3. It knows how often these components are downloaded over time.

The information above is enough to figure out which components need to be remediated. Let’s see an example of what that might look like.

How do I remediate vulnerable components?

There are a lot of ways to research and remediate vulnerabilities. The following is a common example of what this can look like for a Maven component.

I’m looking at the RHC summary report for one of my proxy repositories, and notice that several vulnerable components are listed. One of the most vulnerable components seems to be xerces:xercesImpl:2.9.1 (two vulnerabilities found).

I try to see what these vulnerabilities are about. First, I go to a public repositoryand search for those coordinates. The search doesn’t recognize the GAV format I provided, so I search using only the group name (xerces) instead.

A list of components appears, including the one I’m after. I click “all (17)”. The different versions of the xerces:xercesImpl components are listed, I click “2.9.1”.

There doesn’t seem to be any information about vulnerabilities here, though I see this version is quite old (2008). I click the back button to get back to the list of component versions then click “2.11.0” to see how old it is for comparison.

Through this website, I’ve learned that 2.9.1 is old (2008), and the newest version 2.11.0 is much newer (2013). However, I’ve learned nothing about the vulnerabilities that affect my version, and am unsure whether the latest version has resolved those problems.

Next, I go to Google to see if I can get better information. Upon searching for “xerces vulnerabilities”, I see a number of promising results, so I refine by adding the version “xerces vulnerabilities +2.9.1”.

I click what looks like the official release notes for the component and scroll down to my version (2.9.1). Nothing here is related to vulnerabilities, so I go back to my search page.

On the search page, I see another page which appears to list security vulnerabilities for xerces. Five vulnerabilities are listed, but it appears as though I have to click into each one to see version information. I open all of the vulnerabilities in separate tabs and look at them individually.

Of these, the first and fourth vulnerabilities seem to relate to my current version (2.9.1). This matches the total number of vulnerabilities that RHC told me about, so I’m pretty confident that I’ve found the correct details.

Unfortunately, it appears that the newest version of xercesImpl (2.11.0) still has those vulnerabilities, so upgrading won’t help. I’m not sure what the next course of action is. I send out an email to the developer mailing list with my findings and hope that the application owners can figure it out from here.

Your results may vary, but this is a common outcome of vulnerability research. Our security researchers at Sonatype go through a similar process when researching vulnerabilities for our own database.

This seems painful; there must be a better way

As seen above, using what RHC knows can go a long way towards keeping your repositories healthy. However, as awesome as RHC is, there are a few things it can’t do that would make your life even easier.

1. It doesn’t have a list of the vulnerabilities that affect your components (unless you have Sonatype Nexus Repository Pro).
2. It can’t contact the owners of an application that uses vulnerable components.
3. It can’t keep those components out of your software development lifecycle (build, test, deploy, etc).

In each of these cases, Sonatype Lifecycle (in concert with Sonatype Repository Firewall) can help. You can still use what RHC doesknow to do the research needed to remediate those vulnerable components, it’s just often easier to use an automated solution with better data instead.

I’d like to talk through a few of the problems demonstrated in the story above to illustrate what I mean. In each case, the problem is due to a lack of information and could be addressed with better data and automation.

1. Problem: There isn’t a version of a component that is vulnerability free, and it’s not immediately obvious what a suitable replacement would be.
   
   Solution: Sonatype Lifecycle provides recommendations when there is no path forward. In the xercesImpl example, it suggests updating Java and switching to JAXP.
2. Problem: You don’t know what applications use a vulnerable component, or who you should contact with this information, so you’re left with spamming a developer mailing list or similar.
   
   Solution: Sonatype Lifecycle or Repository Firewall would help by notifying app owners automatically, and keeping vulnerable components out of their development lifecycle.
3. Problem: The vulnerability information on cvedetails.com was actually incomplete and misleading (C++ vulnerabilities don’t usually apply to Java, and CVE-2013-4002was missing from the list).
   
   Solution: Sonatype Lifecycle data is more accurate than that found in public databases, because we vet the data manually, and fix it as needed. We also tie it to the specific ecosystem used by the component (e.g. Java) to eliminate false positives.

RHC makes it possible to manually research and remediate vulnerable components. This is a huge step forwards in helping you maintain the health of your repositories.

For some people, manual remediation is enough. That said, it can be time-consuming and frustrating, especially if the public data you’re using isn’t good enough. If you’re strapped for resources, an automated solution like Sonatype Lifecycle or Sonatype Repository Firewall might be a better fit. Alternatively, if you just want to see the full list of vulnerabilities that affect the components in your repository, Sonatype Nexus Repository Pro is a great way to go.

In either case, we hope this was a helpful overview of how to use RHC to maintain the health of your repositories. If you have questions or feedback about any of our products, please let us know. We’d love to strike up a conversation.