Resolving Security Issues

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

In order to see policy violations that are due to security issues, use the Policy Type filter in the sidebar to filter to only Security policies.  From there, more details about what caused the violation can be observed by opening the CIP for a given violating component.

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 InfoVulnerabilities, 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 Issue: 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.

Any changes to security vulnerabilities are visible only when the application is re-analyzed (via the re-evaluation button or a new evaluation being triggered from CI, CLI, policy monitoring, etc).

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 the Policy Violations Table 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 issues trigger policy violations and thus ensure that they get your attention.