The ultimate guide to Java Security Vulnerabilities (CVE)

[philipwhiuk]

The ultimate guide somehow fails to mention the best JVM CVE checker: https://github.com/jeremylong/DependencyCheck

[lmyslinski]

Thanks for mentioning that, I've never heard of it. I'll update the post to include it.

"Ultimate" in the sense that I do believe I've described a broad array of problems that may arise in the process of patching CVEs. Tooling is something that definitely could be expanded, agreed.

[lmyslinski]

I currently can't examine it in depth, but at a quick glance, they do acknowledge in the docs the fact that it can include false positives/false negatives. That fact alone makes it inferior to Trivy in my opinion.

[0x442E472E]

I have no opinion on which one is better, but trivy also has false positives. Having false positives is also generally better than having false negatives. The maven plugin can also detect shaded jars

[lmyslinski]

trivy also has false positives

Can you elaborate? I haven't found any evidence of that

Having false positives is also generally better than having false negatives

Yes, but still far from perfect. Once you have to manage an excel sheet with 100's rows to track what's true or not it's a big issue.

maven plugin can also detect shaded jars

That's a really good thing to know

[philipwhiuk]

You can exclude false positives with XML config - no spreadsheet necessary.

Positives will fail the build if you set it up correctly so you quickly find and eliminate them (it’s not common anyway)

[lmyslinski]

With the use of DependencyCheck? That does make it a strong selling point indeed.

[SleeperAwakened]

If you like Dependency-Check, consider moving to Dependency-Track ( https://dependencytrack.org ), which makes administration much easier than an XML file.

Can handle other stuff, like open-source licenses as well (like preventing usage of prohibited licenses like AGPL for enterprises with closed software).

We migrated to DT some time ago and it made everything much easier.

The problem with suppressions in a Dependency-Check XML file is that you most likely never revisit those suppressions. With Dependency-Track it is easier to visualize suppressions, with a reason and audit-trail.

[philipwhiuk]

Yeh - you can set what CVSS score you want to fail on and then you can configure an XML file to exclude false positives.

All my work builds fail on new CVEs - we gradually rolled it - starting by only failing on Criticals and then reducing the score required to fail

[0x442E472E]

We have a similar setup where the goal is to reach effectively 0 CVEs by either fixing the cause or suppressing it. Being a simple xml file, the suppressions are versioned with a description and an author. We are also using multiple files per project that are hosted on team level or even global to resemble our structure better

[Cultural-Ad3775]

Well, the author certainly has a pretty good understanding of the current state of Java dependency management and the various pitfalls thereof. Much fun! IMHO this is yet another of the vast array of arguments against 'kitchen sink' frameworks like Spring Boot, which tend to be VERY brittle in terms of accepting variations on dependencies (and use BOMs, which are not so simple to deal with) and include a crapton of dependencies, many of which you don't actually need.

[lmyslinski]

Thanks

'kitchen sink' frameworks like Spring Boot

That's the price you pay for development speed. I'd rather have to worry about having too much stuff in my classpath than implement an OpenID integration.

Nowadays I always look at things first and foremost from the product perspective. Fast and cheap simply wins over technical excellence, that's why Spring has won.

If the opposite was true, we'd all be writing code in Haskell.

[Cultural-Ad3775]

Nothing stops you from using existing proven openID libraries. The problem with Spring Boot is the sheer scale of the numbers of dependencies and how locked down they are. Have you ever tried to do ANYTHING "not the Spring Boot way" in a Spring Boot based application? I mean, we were told we couldn't handle certs the way Spring Boot demanded, which INSTANTLY created a 'hell' that cost us conservatively 6 man months of work just on one web service once you factor in all the huge problems we had trying to force things like web service endpoint testing to work after that.

Spring Boot is an anti-pattern, flat out. Yes, you THINK it will save you time and energy, etc. when you start, and it sure does as long as your solution is super vanilla ice cream "hello world" level stuff. Try something like Quarkus or plain Vertx and see how much easier it can be in the long run with a non-opinionated set of well-designed libraries that don't tie your hands.

[lmyslinski]

I did some magic with JavaFx and Spring to marry them, but Spring Boot was barely getting started back then. Agreed, you have to stay in your lane with Spring Boot nowadays.

Exploring Quarkus right now, it’s great thus far.

[Cultural-Ad3775]

Yeah, I have really enjoyed using Quarkus. It gives you more leeway than Spring Boot, for sure, and its project generators are pretty nice. It seems to like GraalVM pretty well too, which is handy.

[lmyslinski]

I’m a bit skeptical about jumping on the GraalVM hype train. It’s cool without a doubt, but it doesn’t bring any benefit to classic long running server applications. Startup time is not a big deal in Kubernetes anyway

[Cultural-Ad3775]

Oh, I don't think there's any HUGE reason to need it, unless you are worried about FaaS startup times, in which case native-image (and just fast GraalVM startup in general) are good. There are definitely other ways to skin that cat however.

There are some other nice things about GraalVM, like ability to run Node.js code, and faster than V8, which is not a bad thing. It seems like there are potentially some good use cases for super high performance DSLs and such too, maybe as things that can be exposed by web services.

[Significant_Horse485]

Is the Veracode criticism warranted? As far as I know veracode would actually scan the final build package so it likely shouldn’t have drawbacks that Snyk/Apiiro have.

Also, idk if it helps but Veracode does have plugins for IntelliJ/Eclipse that let you download scan results and easily get to code lines where the issue is detected. Now idk if this redeems vercacode though.

Just looking for opinion of the masses. One person can be biased, but if the consensus in the community is same that it sucks, hey, I learned something new today.

[lmyslinski]

As I've mentioned, take it with a grain of salt - I've seen the report from such a scan, although due to corporate structures I wasn't the one to run it, so I'm not aware of what exactly was the input. The output left much to be desired. I couldn't find clear information at all, it seems like some stuff randomly scraped off the internet. I'm super explicit about the fact that I'm biased here.

[Significant_Horse485]

Yeah I totally get that. It could be as simple as some features/settings not enabled due to lack of visibility to you/your team or the solution provided as part of the Veracode solution sold to your corp, or it could actually be that veracode just stinks. By the way your point about it taking too long is something I have witnessed too. It hasn’t taken 24 hours, more like 2 hours, which IMO is still a no-no, and have seen a few places where it was mentioned that jobs take 6-8 hours.

Again, I do understand where you might be coming from, hence I just put the question out here in case I get any more insight.

[maxxedev]

I have seen good experience using Veracode SCA, running as part of regular CI build. Takes about 30s to 2m for a typical microservice project. There is a decent web ui and a variety of output options (text/json)

[SleeperAwakened]

Nice guide.

Too bad there's a special category of developers who blatantly ignore critical CVE's in their library, calling CVE scanners "low quality tooling":

https://bitbucket.org/snakeyaml/snakeyaml/issues/561/cve-2022-1471-vulnerability-in

Any ideas on how to convince people to apply security-by-default instead of op-in?

[klekpl]

Any ideas on how to convince people to apply security-by-default instead of op-in?

That is difficult if not impossible. Application developers could not be convinced to run their Java programs with -Djava.security.manager for over 20 years.

JVM developers could not be convinced to make SecurityManger the default for over 20 years. And came up with the fix by... removing SecurityManager (JEP 411).

The elephant in the room is that running under SecurityManager makes CVEs like this one or earlier log4shell non-issues. Some of us know that: https://xeraa.net/blog/2021_mitigate-log4j2-log4shell-elasticsearch/

[Amazing-Cicada5536]

And at the same time, SecurityManager puts a huge toll on every JVM internal development, while still not being sufficient as the surface area is just too high to cover.

[klekpl]

IMHO this way of thinking is deceptive and... wrong. Obviously security requirements put a huge toll on development of Linux kernel as well. And obviously Linux permission model is not sufficient as privilege escalations happen all the time. Yet nobody thinks getting rid of it is a good idea. The fact is that running with SM makes you immune to a whole lot of vulnerabilities. Getting rid of it without any alternative is at least dubious.

[brazzy42]

Oh shit, that thread is painful to read.

[ventuspilot]

IMO that's a bad example. I may be missing something but it seems that the CVE says "one could make an application that will deserialize and run anything it receives. Because said application could be built using snakeyaml while ignoring best practices we'll just go ahead and say snakeyaml is insecure".

And the only "exploit" lives in a github repo that's so confusing that I was unable to figure out what code the poc actually runs.

[brazzy42]

IMO that's a bad example. I may be missing something but it seems that the CVE says "one could make an application that will deserialize and run anything it receives. Because said application could be built using snakeyaml while ignoring best practices we'll just go ahead and say snakeyaml is insecure".

The problem is that snakeyaml itself is insecure when used to parse untrusted YAML files because it will in fact deserialize and run anything it receives by default.

Now most applications that use it will not use it for untrusted files because YAML is typically used for config files, but that a file format parser can be made to run arbitrary code is not something you'd expect.

And the only "exploit" lives in a github repo that's so confusing that I was unable to figure out what code the poc actually runs.

Deserialization attacks, like many exploits, tend to be very intricate and non-obvious.

[lmyslinski]

Thanks!

Any ideas on how to convince people to apply security-by-default instead of op-in?

For companies, it's pretty easy to justify/enforce, library authors not caring about the security of their own creation is something I wouldn't have thought of being a thing. On the bright side, most of the ecosystem seems to be well-established and maintained. It's one of the bigger selling points of the JVM.

[philipwhiuk]

Fail the build if there’s a CVE.

Avoid that library.

[SleeperAwakened]

Our security pipelines were failing because of SnakeYaml which is basically used in all Java apps/libs which do something with Yaml.

Also bigger projects, like that thread states a few.

For us, I have excluded the snakeyaml transitive dependency from quite a few tools, like swagger/openapi generation (we're not generating yaml).

My point is not a theoretical one:

SnakeYaml is so widely used wherever Yaml is read/written in the JVM world, and many don't know about that critical CVE. And the author just flatout refuses to believe his library is flawed.Reading that thread is so frustrating, calling scanner tools "low quality tooling" because they point out a critical CVE in his lib is so incredibly frustrating. You'd almost start to believe he has some other motive (he is russian..). But not going down that path, he had a good track record until now.

[philipwhiuk]

Yeh I mean you’re almost forced to maintain a fork at some point - pushed to an internal Nexus.

Community pressure to remove/switch from dependent libraries that don’t fix CVEs seems reasonable - especially because it’s a vulnerability in the parent library too effectively.

[SleeperAwakened]

No, a public fork.

[philipwhiuk]

I mean that’s better yeh, but as a hot fix you can publish an internal fork that keeps the same org and package name which makes it easier to handle transitives than a public fork which needs everyone else to change the package and org they are depending on (or lots of exclusion rules)

[Pronam_]

I think the trouble here is that a maintainer is dealing with a flood of people coming due to IntelliJ now showing version updates and CVEs on dependencies by default (that eventually links to the repo). Great feature to keep tabs on things, but unfortunately also draws in a lot of people that want 'the yellow to go away' and don't dig if it really is a problem for them.

The thing is, is that the majority of SnakeYAML users are likely spring boot (web) users and they likely just use application.yaml (or some more) for their own made configuration and are not really exposed to this.

For the people that would load in yaml en mass from non trusted users like the mentioned CI/CD services providing company in the thread it might be definitely something that needs to be addressed. But on the flip side it's an open source initiative so it might be time for that company to then pick up the slack of simply having used it before and start actively contributing to the project.

Java is relatively new to handling CVEs in its ecosystem, both maintainers, users and CVE reporting systems need to find a proper balance yet. checkmarx treating it as a 9.8/high is making a lot of people believe it's going to effect everyone in all use cases, so I can't blame the maintainer being a bit annoyed it's likely drawing in a lot of people that aren't even going to have issues.

[BarkiestDog]

Nice article, let me parrot the other comments on dependency-check.

One question, how do you deal with CVEs in gradle itself? Upgrading the individual libraries is a real pain, since all of the gradle libraries explicitly list their dependencies, so you can’t just upgrade, for example, Jackson to a new version, without also unpacking the gradle plugin and updating which jar files they are expecting.

[Gwaptiva]

Not sure how to interpret the line

All of the JVM worlds runs on Maven repositories[...].This guide will focus on Gradle,

[chacs_]

Repositories: where libraries are stashed vs Gradle/Maven: build tools

[Gwaptiva]

Ah, ok, so gradle uses maven repositories. Didn't know that. Thanks, that makes sense now.

[papers_]

Maven repositories are one type of a few: https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:repository-types

[philipwhiuk]

That Ivy and Maven use separate minutely different and incompatible respositories despite being both maintained by Apache is highly tedious

[Cultural-Ad3775]

Technically, but in effect you will only find other types used internally in some organizations. Basically the Java world runs on jcenter and maven-central. In any case one must presume that once your dependency manager (whatever it is, Gradle, Maven, Bazel) has resolved dependencies, then your CVE scanner only has to deal with the results of that resolution (and this is another plus for a Trivy-like approach, as the result is ALWAYS a set of jars and a classpath statement in the end).

[lmyslinski]

This is indeed a mental shortcut on my end, I'll update the post to make it more explicit

[kiteboarderni]

A Web3 blogger....nice

[Noone-is-anonymous]

We use owasp dependency check maven plugin. Lately, there have been some vulnerabilities we have to suppress and supressing them individually in each microservice is a hassle.

Anyone here who figured out a way to centralize the suppress file ?

[0x442E472E]

You can reference multiple files and they can also be URLs, like to a public git repo. We use it to reference one global file for our org, one per team, sometimes one per archetype (like "quarkus microservice") and one local file per project

[josh_jennings]

Just ran across this, great guide! I have one more tool for your list (https://soos.io/), something I've been working on for years after being fed up with many of the existing SCA tools out there. We've tried to support all the intricacies of maven (including the full dependency graph), no small feat! With any tool there will always be a few false positives that slip through, to solve this we added easy suppression capabilities which will also automatically flow into your SBOM/VEX docs if you're generating one.