While doable for Java, I don't really see the case here. I mean, if you have a program searching your disk for older versions of openvpn so that it can use it and exploit its vulnerabilities... then you already have a malicious piece of code running in the first place, so it doesn't have to look for vulnerabilities.
Look, I'm not saying that the library should never get updated. But you always need to consider the risks, such as
- the risk that the old library contains a vulnerability
- the risk that this vulnerability affects your particular usage of that library
- the risk that the new updated version contains a newly introduced vulnerability
- the risk that you break something during the integration of the new library, causing a completely different vulnerability or simply a malfunction.
...
The last point here is significant. You are concerned about the particular library not being the latest version - OK, I get that. But if we take a library update one day old (just an example) and put it into our release the next day - now that is something you should be concerned about, because that would be irresponsible (and likely to cause more harm than good).
The risks have been considered here - we fixed the real important issue by including a new version of OpenSSL library. We believe the other changes in that library are not important for us at the moment - i.e. that it would be more risky (less secure) to include them than not. Delaying the update release to thoroughly test all the other changes would also be more dangerous - and it would leave the users unprotected from the OpenSSL problem (and other unrelated issues the program update has fixed) longer.
Yes, maybe we should have changed the name/version of that executable to make it clear that it's not the virgin vulnerable copy PSI is reporting, but something else...