Totally agree. Especially when the update is not a major bump of 3 versions. Most of the time it's just a minor/bug version bump. That will greatly help on the security scanners area, where the "fear" dominates the market :-)
Thanks James for the suggestion, great idea. Wadeck On Tuesday, August 31, 2021 at 3:58:38 PM UTC+2 [email protected] wrote: > Hi all, > > I would like to propose that we add to the list of eligible criteria for > backporting the following > > * is a dependency update with a known security issue > > The reason for this if we have a dependency with a security issue that is > exploitable from Jenkins we already do include that as a LTS issue via the > current SECURITY process, however if the issue is *not* exploitable then > we do not. (for example the recent XStream issues have not impacts Jenkins > as we already use an allow list). > > However as supply chain issues are becoming more prominent to our users, > they are scanning software with automated tools that look at the > dependencies, and these scanners do not understand how a library is used > or configured, and has the potential to: > > * make the software look insecure (thus be a barrier to adoption) > or > * cause extra nose asking about CVE-2021-123456 > > WDYT? > > /James > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6d65b90e-1e31-475c-b3f6-9920bb4ee33en%40googlegroups.com.
