OSSindex shows component clean, but when used as a dependency lift scanner says severe vulnerability

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

One artifact in particular is org.odpi.egeria:repository-services-implementation@3.8 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

@sonatype-lift sonatype-lift bot yesterday

Critical OSS Vulnerability:

pkg:maven/org.odpi.egeria/repository-services-implementation@3.8

1 Critical, 0 Severe, 0 Moderate, 0 Unknown vulnerabilities have been found across 1 dependencies

Components

(at-me in a reply with help or ignore)

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.

2 Likes

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?

Correct

Whilst the ossrh push on our release is the last.?

Yep

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!

1 Like

Hi,
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?

Thanks!

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.

The PR is at git12 initial code by davidradl · Pull Request #15 · odpi/egeria-connector-hivemetastore · GitHub - does that help.

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 …

thanks!

1 Like

Responded on PR. Lets continue the conversation there

1 Like

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:

Let’s start with one pretty small and simple example, GitHub - prisma/tiberius: TDS 7.2+ (mssql / Microsoft SQL Server) async driver for rust

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.

Now where this gets weird: The parent from the screenshot is pkg:cargo/opentls@0.2.1 which we actually use in the tiberius: tiberius/Cargo.toml at 8480334a1324c26cf0975ebb12ee92313b232904 · prisma/tiberius · GitHub That component page shows 0 vulnerabilities!

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.

Now where this gets weird: The parent from the screenshot is pkg:cargo/opentls@0.2.1 which we actually use in the tiberius: tiberius/Cargo.toml at 8480334a1324c26cf0975ebb12ee92313b232904 · prisma/tiberius · GitHub That component page shows 0 vulnerabilities!

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.

You can see the dependency graphs here the Lift thinks are correct Sonatype Lift -- Console. The way Lift works for Cargo is it will first analyze the cargo.lock file. However if it doesn’t do that then it will perform a build to generate the lock file. It could be that the build Lift is doing is pulling down different versions of the dependencies (maybe because it is building on a different OS?). You could try committing your lock file to increase the accuracy.

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.

That’s it, if you replace the plain + with the urlencoded %2B the page works: https://ossindex.sonatype.org/component/pkg:cargo/openssl-src@300.0.9%2B3.0.5


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