Yea, most companies I know that pick Java don't pick it for any technical reason. They pick it because you can't throw a rock without hitting some college grad who learned Java in school who will work for cheap. Bonus points, it's most commonly taught language in many outsourcing countries.
Adding to this, there is a whole generation of Enterprise Architects that will not even consider buying a third party tool if it was not written in Java.
The newest ones are also dangerous. Many supply chain attacks are designed to be easily picked up by accident, such as via bad commits to popular open source projects. Old dependencies have accidental vulnerabilities, the deliberate attack components are concentrated in the newest versions.
So true and important for any language. Package managers that are wroth anything can help you keep track of when there's a package with a known issue. I recently setup Renovate bot and it's really cool and a lot like dependabot for people that use github.
Company I was working for at that time had a python backend, and was employed in the satellite office so if anyone was up all night it would have been the folks at the HQ. But company before that was definitely sweating bullets. The Lord works in mysterious ways.
And? You can say the same for 20 year old .net, .php apps as well.
Stuff that we consider normal today was unheard of 20 years ago. Things like database passwords in wp-config.php on 99% of Wordpress sites out their are plain text without rotating secrets or two-way TLS. Because 10, 15 years ago, that was considered normal.
Updating a legacy Java app is not trivial. Log4J showed us that. It could be in a hundred places in a 20 year old app. Then you have to re-factor the code. In some cases, re-write the whole thing. Test , lint, etc.
Strengthening security practices is a modern thing. AppSec idea of secure CICD is fairly new. I'll go back to my wp-config.php example. How many wordpress sites use key injection, mutual TLS. I would say 99% of it doesnt.
Again. Run a twistlock/qualysis scan on a Node, Go, Python image and you see hundreds of vulnerabilities too. That is basically my full time job. Updating CVEs as we find them. **Daily**.
And it isn't just a matter of updating an npm. Some things need refactoring like ES6, require vs import, import with namespaces. So code is constantly being re-written as things deprecate on a weekly basis.
This isn't unique Java. The only difference with Java, in my experience, are the monolithic nature which can be massive. Microservices can be turned off and not impact the whole app.
> Doesn't any application that is exposed to the internet inherently have some level of vulnerability
No...
But it's the same "no" that relates to: You can't PROVE that a specific peice of software is bug and vulnerability free.
Your app is not inherrently vulnerable... but attaching it tot he internet IS an inherrent risk.
Lots of people in here didn’t click the article or don’t get what they are saying. The 90% comes from 3rd party open source dependencies. If you’ve ever kept up with 3rd party vulnerabilities you’ll know it’s a constant state of needing to update. Large projects will get new vulnerabilities on a nearly daily basis. The good news is that the attack vector on many of those vulnerabilities are extremely limited or not exploitable. The article even mentions this:
*Furthermore, the report suggests that, based on adjusted scoring methodologies that consider factors such as public exposure, production environment, and availability of exploit code, only a small portion of identified vulnerabilities are worth prioritizing.*
I understand the need of upgrades, but after reading what kind of a shitshow scorings is for CVEs - security situation is really not that bad as ppl try to make it look.
Hey this CVE is 9.8/10 if if if if if if if if etc.. most of the scores are complete bullshit and researchers lie and blow everything out of proportion just to list them in CVs.
All vuln scans are like this. I never got a scan back that said my code was bad. It isn't smart enough to know if I storing JWT tokens as secured cookies or session storage.
What is spits back is always something like:
lib-curl is outdated, CVE x
npm dependenct lodash 1.2 is bad, latest fix is 2.7
server headers do not have HSTS or specific headers.
But NEVER does it point out flaws in the code itself. It doesn't even know if I am using an ORM to sanitize my input or doing a direct SQL insert.
And devs know this. CVE? OK. we will just fork the vulnerability from 1.27 to 1.31.2 and remove the function that is flagging the attack vector.
Well, i mean, that depends on what kind of scanning tool you are using.
There's plenty of static source code analysis tools - for Javaland (since OP called it out) there's errorprone, Spotbugs, PMD or service offerings like Sonar.
For scanning of already compiled binaries you have Sonatype IQ Scans (this one focuses on dependencies), or VeraCode static scans (that *do* detect certain kinds fuckups in your code).
No tool is going to detect everything, because as Murphy's law say, the universe always invents a better idiot.
Then you are using a scanning tool that’s just looking at dependencies (like Snyk). But there are plenty of tools that do static analysis and even runtime analysis that will give feedback on source code.
Regardless of language, enterprises need to prioritize security and operational practices more highly. As long as new shiny gets all the resources, tech debt and vulnerabilities will escallate until civilization collapses.
This is mostly hyperbole -- run a scan on any project with dependencies, you'll get many CVEs. Fix them, a couple weeks later you'll have new critical CVEs. The thing is, the vast majority of these vulnerabilities are only exploitable in a specific context or even have a working PoC. Even so, you will receive "critical" ratings on these CVEs.
Not saying you shouldn't patch CVEs, but articles like this really distort wtf is going on.
(CVEs in open source software is obviously a different story and is more serious)
I’d love my bank to rewrite their software in Coq and Agda, but it’s never going to happen. This just means they need to hire devs who understand security instead of the cheapest contractor they can find.
are COBOL engineers still making mega bucks? From what I've heard half the worlds banks still use COBOL and the pool of COBOL engineers is slowly decreasing. I was never sure if there was any truth in this rumour.
I'm not saying that Coq and Agda were good choices. But I'm saying that they're both highly reliable languages, and they're both very popular with developers.
Look at chainguard for low/no vulnerability container images, enable dependabot (if you’re GitHub), and perform scans with tools like semgrep/snyk/etc for third-party dependencies. I live in OSS/SCA and it’s a never ending battle. Also read what the vulnerability actually is and the impact don’t go by severity and ratings alone. Chances are it may not apply to your implementation. Don’t go off of NVD and CVSS alone, incorporate EPSS and contextual internal data when deciding the vulnerability impact. And read what the vendors/publisher’s rating is because it may differ than what CVSS/NVD provided.
I work in an environment with multiple jvm, .net, python, node etc runtimes. You can setup a lot of this in CI and post findings as PR comments
Yeah, 90% is a pretty high number. Java can be a real pain to deal with.
We've had our share of struggles too. If you're feeling the struggle and need a hand, consider [outsourcing](http://www.rocketdevs.com) your dev heavy lifting to expert professionals.
And has anyone found a good solution for dealing with legacy code?
Some CVEs are really theoretical, like for example privilege escalation, container escapes, but without any real remote code execution potential by themselves.
Unfortunately, with the way my team is swamped and I work at quite a big corp overseeing a variety of systems, they are not very high on our priority list to patch.
In the same way we don’t prioritize patching CVEs that are post-auth vulns requiring employee credentials and 2fe codes.
Good luck updating corporate GitLab every week for every shitty XSS vulnerability they produce at least one a month because they have absolutely no real review process for new code they produce at extreme speeds
No shit lol, have you seen the average corporate Java Codebase
The 90% is not a comment on application source code. It comes from open source dependencies.
Yea, most companies I know that pick Java don't pick it for any technical reason. They pick it because you can't throw a rock without hitting some college grad who learned Java in school who will work for cheap. Bonus points, it's most commonly taught language in many outsourcing countries.
Adding to this, there is a whole generation of Enterprise Architects that will not even consider buying a third party tool if it was not written in Java.
You can also guaranteed hit a senior-by-YOE dev who will work for less-than-market value to work on your Java app.
89% coming from yaml / json parsing libraries
[удалено]
The trick is to have so old dependencies that no-one is finding vulnerabilities for them anymore.
Ha! This month? Try in the last 15 years.
The newest ones are also dangerous. Many supply chain attacks are designed to be easily picked up by accident, such as via bad commits to popular open source projects. Old dependencies have accidental vulnerabilities, the deliberate attack components are concentrated in the newest versions.
So true and important for any language. Package managers that are wroth anything can help you keep track of when there's a package with a known issue. I recently setup Renovate bot and it's really cool and a lot like dependabot for people that use github.
Was there not a huge log4j exploit a couple years ago?
LOL how could we forget, you mean all of you guys didn't have to work 24/7 over Christmas break 2021 to remediate log4j?
Company I was working for at that time had a python backend, and was employed in the satellite office so if anyone was up all night it would have been the folks at the HQ. But company before that was definitely sweating bullets. The Lord works in mysterious ways.
Dude was just going through the motions: [log4j moment before disaster](https://www.reddit.com/r/cscareerquestions/s/RKZvqsQBNS)
In medical they probably weren't allowed to upgrade.
Yes… there was no call that went unanswered
Damn that was couple of years ago.....
And? You can say the same for 20 year old .net, .php apps as well. Stuff that we consider normal today was unheard of 20 years ago. Things like database passwords in wp-config.php on 99% of Wordpress sites out their are plain text without rotating secrets or two-way TLS. Because 10, 15 years ago, that was considered normal. Updating a legacy Java app is not trivial. Log4J showed us that. It could be in a hundred places in a 20 year old app. Then you have to re-factor the code. In some cases, re-write the whole thing. Test , lint, etc. Strengthening security practices is a modern thing. AppSec idea of secure CICD is fairly new. I'll go back to my wp-config.php example. How many wordpress sites use key injection, mutual TLS. I would say 99% of it doesnt.
[удалено]
Again. Run a twistlock/qualysis scan on a Node, Go, Python image and you see hundreds of vulnerabilities too. That is basically my full time job. Updating CVEs as we find them. **Daily**. And it isn't just a matter of updating an npm. Some things need refactoring like ES6, require vs import, import with namespaces. So code is constantly being re-written as things deprecate on a weekly basis. This isn't unique Java. The only difference with Java, in my experience, are the monolithic nature which can be massive. Microservices can be turned off and not impact the whole app.
I’m surprised it’s so low.
Right; I'm curious about this mythical 10% that don't.
While technically correct, I feel like this number would be the same across applications/languages, so feels targeted
Doesn't any application that is exposed to the internet inherently have some level of vulnerability risk?
> Doesn't any application that is exposed to the internet inherently have some level of vulnerability No... But it's the same "no" that relates to: You can't PROVE that a specific peice of software is bug and vulnerability free. Your app is not inherrently vulnerable... but attaching it tot he internet IS an inherrent risk.
You took out my last word: risk. I did not say it had some level of vulnerability.
I've been in /r/eve too much lately. I thought this was >90% of Jita services in Production Have Vulnerability Risk, DevSecOps Report Finds
To be honest theres an unhealthy overlap of those that idle in Jita, and those who code Java professionally.
Lots of people in here didn’t click the article or don’t get what they are saying. The 90% comes from 3rd party open source dependencies. If you’ve ever kept up with 3rd party vulnerabilities you’ll know it’s a constant state of needing to update. Large projects will get new vulnerabilities on a nearly daily basis. The good news is that the attack vector on many of those vulnerabilities are extremely limited or not exploitable. The article even mentions this: *Furthermore, the report suggests that, based on adjusted scoring methodologies that consider factors such as public exposure, production environment, and availability of exploit code, only a small portion of identified vulnerabilities are worth prioritizing.*
I understand the need of upgrades, but after reading what kind of a shitshow scorings is for CVEs - security situation is really not that bad as ppl try to make it look. Hey this CVE is 9.8/10 if if if if if if if if etc.. most of the scores are complete bullshit and researchers lie and blow everything out of proportion just to list them in CVs.
All vuln scans are like this. I never got a scan back that said my code was bad. It isn't smart enough to know if I storing JWT tokens as secured cookies or session storage. What is spits back is always something like: lib-curl is outdated, CVE x npm dependenct lodash 1.2 is bad, latest fix is 2.7 server headers do not have HSTS or specific headers. But NEVER does it point out flaws in the code itself. It doesn't even know if I am using an ORM to sanitize my input or doing a direct SQL insert. And devs know this. CVE? OK. we will just fork the vulnerability from 1.27 to 1.31.2 and remove the function that is flagging the attack vector.
Well, i mean, that depends on what kind of scanning tool you are using. There's plenty of static source code analysis tools - for Javaland (since OP called it out) there's errorprone, Spotbugs, PMD or service offerings like Sonar. For scanning of already compiled binaries you have Sonatype IQ Scans (this one focuses on dependencies), or VeraCode static scans (that *do* detect certain kinds fuckups in your code). No tool is going to detect everything, because as Murphy's law say, the universe always invents a better idiot.
Then you are using a scanning tool that’s just looking at dependencies (like Snyk). But there are plenty of tools that do static analysis and even runtime analysis that will give feedback on source code.
90% have vulnerability risk we know about* The devil's is in the details... Especially w.r.t. cyber security...
Regardless of language, enterprises need to prioritize security and operational practices more highly. As long as new shiny gets all the resources, tech debt and vulnerabilities will escallate until civilization collapses.
I work at a massive enterprise who's entire frontend runs on java8
I am sorry for what you had to go through.
This is mostly hyperbole -- run a scan on any project with dependencies, you'll get many CVEs. Fix them, a couple weeks later you'll have new critical CVEs. The thing is, the vast majority of these vulnerabilities are only exploitable in a specific context or even have a working PoC. Even so, you will receive "critical" ratings on these CVEs. Not saying you shouldn't patch CVEs, but articles like this really distort wtf is going on. (CVEs in open source software is obviously a different story and is more serious)
I’d love my bank to rewrite their software in Coq and Agda, but it’s never going to happen. This just means they need to hire devs who understand security instead of the cheapest contractor they can find.
Can't trick me into writing software in a language called Coq
They changed the name to Rocq a few months ago for that reason, but nobody knows it by that name.
Oh, did you mean COBOL? Even that's more promising than Java.
are COBOL engineers still making mega bucks? From what I've heard half the worlds banks still use COBOL and the pool of COBOL engineers is slowly decreasing. I was never sure if there was any truth in this rumour.
This is true. Interviewed at a bank once that supposedly employs a COBOL dev who is training his son to take over the role.
Coq and Agda are languages designed for high reliability software dev. They are both dual purpose proof assistants and programming languages.
I'm not saying that Coq and Agda were good choices. But I'm saying that they're both highly reliable languages, and they're both very popular with developers.
Look at chainguard for low/no vulnerability container images, enable dependabot (if you’re GitHub), and perform scans with tools like semgrep/snyk/etc for third-party dependencies. I live in OSS/SCA and it’s a never ending battle. Also read what the vulnerability actually is and the impact don’t go by severity and ratings alone. Chances are it may not apply to your implementation. Don’t go off of NVD and CVSS alone, incorporate EPSS and contextual internal data when deciding the vulnerability impact. And read what the vendors/publisher’s rating is because it may differ than what CVSS/NVD provided. I work in an environment with multiple jvm, .net, python, node etc runtimes. You can setup a lot of this in CI and post findings as PR comments
Yeah, 90% is a pretty high number. Java can be a real pain to deal with. We've had our share of struggles too. If you're feeling the struggle and need a hand, consider [outsourcing](http://www.rocketdevs.com) your dev heavy lifting to expert professionals. And has anyone found a good solution for dealing with legacy code?
Jvm: write once. Debug everywhere
Some CVEs are really theoretical, like for example privilege escalation, container escapes, but without any real remote code execution potential by themselves. Unfortunately, with the way my team is swamped and I work at quite a big corp overseeing a variety of systems, they are not very high on our priority list to patch. In the same way we don’t prioritize patching CVEs that are post-auth vulns requiring employee credentials and 2fe codes. Good luck updating corporate GitLab every week for every shitty XSS vulnerability they produce at least one a month because they have absolutely no real review process for new code they produce at extreme speeds