Lessons Learned From (Almost) 8 Years Of Sigma Development

Thomas Patzke, a core developer of the Sigma generic detection rule format, reviews nearly eight years of building the project. Sigma began around 2016 as an experiment to describe log-based detections in a vendor-neutral way and convert them into queries for many SIEM platforms. Early on, the rules and the converter lived in one large repository. This allowed fast, breaking changes, but ownership of individual backends was hard to track and the team did not agree on what a release contained.

The middle of the talk covers the 2020 rewrite of the toolchain into a separate library and command-line tool, backed by a large test suite that catches regressions a simple run-to-completion check missed. Rules were split from code, and backends moved into their own projects so that maintainers could own them. The speaker also describes trade-offs: breaking changes now require coordination across projects, and version compatibility between the library and backends has become more complex. Licensing was another lesson. The specification went to the public domain, the tooling moved to LGPL, and the rules received a custom detection rule license that requires attribution. The speaker stressed that the team were not lawyers and that changing licenses meant asking every contributor for consent.

To close, Patzke offers advice for maintainers and contributors: release early and often, discuss large changes with maintainers before writing code, keep quality gates such as tests and enforced formatting while welcoming small fixes, and take breaks to avoid burnout. Sponsorship and direct user feedback are also presented as sources of motivation.