We have lots of maven artifacts for our ‘egeria’ project. We push to the oss repository, and so as part of staging for a release, all artifacts are scanned by sonatype. Our last report is at Sonatype Lift
One artifact in particular is org.odpi.egeria:firstname.lastname@example.org which shows as clean: Maven - org.odpi.egeria.repository-services-implementation - Sonatype OSS Index
Yet, when we consume this dependency within another of our projects (PR #03 Initial code commit by davidradl · Pull Request #6 · odpi/egeria-connector-repository-file-sample · GitHub ) we see a failure report
Critical OSS Vulnerability:
1 Critical, 0 Severe, 0 Moderate, 0 Unknown vulnerabilities have been found across 1 dependencies
(at-me in a reply with
Can anyone explain why this would occur. I wondered if it was perhaps due to recent CVEs found in some transitive dependencies - but it’s not clear from the error, or the scan, or a simple search on OSSIndex whether this is correct.
@nigel.l.jones Thanks for raising this. The reason is that there is currently a disconnect between Sonatype Lift, Sonatype Lift via OSSRH and OSSI. We’re in the process of moving everything over to use Sonatype’s high quality data. One way to spot this is happening is by the ID of the vulnerability, in this case SONATYPE-2021-1694. If it is a SONATYPE ID then that has been manually added by our research team
- Sonatype Lift - This is currently using high quality data that includes data inputted by our research team. This is the most accurate.
- OSSI - This is using the old “standard data” pipeline
- Sonatype Lift via OSSRH - this is currently using OSSI.
We anticipate having the new pipeline in place for OSSI next week and then everything will be aligned.
Thanks for the quick reply. Currently this scan is using the ‘sonatype-lift’ app on github where we have selected a list of repos to scan. (all public). I’m not sure which of those three this would be - presumably the first? Whilst the ossrh push on our release is the last.?
Since we are the authors of the component that is reported to have a severe vulnarability, how would we find out what that is? Obviously we can wait for next week if it becomes clearer then!
Lift is currently disabled for that repo (odpi/egeria on github) as it has a lot of code, and we weren’t ready for all the observations in the PRs, but would a scan that didn’t inject comments -at least initially - likely show the reason?
I’m not sure which of those three this would be - presumably the first?
Whilst the ossrh push on our release is the last.?
Since we are the authors of the component that is reported to have a severe vulnarability, how would we find out what that is?
Let me see if I can get the details and I’ll respond to you privately
@nigel.l.jones For the projects that you don’t want to install Lift on yet you could fork the repository and then run an on-demand analysis via the Lift console. That will give you a dependencies tab with the BOM and all of the found vulnerabilities. Not a particularly exciting example but here is one I used for testing: Sonatype Lift -- Console
Thanks for the private message with specific details. That’s really helpful. Look forward to seeing the tool improvements, and I’ll try a fuller scan on my fork. Thanks!
I wanted to followup, as I still see this behaviour, and am trying to work out how we address such issues.
For example in a recent PR at Refactor Glossary View OMAS to use generic handlers by alexandra-bucur · Pull Request #6614 · odpi/egeria · GitHub one of the observations was:
I can look at our git code scan in sonatype at Sonatype Lift – Console - but this shows vulnarabilities in modules we use. Now this includes spring - but we have a lot of modules using spring ,and not this one.
So how do we get from that dependency issue in a PR to the underlying problem so that it becomes actionable?
Is the migration still in progress?
I should add that on ossindex, our 3.9 version (last release) is ok ie Maven - org.odpi.egeria/generic-handlers - Sonatype OSS Index … but here we are using 3.10-SNAPSHOT. This will be pushed to the snapshot repo (we do this on every merge), though the build experiencing the failure is a full build which includes building this artifact …