Hi, There are lots of vulnerabilities reported which do not affect our usage of dependencies. Therefore I am still in favour of putting the responsibility towards those who build applications/distributions out of Sling bundles. For Sling Starter this is obviously us.
I would recommend to introduce some automated means (apart from dependabot) to check for vulnerabilities on all Maven projects which are not OSGi bundles. Something like https://jeremylong.github.io/DependencyCheck/dependency-check-maven/ <https://jeremylong.github.io/DependencyCheck/dependency-check-maven/> works for that use case., A new policy for not depending on vulnerable dependencies will put a lot of pressure on us, to release bundles way more often than we currently do (for no functional benefit). However, what is documented at https://cwiki.apache.org/confluence/display/SLING/Dependabot probably needs to be documented on our web site for consumers as well, so that the expectations can be managed. Regards, Konrad > On 19. Oct 2022, at 17:28, Carsten Ziegeler <cziege...@apache.org> wrote: > > Hi, > > in light of https://issues.apache.org/jira/browse/SLING-11623 I think its > worth to have a hopefully brief discussion about our dependency update policy. > > https://cwiki.apache.org/confluence/display/SLING/Dependabot captures what we > said in the past and I think this is a good guideline, keeping the dependency > at the lowest required. > > However :) with security issues in dependencies like the above, we leave all > the responsibility on our users. Clearly, we don't want any of our users to > run with known security issues, so if we update our dependencies to versions > without known issues, we help our customers as they have to update the > dependencies as well. It makes the world a little bit safer and avoids all > these continuous scanning reports. > > I'm currently torn between the two, slightly prefering to update dependencies > in case of security issues. > > Regards > Carsten > -- > Carsten Ziegeler > Adobe > cziege...@apache.org
