For ‘Egeria’ we are seeing a number of vulnarabilities reported that I can’t explain - we’ve still got Nexus IQ running (as we move to lfx) and they are not picked up there, but maybe this tool is better.
One example report is:
In the build.gradle I don’t see any direct reference to logback.
I ran a gradle build scan (from our project top level) with ./gradlew --scan -x test -x javadoc
This scan is published to Build Scan™ | Gradle Cloud Services
The source is from GitHub - odpi/egeria-docs: Documentation repository for the Egeria project.
If I go to the offending module, there is no reference under the compileClasspath.
Under runtime we have two references to logback, but both are at later, fixed versions - and as expected are annotated as ‘constraint’ — this means it’s fixed based on the top level gradle constraints (like the pom’s dependencyManagement)
ie
ch.qos.logback:logback-classic:1.2.11
constraint
ch.qos.logback:logback-core:1.2.11
constraint
As such I can find no evidence at this level (dependencies) of us having a vulnerable, older logback.
Any thoughts on why this would be reported - what might I be missing?
2 Likes
I’m seeing similar reports on maven (we build with both maven and gradle).
For example a report on a dependency with a vulnarability, yet not one we use according to ‘mvn dependency:tree’ ?
Is the scan just looking at artifact dependencies? I had wondered if it was also trying to look at jar files, or even classes - though I’ve yet to find any offending such file yet.
1 Like
I also took a look on the snyk forums. This suggested running gradle dependencies -q. This doesn’t work well for multi module projects (we have 100s) run from root, but run in the relevant subdir, the output demonstrates that we are correctly constraining the logback versions to fix this vuln ie:
➜ graph-repository-connector git:(master) gradle dependencies -q | grep logback
| +--- ch.qos.logback:logback-classic:1.2.11 (c)
| +--- ch.qos.logback:logback-core:1.2.11 (c)
| +--- ch.qos.logback:logback-classic:1.2.11 (c)
| +--- ch.qos.logback:logback-core:1.2.11 (c)
| +--- ch.qos.logback:logback-classic:1.2.11 (c)
| +--- ch.qos.logback:logback-core:1.2.11 (c)
| +--- ch.qos.logback:logback-classic:1.1.3 -> 1.2.11
| | +--- ch.qos.logback:logback-core:1.2.11
| +--- ch.qos.logback:logback-classic:1.1.3 -> 1.2.11 (*)
| | +--- ch.qos.logback:logback-core:1.1.3 -> 1.2.11
| | +--- ch.qos.logback:logback-classic:1.1.3 -> 1.2.11 (*)
| | \--- ch.qos.logback:logback-core:{strictly [1.2.9, 2[; prefer 1.2.10} -> 1.2.11 (c)
+--- ch.qos.logback:logback-classic:1.2.11 (c)
+--- ch.qos.logback:logback-core:1.2.11 (c)
| +--- ch.qos.logback:logback-classic:1.2.11 (c)
| +--- ch.qos.logback:logback-core:1.2.11 (c)
| +--- ch.qos.logback:logback-classic:1.2.11 (c)
| +--- ch.qos.logback:logback-core:1.2.11 (c)
| +--- ch.qos.logback:logback-classic:1.2.11 (c)
| +--- ch.qos.logback:logback-core:1.2.11 (c)
| +--- ch.qos.logback:logback-classic:1.1.3 -> 1.2.11
| | +--- ch.qos.logback:logback-core:1.2.11
| +--- ch.qos.logback:logback-classic:1.1.3 -> 1.2.11 (*)
| | +--- ch.qos.logback:logback-core:1.1.3 -> 1.2.11
| | +--- ch.qos.logback:logback-classic:1.1.3 -> 1.2.11 (*)
| | \--- ch.qos.logback:logback-core:{strictly [1.2.9, 2[; prefer 1.2.10} -> 1.2.11 (c)
+--- ch.qos.logback:logback-classic:1.2.11 (c)
+--- ch.qos.logback:logback-core:1.2.11 (c)
So this still looks like bad scan reporting?
1 Like
Welcome to the community @planetf1
I believe the scan is looking at your upstream dependencies that are being pulled down steam by your repos. @pranab.bajpai and @David_Deal work with LFX Security and maybe they can help further advise you here.
@pranab.bajpai or @David_Deal do you have any additional insight regarding this?
1 Like
@planetf1 which repository are you asking about? You reference odpi/egeria-docs above. This repository shows 0 open vulnerabilities.
@planetf1 can you clarify the:
- repository
- manifest file (build.gradle file) within the repository
Hi, thanks for the reply.
The repository is GitHub - odpi/egeria: Open Metadata and Governance - apologies for pasting the wrong link above.
The manifest for this error is open-metadata-implementation/adapters/open-connectors/repository-services-connectors/open-metadata-collection-store-connectors/graph-repository-connector/build.gradle
This is just the first error I was looking in to - we have a series of other ones which I need to check through, but one step at a time 
Before diving in too deep, allow us to rescan the project top-to-bottom, it’s been >1month since we last scanned (we are working to fix/update the scanning interval to 1 week).
1 Like
Hey @planetf1 upon looking at your Enrgia repository GitHub - odpi/egeria: Open Metadata and Governance as mentioned in LFX Security here:
I was able to find the vulnerability manifest file in your repo by following the path described in LFX Security here:
Did you check to ensure the build.gradle in this repo was up to date? It could also be you were looking in the wrong path.
Could you check to make sure the build here is up to date?
egeria/build.gradle at master · odpi/egeria (github.com)
@planetf1 I think to prevent possible confusion over the dependency manifest file location it will be a good idea to make the ‘repo manifest file’ an active link in LFX Security.
What do you think?
@David_Deal and I sent this feature request in to the LFX Security team.
I hope this helps, let us know if you were able to update the file, to remediate the vulnerability
Thanks for suggesting making the path to the gradle file a link - that’s a useful usability improvement.
On the manifest file itself - the build.gradle, I don’t see an issue with it. We have constraints defined in our top level build.gradle which forces dependency resolution, including of the transitive dependency, to a version later than that which the vulnarability is reported in.
I pasted some output towards the top of the thread in 2 ways
- a gradle build scan
- output from gradle dependencies -q locally
Both show that later versions of the dependency are indeed being used - and that the constraint is being respected.
So I think it’s a false positive report, and there is no remediation to be done.
When I look at the list of issues overall I think this applies to some others too, so it feels to me as if the scan is in error.??
Ah! Just read this note about the scan being a month old.
Can we get the date of last scan shown on the report more clearly?
That being said, our constraints on this dependency were in place over a year ago at levels greater than that being reported, so I don’t think (unless there are other issues) a 1 month old scan is the cause…?
But that all being said, agreed it would be good to get the scan updated as a starting point to further discussions. Thanks.
1 Like
Rescan looks clean[er] now - I don’t see any entries for the above-mentioned Gradle build file from the vendor report. Give the LFX Security backend some time to finish processing the job (all repos for Egeria), recalculate the project results/stats, and allow the caches to expire.
2 Likes
We recommend running Snyk and BluBracket as part of your normal CI/CD process as well.
@David_Deal Thanks re: rescan. Will revisit that when updated - in day or so
On regular CI/CD we’re currently using:
- Nexus IQ (via azure pipelines, originally setup by LF) for CLM/dependencies/license. Kinda works but clunky UI. We’re currently comparing results with LFX… with hope to stop using IQ
- SonarCloud for static code analysis — but it doesn’t integrate well with PRs, and so Mandy developers mostly ignore it as it’s async to the pr process
- CodeQL (github) - this actually works well as it’s tightly integrated. It’s found many bugs, and we’ve fixed some. So developers (including me) see code issues reported in PRs, and get a chance to fix. Not great for reporting though. I don’t see LFX yet is doing general code scanning
- we had a play with ‘lift’ and still have it active on some JavaScript repos, but it was a bit noisy and not so well integrated so no longer in use for main repos.
- snyk - also tried this via cloud service, but we blew the free tier limits too quickly. Also the UI was quite tedious to navigate with 100s projects, so we stopped… until snyk is revisited via the LFX UI. And you have it licensed? Presume if we scan ourselves we won’t use a LF license?
I’ve not come across Bluebracket — but I would guess we’d also blow the free tier. Do LF projects get any access to licenses to run elsewhere in ci/cd (ie github actions)?
Many thanks
The new scan no longer had these issues. I was able to work through the ones reported and address most of them.
Would it be possible to request a new scan @David_Deal (only ‘egeria’ was updated)?
I expect to still see a netty() report - which I don’t think will affect us but I’ll double check, but most should be gone.
1 Like
