Skip to main content

A simple script to export your Google SecOps rules

  • July 11, 2026
  • 3 replies
  • 46 views

GromeroSec
Forum|alt.badge.img+5

As SIEM admins, we all get asked for the same thing every so often: "export the rules — give me everything we run." It's routine, and it shows up a lot in audit and compliance.😅

Most of the time we don't want to stand up a whole versioning / detection-as-code setup just for that. We just want to export our rules, the way you can in pretty much any other SIEM.

Google SecOps doesn't really hand you that today. The docs on this are either thin or jump straight to a full detection-as-code pipeline with Terraform, Git, and CI/CD — great if you run a platform team, overkill if you just need a copy of your rules.

So I wrote the simple middle: a small, read-only Python script.

  • - Pulls every rule via list_rules (it never modifies anything).
  • - Writes an Excel, one row per rule, with each meta field and each outcome variable as its own column — filterable and readable.
  • - Also drops one .yaral file per rule as a literal backup.

Requirements: a service account with chronicle.rules.list, and pip install secops openpyxl. That's it.

If you want to change what it exports, you don't need to know Python — there's an EDIT ZONE at the top where you flip a couple of True/False toggles or add column names to exclude (add/remove columns, turn the .yaral backup on or off, thin out the outcome columns).

Repo: https://github.com/gromerosec/google-secops-rule-export
Full write-up: Google SecOps Field Notes: A Simple Way to Export Your Rules
https://medium.com/@gromerosec/google-secops-field-notes-a-simple-way-to-export-your-rules-d61f0aa7f79d?sharedUserId=gromerosec

Hope it helps someone. Cheers.

3 replies

whathehack81
Forum|alt.badge.img+6

Yeah, this comes up a lot. 🧠 

 

If you do not want to stand up a full detection-as-code pipeline, the practical middle ground is usually a small scheduled export script that pulls the current rule/detection objects through the available API, writes them to JSON/YAML, and stores them in a timestamped folder or Git repo.

 

That gives you:

 

- audit evidence of what rules existed at a point in time

- simple diffing between exports

- rollback/reference history

- no full Terraform/GitOps pipeline required

 

I would probably keep it read-only at first: export only, no deployment/import logic. Then later, if the team wants proper detection-as-code, the same export format can become the starting point.

 

So I agree with the pain point: for compliance/audit, a simple “export everything we run” workflow is often enough, and a full CI/CD detection pipeline can be overkill for smaller teams.


GromeroSec
Forum|alt.badge.img+5
  • Author
  • Bronze 3
  • July 11, 2026

Exactly — that is the middle ground I was aiming for: read-only, simple, and without requiring a full CI/CD setup.

One point I feel strongly about is that even a small Python script or API call can still be a real barrier for many Blue Team analysts. I entered security without being a developer and without understanding how APIs worked. What feels simple to us today can be genuinely challenging for someone earlier in that journey.

That is why I wanted to make this feel more like a small tool than a code example: safe defaults, clear inputs, readable output, and minimal need to understand the implementation.

Thanks for the thoughtful reply, R.Q.


whathehack81
Forum|alt.badge.img+6

Absolutely agree. That “simple for us, still a barrier for others” point is easy to forget.

 

Making the export read-only with safe defaults is the right call. It lowers the risk for admins who just need audit evidence without asking them to become developers or maintain a full detection-as-code pipeline.

 

Good share. 🧠