+1 probably we should flesh out which "security scanning tools" we are referring to - GitHub/Dependabot immediately accessible for us.
updating to latest dependencies not affected by security issues should bring more benefit than harm in my pov, and we should not only limit it to 3rdparty dependencies. stefan > -----Original Message----- > From: Eric Norman <enor...@apache.org> > Sent: Friday, November 22, 2024 3:58 AM > To: Sling Developers List <dev@sling.apache.org> > Subject: [VOTE] Proposal to revise the policy for updating dependencies > with known security vulnerabilities > > 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
