Resolving Security Issues

Evaluating your application for the first time, and seeing a huge number of critical security vulnerabilities indicated on the Summary tab 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?

Security Issues

The component list on the Security Issues tab only shows components that have a security vulnerability. If a component has multiple security vulnerabilities it is displayed multiple times.

There are a total of four columns: Threat LevelProblem CodeComponent, 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 are self-explanatory, the Problem Code and Status columns deserve a bit more explanation:

  • 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. These public security databases allow you to get quick information about the security issue and nature of the vulnerability.
  • The Status column tracks 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.

The Component Information Panel (CIP)

To access the CIP, simply click on a component row in the list. There are three sections you should use during your security vulnerability investigation - Component Info, Vulnerabilities, and Audit Log.

Component Info

One of the first things you should notice in the Component Info section is the Highest Policy Threat.  This field, located on the left side of the panel, displays the highest threat level policy that has been violated, as well as the total number of violations.

Next, you should take a close look at the graph to the right of the panel. On the heatmap, locate the row for Policy Threat. This graph will display the highest policy threat levels for each version across all policy types, with the current version identified as This Version. A breakdown of the highest policy threats for each policy type can be displayed by clicking on the Details link. In some cases there are clear points where Security policy threats 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.


After clicking on a component row to display the CIP, click the Vulnerabilities tab.

Here, the left side displays all security vulnerabilities. Depending on how many, this list may scroll. The list is organized into four columns:

Threat LevelIndicates the threat assigned to the security vulnerability and is determined based on the source. This is not associated to any policy threat level.
Problem CodeThis is the unique identifier of the security issue as assigned by the source (e.g. CVE-2000-5518). It will change depending on the source of the data.

Sonatype provides information from public sources, as well as information from our own research team. Clicking on the information icon in the corresponding row displays additional details provided about the issue.


The status of the security issue as assigned by the drop down to the right. See below for information on changing this status.
To the right of the list of security vulnerabilities is the status drop down and a comments section. 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. After you click the Update button, any Status Comment you entered will be cleared, but is saved and visible in the Audit Log. It is important to mention the status can be changed to any status at any time. 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.

Updating the status of the security issue requires the "Edit IQ Elements" permission.

Matching to Violations

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 Violations 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.