Releases are rebuilt daily under a rolling tag: what that means for your deployment

[fabriziosalmi]

A note on how this repository publishes rules, since the release model is unusual and it affects how you should deploy them.

There is one tag, and it moves

Every release is published to the tag latest. A scheduled workflow runs daily at 00:00 UTC, re-fetches the OWASP Core Rule Set, runs the four converters plus the bad bot generator, commits the regenerated files and republishes the four archives. The tag you downloaded last month is not the tag you download today, and there is no v1.4.2 to fall back to.

Today's build carries 646 patterns across 20 categories, and 1879 bot signatures shared by all four backends.

A correction to the first version of this post, which repeated the CRS version printed in the release notes. That number is not reliable. The release notes query the CRS latest release directly, while the code that fetches the rules resolves --ref as a string prefix defaulting to v4.0, and reverse string ordering over the matching tags selects v4.0.0-rc2. The two mechanisms are independent, so the version named in a release body is not necessarily the version the archives were built from. The details, and how to build against a version you choose, are in How it works.

Backend	Format	Archive
Nginx	map + if	nginx_waf.zip
Apache	ModSecurity	apache_waf.zip
Traefik	middleware TOML	traefik_waf.zip
HAProxy	ACL	haproxy_waf.zip

What this means for you

Do not pull latest from a production host on a cron job. An upstream CRS change can alter a regular expression that your traffic happens to match, and you will find out from your users. Fetch, stage, test, then roll.

Pin by digest if you need reproducibility. Every release body lists the SHA-256 of all four archives. Record the one you deployed:

echo "<sha>  nginx_waf.zip" | sha256sum -c -

If a rebuild ever surprises you, that digest is how you tell which build you were actually running.

Validate before reload, every time. nginx -t, apachectl configtest, haproxy -c -f /etc/haproxy/haproxy.cfg. The repository runs Nginx and Apache validation in CI on every change, but CI validates the generated files in isolation, not against your configuration.

Known issue in current builds

Nginx caps a single configuration parameter at 4096 characters, and some generated regular expressions cross it, producing too long parameter, probably missing terminating character. The case in xss.conf was fixed in #7; a report against waf_maps.conf is open at #22. If you hit it, the issue lists the offending lines and dropping them is a safe workaround until the converter splits them.

Caddy

Caddy is not one of the four backends. It has a separate implementation at caddy-waf, which is a Caddy module rather than a rule export.

Integration guides are on the documentation site. Deployment questions belong in Q&A; a rule that fires wrongly, or one that should fire and does not, belongs in issues with the request that triggered it.