The CLM Book - Optimized Component Lifecycle Management with Sonatype CLM
Perhaps one of the most disconcerting experiences with Sonatype CLM, is scanning your application for the first time, and seeing a huge number of critical security vulnerabilities indicated on the Summary tab. It can be a sobering experience, and in some ways it should be a little worrisome. More importantly though, it should create motivation for further investigation.
The key word there being investigation. That’s because even though we’ve provided accurate data, you still need to have a process to review all available data, and then track your progress. It is not completely uncommon, and quite possible that a vulnerability doesn’t apply to your application or, at the very least, isn’t a concern given the particular application you are developing, and it’s relative exposure points. Where do you start your investigation though?
The component list on the Security Issues tab (see example displayed in Figure 4.20, “Security Issues Tab”) only shows components that have a security vulnerability. In addition, when a component has multiple security vulnerabilities, it is displayed multiple times.
There are a total of four columns: Threat Level, Problem Code, Component, and Status. Initially the list of vulnerabilities is ordered by the Threat Level column. However, you can sort the list by any other column by simply clicking on a header.
While the Threat Level and Component columns should be self-explanatory, the two other columns, Problem Code and Status, deserve a bit more explanation.
- Problem Code
- The Problem Code column provides a link to available details for the security vulnerability on the CVE and OSVDB web sites. This information is provided via the CVE and OSVDB security information sites, and is managed independently of Sonatype CLM data. These public security databases allow you to get quick information about the security issue and nature of the vulnerability.
- Status
- The Status column allows you to track the state and progress of research of the effect of a security vulnerability with respect to your application. We’ll focus on the Status column in a bit more detail when we cover the CIP. A key point to remember, is that as long as the status is set to Open, Acknowledged, or Confirmed, the vulnerability will be included in the counts on the summary page. In addition, a policy with a condition related to the presence of a security vulnerability will be met, as long as the status is set to Open. That means it’s very important to research these issues, so that only those affecting your application remain.
To access the CIP as displayed in Figure 4.21, “Component Information Panel (CIP)”, simply click on a component row in the list. There are three sections you should use during your security vulnerability investigation - Component Info, Edit Vulnerabilities, and Audit Log.
- Component Info
- One of the first things you should notice in the Component Info section, is the Highest Security Threat. This field, located on the left side of the panel, displays the highest threat and the threat value (on a scale of 1-9). In addition, it will display the total number of security issues for that particular component.
- Component Graph
- Next, you should take a close look at the graph to the right of the panel. On the graph, locate the Security Alerts field, taking into consideration the other fields as well. This graph will display security vulnerabilities by version, with the current version identified as This Version. In some cases there are clear points where security issues have been resolved, as can be seen above. Often this tends to coincide with more popular version, although, that is not necessarily always the case.
There are two ways to edit the status of a component vulnerability. We cover both below.
- Via the CIP
-
After clicking on a component row to display the CIP, click the Edit Vulnerabilities section.
Here, the left side will display all violations sorted by the Threat Level for the selected component. If you desire you can also sort by the Problem Code or the Status. You should also notice that there are check boxes next to each security vulnerability. This allows you to set the status for multiple vulnerabilities.
To the right of the list of security vulnerabilities is the status drop down and a comments section. There are four statuses available:
- Open
- the default status, represents no research being done.
- Acknowledged
- represents that the security vulnerability is under review.
- Not Applicable
- indicates that research was conducted, and the particular vulnerability does not affect the application.
- Confirmed
-
demonstrates research was conducted, and it has been determined the security vulnerability is valid and applicable.
To change the status simply select one from the drop down, select the vulnerabilities the status will apply to, enter any associated comments, and finally, click the Update button. It is important to mention the status can be changed to any status at any time.
- Via the Grid
- If you want to make edits to the security vulnerability status for multiple components at the same time, simply use the list and select the checkbox next to each component. Then, click the Edit button and select the appropriate status. If necessary, enter information in the comments area.
The condition Security Vulnerability present/not present considers all statuses, except Not Applicable to be a present security vulnerability. The same is true for the count of security vulnerabilities on the Summary tab.
When a status for a security vulnerability is changed, the change, as well as any corresponding comments, will be recorded in the Audit Log. While there are no requirements to enter comments, it is a good idea, to enter something in case of a future review or an internal audit being required. At the very least, the changes in status are tracked.
In some cases, just because there is a security vulnerability, that does not necessarily mean there is a corresponding policy violation. For this reason, it’s important to refer back to your Policy tab as well. If you are finding that critical security issues you are troubleshooting do not show up as a policy violation as well, you may need to refine your policy so that future security issue trigger a policy violation and thus ensure that they get your attention.
Security issues can be scary, there is really no way to deny that. However, as with all things, fear can be leveled by knowledge and understanding. The more you know, the more you will understand and the less you will fear. So, here is what you should have picked up from our section on Security Issues:
- Accessing the Security Issues tab.
- Reviewing security vulnerabilities and the threat.
- Changing the status of a security issue.