I have a war file that was created using CF2018 with all patches applied. This war file was then submitted to a company named Veracode for a static security scan. The results stated that there were over numerous jar files with what they rated as Very High to Medium vulnerablities. They included jar files such as jackson-databind-2.8.8.jar, tika-core-1.21.jar, bcprov-jdk15on-153.jar, jetty-io-9.4.12.v20180830.jar and xercesImpl.jar. I also tried this on a patched CF2021 instance with similar results. I obviously cannot just go into the cfusion/lib and replace these jar files with updated versions. Does ColdFusion really have that many vulnerablities? Any suggestions on how to deal with this would be greatly appreciated.
It certainly has that many old jars, and as you say there's essentially nothing we can do but wait for Adobe to address them. They tend to drag their feet unless there's some urgency, so what you CAN do now is file a bug report about this, with those details, as they may not respond here. (Sometimes they do.)
If you DO file such a report (at tracker.adobe.com), please then share the ticket/url here, so others sharing the concern can add votes and be notified as Adobe or anyone responds there.
This is of course a larger problem than just this current situation. There really needs to be greater care and attention to ensure that such old libraries aren't allowed to linger for years, as has happened. Yes, it's a challenge, since cf includes SO many libraries and some DO intertwine. But with more and more attention being paid by orgs to ensure that apps deploed in their environments are updated and secure, it's long since time for Adobe to step up on this, or explain why they do not.
I have a slightly different take on this than @Charlie Arehart although he is not wrong about the outcome. The problem with CF 2021 is the problem with any modern, mature enterprise software. It includes lots of things! Things that presumably people asked for at some time. Those things cause code dependencies. I think it's unrealistic to expect that a product is always going to use the very latest versions of each possible library, when all of those libraries have to be tested with someone's old production CF app.
Dave Watts, Eidolon LLC
But yeah, there's a LOT that's sad about the state of old libraries within CF, as I started out with in my longer comment.
To be clear, it's not as simple as "they should just offer the latest version" of everything they embed. They need to do substantial testing, and then deal with compat issues--which may become multiplied when one lib may somehow relate to another. The factorial permutations probably leave them feeling stuck.
But you're not wrong to complain. And at least with any one lib (like this jetty matter), sometimes it's just a matter of getting them to pay attention to it. Sad that it may take that approach, but CF is indeed a large monster. The new modular design of CF2021 (with the freedom to include packages/modules or not) only goes so far in addressing this issue.
But I also stand by what I'd said in my other reply here, above. Both sentiments can be held at once, or depending on what someone else may have said. Just as they have a balancing act in managing cf, we have one in managing our replies here. 🙂
Dave thanks for your reply. My concern is not with the age of the jar file or it not being the latest version but with the fact that a scan has identified them as having a security vulnerability. For example the scan results given show very high and high vulnerablilities for jackson-databind-2.8.8.jar which is causing us to fail the scan.
Yeah, I understand that concern. But, can anyone actually execute that security vulnerability? If your security scanner just looks at the names of the files on your filesystem and sees "jackson-databind-2.8.8.jar", you'll fail the scan, but it's not clear that CF would allow unsafe code to be sent to it in the first place. So, my recommendation is that in the short term, you try to execute a test case against it - which might be fairly hard - and tell your security people that it's a false positive if your test case doesn't trigger the vulnerability.
I realize this approach is less than optimal, to say the least. But it might be the best you can do, and it might delay the resolution for the failed scan.
Dave Watts, Eidolon LLC
Charlie - thanks for your response.