You're importing these utilities in your Jenkins artifact, right? I'm just looking to have them updated in your project. Presumably, there are newer versions of those libraries without the vulnerabilities. I'm looking to have an updated build (Cloudbees) that uses newer, "safer" versions or removes them if they were unnecessarily imported. Does that make sense? I'm not stating that you own these libraries, it's clear they don't. I'm aware they are Spring libraries, but you're choosing to build with those specific, outdated, and more importantly vulnerable versions which are getting flagged on security scans.

We have to whitelist Jenkins because you don't have updated libraries. At the time of scan we are not installing 3rd party plugins yet either. Are you passing your own, internal security scans? Do you have specific libraries whitelisted that you can share so we can follow your examples to get the app deployed in our environment safely? However we can align would be great and easiest!

without the vulnerabilities

As I explained, these vulnerabilities are false positive findings. Your security scanner is trash.

Actually, you didn't explain they were false positives. You said they were Spring's issue, not Cloudbees. You deflected and said it wasn't your problem.

You're using Spring 2.5 or at least the time this issue was written, that's what you are using. It's clearly out of date. Rather than attacking the requestor, could you address the request? Is there an ETA for updating these libraries or Spring version? Could you maybe administer this ticket, relate it to another, possibly blocked issue to upgrade Spring? Or just address the open concern that the underlying framework is dated and if there's an ETA to do somethign about it? If you're not concerned about it - why aren't you concerned? I get you're probably tired of people asking for silly requests with little research. Apologies if this is the case, I did, at the time of writing my comment look into the maven file and libraries despite not being a developer. Heck, maybe our scanner is "trash" as you're accusing. I don't own it. I just want the problems to go away so the auditors are happy. Any help or explanation of that to make my life and possibly others better would be tremendously helpful. Thanks!

Actually, you didn't explain they were false positives

I didn't use this term, true. Still, quoting my previous response:

crypto-util is a library by the Jenkins project. The CVE points to Erlang Open Telecom Platform and is pretty obviously unrelated

and

"SpringSource Spring Framework 2.5.x before 2.5.6.SEC02…" (and you can stop reading right there)

and

the class was introduced in Spring 3.0.

You deflected and said it wasn't your problem.  … It's clearly out of date. Rather than attacking the requestor, could you address the request?

The outdated component is clearly a problem. It is however not a problem in the way you brought up – having these security vulnerabilities. I'm not attacking you, I point out that what you wrote specifically doesn't look like a problem.

As far as I'm concerned (and since you keep bringing up my employer in an unrelated issue tracker, I'm not speaking on behalf of CloudBees), it's simply a matter of effort to benefit. It's almost certain that many plugins will break and require adaptation. And "not getting false positive security scanner findings" isn't the kind of benefit I would want to see for months of effort. In fact, if the issue description is correct and we'd have to update Groovy, it would almost certainly introduce new security vulnerabilities (via Script Security).

drats, should have had more coffee... EVERYONE has a cloudbees id. facepalm - sorry for the obvious confusion on my part.

I never really expected this to be a quick thing, just hoping it would be fuel for the fire. I read the initial response as "deal with it" instead of something constructive. The issue is nearly 5 years old and it's still relevant (needing updates). So despite the months of effort, it's probably worth it to stay modern and supported across the board with various dependencies. Tech debt is just going to keep piling on. Oh well I suppose. Anyways... thanks for the insight. I'm not disagreeing with any of the above, but i'm hoping the initial response doesn't distract from the goal that there are underlying implications for not maintaining the framework. This is just one, however small.