It would be nice to have a document summarizing our upgrade policy has we get requests to upgrade that we have to decline and motivate. Using a reference to a wiki page would be easier and more comprehensive.
Also, describing the scope of what having dependencies management here means will be useful to set expectations. A typical example is #15979
Comment From: mathieufortin01
One of these policy should probably be a security one, ie upgrading (or not!) dependencies with known vulnerabilities above a certain "score". In that sense, has there been any attempt/motivation to include a dependency checker into (or beside) the build process ?
Comment From: bclozel
@mathieufortin01 anything specific in mind? We already have a process in place, I'm just not sure what you're referring to.
Comment From: mathieufortin01
Im referring to an automated process to detect known vulnerabilities both in currently defined dependencies (which would trigger a dependency upgrade), and in more recent ones (when deciding to upgrade).
Maybe this should go into the bomr project ?
Regarding this issue (document the upgrade policies), is there any documentation for the current upgrade process that is in place ? I could come up with a draft document highlighting the policies I can deduce from the Bomr project and other sources. But a formal documentation of the process would help.
Comment From: bclozel
Where would we get the security vulnerability issue data? How would we map that to our own dependency management? Wouldn't it like building our own vulnerability scanning product?
We got quite a few issues coming from such commercial tools on this issue tracker and many of them were false positives, as they offer often a quite limited picture of the vulnerability (like the exact artifact or the conditions to trigger the vulnerability). We're part of the Pivotal Security team and we've got a direct line with many OSS projects, so I'm wondering what would be the benefit here.
Comment From: mathieufortin01
Where would we get the security vulnerability issue data? How would we map that to our own dependency management? Wouldn't it like building our own vulnerability scanning product?
Not at all. Wouldnt tools like owasp dependency checker (nvd database) work in this context ? My idea was to have vulnerabilities indicators added to the list of potential upgrades when running the Bomr tool. The tool already supports prohibiting certain libs, and already supports some policies (same-minor|major-version). Adding other policies or more info to the report, like vulnerabilities summary, seems natural.
The benefit is quite clear, but i understand that managing false positives can outweight the benefit.
But... I think this discussion probably went beyond the original intent of the issue.
Comment From: wilkinsona
This is now covered on the wiki in the team practices page: https://github.com/spring-projects/spring-boot/wiki/Team-Practices#third-party-dependency-upgrades