All,
Historically, our approach to security fixes has been:
- take advantage of any opportunity to disguise what is actually being
fixed
- commit the fix with a non-obviously security related commit message
- tag
- vote
- release
The time between the commit and tag depended on:
- the severity of the issue (more severe, closer to the tag)
- how obvious the fix was (more obvious, closer to the tag)
The vote period is usually the standard >= 72 hours but we have reduced
that to a few hours when we have needed to release in a hurry.
AI changes all of this. It is trivial (the ASF security team did this
with the 9.0.118 tag) to get AI to review the diff between tags and
identify the security fixes. It took about 20 minutes and several of the
CVEs I've just published were in the first few results. Work colleagues
have been doing something similar for a while too.
Given this change in circumstances, I think it is worth reconsidering
how we approach security vulnerabilities and releases.
A few random ideas to get the discussion started:
- Where mitigation is available (e.g. via configuration) publish the CVE
at the same time as the fix is committed - i.e. before the release.
- Build and vote on releases in private then push to the pubic repos and
announce the CVEs as part of the release process.
- Run some (which?) AI security scans on the Tomcat code base to try get
ahead (unlikely) but at least keep up with anything an attacker could
find.
- Reduce the voting period.
- Something else?
Thoughts?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
