Within the next month, you will notice an update to your PDF reporting generated in Nexus Lifecycle. We’ve updated the report’s look and feel, as well as consolidated the report from seven to four sections to better align with IQ Server’s focus on policy-based updates.
The four new sections will look something as follows:
The report’s new structure emphasises the need to prioritize and remediate the issues most relevant to your business rather than tackling individual security issues one at a time.
The decluttered tables show what matters to organizations when archiving reports of this nature.
As a reminder, these reports do not replace the real-time data provided in Lifecycle - that can be accessed via your Lifecycle dashboard.
Where can I ask additional questions?
You can reply directly to this post. If you are not already registered to the Sonatype User Community, you will be prompted to create an account. This will empower you to create and reply to other threads initiated by both the Sonatype team and your community peers. Notifications can be easily configured to ensure you are aware of updates for a specific thread and/or important announcements within the Community.
The new report format has two differences that are problematic for our usage:
The list of Vulnerabilities includes vulnerabilities in components whose “match state” is “similar.” The Security Issues in the previous format did not include these.
The list of Components does not include the “match state” to identify what is similar like the previous format.
Together, this means that we have vulnerabilities and components that show up in the PDF report that are not applicable for the application, which confuses the person approving our deployment (who cannot access the web interface). We also need to keep this PDF report in case we are audited, so not having this information in the report can be problematic when we have to respond to an audit.
Is there a way to change this report to function like the previous version? Or perhaps just configure it to stop doing the “similar” matching and reporting? That algorithm seems to identifying completely unrelated libraries and we have other controls in place to ensure packages aren’t simply renamed to avoid addressing a security vulnerability.
The list of Vulnerabilities includes vulnerabilities in components whose “match state” is “similar.” The Security Issues in the previous format did not include these.
I have just checked the old report mechanism and I see that the SEcurity Issues list would also include components whose “match state” is “similar”. So, AFAICT this section is behaving the same in the new report.
The list of Components does not include the “match state” to identify what is similar like the previous format.
This is true that the component list no longer includes the “match state”. The component list aims to be a simple BOM for your application.
Nexus Lifecycle’s main strength is to report on policy violations and this is something that the new pdf report now also matches. Does reporting on policy not suit your needs?
This is not what I’m seeing, but it could just be a difference in what is detected as “similar.” In the older report, it only flags one “similar” library (which I don’t use). The newer one flags two such libraries (again, which I don’t use). One of them is the same as the previous one, but a different version. So, it is possible that had SonaType matched the same “similar” libraries, it would show the same vulnerabilities in both reports.
Those “similar” matches are really a problem for us as they cause extra work. We have to waive the vulnerabilities, which are false positives, and then document why they are false positives. I haven’t a clue how the algorithm works, but the two libraries it is flagging make no sense to be identified as “similar.” Is there documentation on how it works somewhere? Or better, some way to turn it off?
The problem we’re running into is that the person approving our releases knows nothing about SonaType. So, they see no policy violations but a list of vulnerabilities. They want to understand why those vulnerabilities aren’t relevant. The report does not include the waivers, so I have to provide a separate report documenting those waivers. In the old report, I could at least explain away the use of what appears to be a very vulnerable component as SonaType mistaking proprietary code for a third party library. In the new report, I can’t even do that.
In my opinion, it really isn’t a simple BOM if it includes components that aren’t actually used by the application. It is a misleading BOM, which then leads to questions and more work to answer them. The old report was much better as it identified not just the external libraries I used, but also the proprietary ones - both libraries developed in house and the actual Jars we end up deploying. That was much more useful. Showing the license in use is also quite useful.
I think what might help your use case is to claim the component. If the similar matching is finding an incorrect match you can claim this component, see The Component Information Panel
Once you have claimed the component the vulnerabilities associated with the similar match will no longer be valid (you are claiming the component as something else), therefore, the vulnerabilities will be removed from the report. In both the License and BoM section it will also correctly state the claimed component instead of the Sonatype matched similar component.
If you would like to understand a little more why the component in question is providing a incorrect similar match, maybe we can arrange a call. It could be that we have either identified a dependency that is significant (for example if it is an uber jar) or that we can refine our algorithm.
Hi Mark,
We are going to give that “claim” option a try and see what happens. It sounds like it may be exactly what we’re looking for. I’ll let you know how it goes and if it doesn’t fix our issue, I will take you up on that discussion on understanding the similar algorithm.
Thanks,
Mike
