Last reviewed:
Why every Sigma rule on a13e.com carries provenance metadata, and how you can verify a rule actually matches what CloudSigma produces.
Every Sigma detection rule we publish on a13e.com is, today and on every future day, what CloudSigma actually produces when you give it the same input. If we publish a rule for CVE-X and you enter CVE-X into CloudSigma right now, you should get the same rule body back.
Two failure modes are unacceptable. Forward drift: we publish rule R, CloudSigma now emits R'. Reverse drift: we publish R-fake that CloudSigma never produced. Both are forms of lying to a security audience. We have built the system so that neither can happen silently.
Every embedded rule shows its current integrity level on the page, next to the rule body.
Today, every embedded rule is at L1 and carries a public reviewed badge. The Verify in CloudSigma deep-link is in place but the live verification mode on the CloudSigma side ships in our next phase. Until then, the button pre-fills the input so you can run the generation yourself and visually compare.
Production rules carry a green production badge: status stable or test in the CloudSigma corpus, level medium or higher, and they have passed the full Sigma validator pipeline plus target SIEM backend conversion at build time.
We do not embed experimental rules on customer-facing pages. They remain useful corpus material, but they stay behind review until promoted.
Where no rule passes the bar, we do not embed a placeholder. We link out to CloudSigma instead.
Detection-engineering content has a specific hazard: the SigmaHQ rule format itself has no cryptographic provenance, no content hashing, no attestation. The author and date fields are descriptive, not verifiable. The rule marketplaces in the space (SOC Prime, Detection.fyi) ship rules with author attribution but no published round-trip verification protocol either.
Our integrity contract closes that gap for the rules we publish. The marketing position is plain: we do not ask to be trusted, we give you the means to verify.
If you find a drift between a rule we publish and what CloudSigma produces for the same input, that is a contract violation we want to know about. Email security@a13e.com or open an issue on the relevant CloudSigma rule. We will rotate the manifest, document the cause, and post-mortem in our quarterly transparency report.