Date: 2021-10-26
Participants: 10 Dev Retreat participants

This was a 70 minute group discussion.

The following ways to avoid future CVEs were discussed:

• Rule exclusion packages moving to plugins.
  The plan was still to move all rule exclusion packages out of the main Core Rule Set and into separate plugins in separate repositories. This would mean that any future vulnerabilities found in rule exclusion packages would automatically not affect all CRS users.
• Disallow certain constructs, e.g. ctl:requestBodyAccess=Off.
  It was agreed to stop using constructs that are inherently dangerous, e.g. switching off request body processing.
• Checklist for reviewing every rule.
  It was agreed that a checklist should be created containing a series of points to check against when reviewing rules. This could include things like anchoring regular expressions at the beginning and the end and ensuring that disallowed/dangerous constructs are not used.
  It was agreed that this checklist should be made into a set of public guidelines to incentivise contributions, so that new contributors would have a clear idea of how to write good commits that would be more likely to be accepted.
  It was agreed that the checklist for reviewing rule exclusions should be different to the general review checklist.
• Bug bounty program.
  The idea of running a CRS bug bounty program was discussed at length. The plan was to start off with a temporary program to gauge the quantity and quality of reports.
  The potential problem of dealing with duplicate reports was discussed. It was agreed that the upcoming demo site could help with this, if the new nightly builds were to be used (as previously reported issues would be fixed in the nightly builds, reducing the chance of a duplicate report).
  The potential problem of conflicts with reporters was discussed. It was agreed that a very clear scope would be required to try and avoid getting into conflicts with reporters.