Hi Christopher, On Thu, 10 Oct 2024 at 18:14, Christopher Schultz <ch...@christopherschultz.net> wrote: > • Canned responses to issues (?) > • security.txt > • Dedicated security team (secur...@project.apache.org) > ◦ Reduce security@ and private@ where appropriate/possible > • Create and document detailed incident response > ◦ Including key contacts and contact information > • Disable inherently insecure features > • Documented release process > • Documented security / threat model(s) > • Reproducible builds > • Automated release process > • SBOMs > • Harden CI workflows (?)
Nice list, might I add another item we recently briefly discussed on Slack[2]: * introduce minor branches with long term security support (and nothing else). Since making any upgrade of a dependency can always break something (e.g. the bugs or implementation specific behavior you are relying on), many companies don't upgrade until it is necessary. This is of course a risk, since those missed upgrades will hit them all at once, when a CVE is published. The problem can be solved with LTS branches that only receive critical and security updates, as advocated by OpenJDK in JEP[1]. Right now users decide themselves, which version of a library they will be using for the next 5 years or so: it's usually the first version without any known vulnerabilities. As an example, downloads of Log4j Core 2.17.x amount to around 40% of the total downloads of Log4j Core. Of course if a vulnerability were to be discovered today, there would be no 2.17.3 release, but only a 2.24.2 release. Offering LTS branches with extended security support is not a choice a single project can make: a good LTS version must only use LTS versions of its dependencies. Since we depend on Commons, such an initiative should be ASF-wide. Piotr [1] https://openjdk.org/jeps/14 [2] https://the-asf.slack.com/archives/C4TQW0M5L/p1728204781631769 --------------------------------------------------------------------- To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org For additional commands, e-mail: security-discuss-h...@community.apache.org
