Hi,
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
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?
@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 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?
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 …
We had a similar issue with Hadoop-common - this is different as it’s not ours, but it’s odd that the sonatype lift PR annotation is reporting lots of issues, whilst OSSindex reports it’s clean.
How do we correlate/understand what the issues are here so we can mitigate
How about the issues we have with our own Egeria packages - how do we know the cause, and as the code owners, do something about it?
@nigel.l.jones Can you send us a link to the comment? Lift is doing a build so can look at transitive dependencies as well, where as OSSI only reports vulnerabilities against the dependency the vulnerability was found in. That might be influencing what is happening here.
There are a number of issues reported in dependencies - some are in ours (org.org.egeria:* ) others in , for example, hadoop-common . I don’t fully understand why in either case …
I think I might be observing something similar, although not in a PR (yet, we just installed Lift) but in our main results in the Lift Console (and in other Sonatype reports customers are sending us). For me it is in Rust repositories:
We have a reported vuln in pkg:cargo/openssl-src@111.22.0%2B1.1.1q. While Cargo - openssl-src - Sonatype OSS Index exists and shows a vuln for the version, the version pages (all of them) only report a 404.
That is also one of our open source packages - and it does not actually use openssl-src! opentls/Cargo.toml at main · prisma/opentls · GitHub All it’s openssl dependencies are not on the absolute newest versions, but non of them show any vulnerabilities in OSSIndex.
This is just one example, we have another Rust project quaint that we use in GitHub - prisma/prisma-engines: 🚂 Engine components of Prisma 2+ - and both the crate itself as also our engines repository get a critical vulnerability reported on this dependency that we are not really using.
Now to add on top of that a bit, the vuln description and CVE do not actually match openssl-src itself, but some other software: (see screenshot above)
My random idea right now: Is this a local OpenSSL package that is pulled in by these OpenSSL related dependencies from the machine that runs these checks, and somehow misreports them as security problems?
exists and shows a vuln for the version, the version pages (all of them) only report a 404.
This appears to be a bug in OSSI. I’ll file a ticket and pass it on to the product management team to prioritize. I wonder if it is related to the “+” in the url.
This is the same nuance that Nigel was running into. OSSI only displays the vulnerabilities for the exact component you are viewing. It isn’t aware of the whole component tree (mainly because the tree can change depending on how you configure your build). Lift does a build so will see the full tree. See my explanation here for more detail: https://github.com/odpi/egeria-connector-hivemetastore/pull/15#discussion_r927631926
That is also one of our open source packages - and it does not actually use openssl-src ! opentls/Cargo.toml at main · prisma/opentls · GitHub All it’s openssl dependencies are not on the absolute newest versions, but non of them show any vulnerabilities in OSSIndex.
Now to add on top of that a bit, the vuln description and CVE do not actually match openssl-src itself, but some other software: (see screenshot above)
I’d need to confirm but this most often happens because the Sonatype research team have found the same vulnerability in another package (possibly because the code was copied). I haven’t checked this yet but will do.
Is this a local OpenSSL package that is pulled in by these OpenSSL related dependencies from the machine that runs these checks, and somehow misreports them as security problems?
Yep it very well could be. Committing the lock file should rule this out.
Thanks a lot for the rest of your answer, but I am still unclear how to fix our problem honestly.
We are getting reports from customers that Sonatype is reporting vulnerabilities in our code, that we do not understand and have no idea how to fix. OSSIndex is showing a vulnerability as long as we are looking at our package, but as soon as we click into the dependency that sits between us and the vulnerable package - the vulnerability disappears. Checking the real dependencies of both our and the other packages, shows not relation to the reported vulnerability.
This for example is not an option, as this is not a real dependency we can control via a lock file. The only hunch we have is that it is actually a local package installed on the system, that somehow is identified to be part of our dependency tree. (It is a bit like if a Windows 10, version xyz vulnerability would be attributed to our software when we run the security scan on that Windows version xyz.)
sonatype-lift bot yesterday
