Hi, I agree to Eric, that we should try to reduce the noise of security scanners, which just scan build-time dependencies instead of runtime dependencies, as in most java projects they are identical. Here in the OSGI world these versions can be different and in reality often are. I also see Julian's position about testing against old versions of dependencies; IIRC I had that case once that all unit tests passed on a bundle, but during runtime functionality failed, because a newer but compatible dependency had a minimal change in semantics. We would have detected that behavior in the unit tests if we would have had the dependencies updated.
For that my +1 to change the policy and encourage people to update dependencies to the oldest version with no known vulnerability. Am Fr., 22. Nov. 2024 um 03:58 Uhr schrieb Eric Norman <enor...@apache.org>: > Hi, > > In light of SLING-12492 at [1] and the related PR and discussion at [2] I > think it would be worthwhile to have a vote about our dependency update > policy for dependencies with known security vulnerabilities. > > 1. https://issues.apache.org/jira/browse/SLING-12492 > 2. > > https://github.com/apache/sling-org-apache-sling-scripting-javascript/pull/3 > > > *History / Background:* > > The wiki at [3] captures what we said in the past and remains a good > guideline for dependencies with no security concerns. Also, the last time > this topic came up there was a discussion at [4] that ended with an > inconclusive outcome so please review that thread as well. > > 3. https://cwiki.apache.org/confluence/display/SLING/Dependabot > 4. https://www.mail-archive.com/dev@sling.apache.org/msg122053.html > > > > *The Proposal:* > Security scanning tools are regularly flagging sling projects as > "vulnerable" due to direct dependencies on other libraries that have known > security vulnerabilities. These security reports can result in obscuring > "real" security problems due to all the noise that we could clean up by > changing our approach to such things. > > Basically, the proposal up for a vote is whether we should encourage > updating the versions of dependencies to be the oldest compatible version > that does not have known security vulnerabilities. This should resolve the > concerns being identified by the security scanning tools and still ensure > that our bundles are deployed in the widest possible range of "secure" > environments. > > Please vote to approve this proposal: > > [ ] +1 Approve the proposal > [ ] 0 Don't care > [ ] -1 Reject the proposal, because ... > > This majority vote is open for at least 72 hours. > > Regards, > Eric > -- https://cqdump.joerghoh.de