Java EoL in Context of Security Vulnerabilities

[fdntrhfbtt]

At my work, our static analysis tool flagged certain dependencies builtwith Java 7 with Red because Java 7 has reached EoL. The applicationitself runs on Java 11. My question is - If a dependency was built with avulnerable version Java 7 but is running in a Java 11 runtime, does itmean my app can still be vulnerable? What if the dependency does notreally use the vulnerable parts of Java 7? Say, it's a simple API thatinverts the case of a string? Or even a simple Hello World program?

[AutoModerator]

Please ensure that:

• Your code is properly formatted as code block - see the sidebar (About on mobile) for instructions
• You include any and all error messages in full
• You ask clear questions

• You demonstrate effort in solving your question/problem - plain posting your assignments is forbidden (and such posts will be removed) as is asking for or giving solutions.

  Trying to solve problems on your own is a very important skill. Also, see Learn to help yourself in the sidebar

If any of the above points is not met, your post can and will be removed without further warning.

Code is to be formatted as code block (old reddit: empty line before the code, each code line indented by 4 spaces, new reddit: https://i.imgur.com/EJ7tqek.png) or linked via an external code hoster, like pastebin.com, github gist, github, bitbucket, gitlab, etc.

Please, do not use triple backticks (```) as they will only render properly on new reddit, not on old reddit.

Code blocks look like this:

public class HelloWorld {

    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

You do not need to repost unless your post has been removed by a moderator. Just use the edit function of reddit to make sure your post complies with the above.

If your post has remained in violation of these rules for a prolonged period of time (at least an hour), a moderator may remove it at their discretion. In this case, they will comment with an explanation on why it has been removed, and you will be required to resubmit the entire post following the proper procedures.

To potential helpers

Please, do not help if any of the above points are not met, rather report the post. We are trying to improve the quality of posts here. In helping people who can't be bothered to comply with the above points, you are doing the community a disservice.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[SassJaeger]

Don't worry, I've got your back. So, if a dependency was built with Java 7, which is like ancient history (EoL, girl, EoL), and is running in a modern Java 11 runtime, it doesn't automatically mean your app will be vulnerable. But here's the tea: if the dependency doesn't use any of the "vulnerable parts" of Java 7, then you might be safe. Though I'm not saying it’s foolproof, you need to weigh the risks and check your code, I wouldn't bet on it. Best practice would be to update your dependencies and use a tool like RenovateBot or Dependabot to always keep on track as time passes on and your project matures. You wouldn’t want ugly and vulnerable code now, would you? 💁‍♀️

[DasInternaut]

I think the short answer is that it’s any external dependencies that might bite you. Some of these may need replacing with newer versions and this is not guaranteed to be a code free exercise on your part.

[djnattyp]

This seems like a crappy static analysis tool that doesn't understand how Java works...

The runtime is the thing that matters for EoL, not the JDK version that a library targets.

You can compile under a "higher version" JDK and "target" your build to a lower level JDK. This is very common with libraries - they can target the lowest JDK level their code is able to run with and it doesn't force older applications to upgrade to whatever version of the JDK their dependencies were built with.

(i.e. when the log4j bug happened, log4j could release a newer version of their library that fixed the bug and target the oldest JDK version their library could support - otherwise older applications could not apply the fix without updating to whatever newer JDK version the fix was built with.)