I wanted to share a practical workflow pattern I’ve been using with Google SecOps for detection rule management.
This is not meant as a replacement for the Gemini capabilities already available in Google SecOps. In my environment, Gemini has mostly been relevant on the SOAR / automation decisioning side, while Claude Code has helped in a different layer: as an external workflow layer on top of the Google SecOps API for repetitive rule-management tasks.
That distinction matters.
I’m not using Claude Code to “chat about alerts.” I’m using it to operate on top of real rule workflows that are usually slow, manual, and inconsistent when done only through the console.
The common problems are familiar to anyone who has operated a SIEM for a while:
- rules become outdated over time
- rules are created by different engineers or different teams
- metadata drifts
- naming conventions diverge
- validation becomes inconsistent
- some rules outlive the people who originally wrote them
The detection logic may still be useful, but the operational layer around the rule starts to decay.
What I’ve found useful is using Claude Code + the Google SecOps API to turn that work into controlled workflows.
The base I use for this is an open-source skill I published here:
google-secops-claude-skill
https://github.com/gromerosec/google-secops-claude-skill
That base skill includes:
- a quick-reference layer for 35+ Google SecOps API methods
- reusable operation patterns for read / update / search / delete flows
- rule-oriented templates
- DRY_RUN-first execution patterns
- documented API gotchas found in real usage
On top of that base, these are the 3 workflows I use most for rule management.
1. Bulk Rule Modification
One common problem in rule operations is that the same change needs to be applied across many rules.
Examples:
- adding a new exclusion
- aligning a namespace or metadata field
- updating a condition pattern
- adapting rules after a source-side change
The traditional approach is manual:
open each rule, patch it, re-check it, compile it, repeat.
The workflow I use is different:
- retrieve the target rules through the Google SecOps API
- identify the rules that match a given scope
- apply the modification in memory
- show the proposed change first in DRY_RUN
- write back only after review
The benefit is not just speed.
The main benefit is reducing manual drift across rules that should stay consistent.
2. Live Validation Through Upload-and-Delete
Another common issue is validation.
A rule can look correct in text form and still fail when tested in the real platform because of field assumptions, formatting, or compilation behavior.
For that, I use a simple workflow:
- prepare or transform the candidate rule
- upload it through the API
- confirm whether Google SecOps accepts it
- capture the result
- delete it immediately if the objective was validation only
This gives me a fast operational answer, not just a visual review.
For me, this is one of the strongest reasons to use the API directly: validation becomes an engineering workflow, not just a console activity.
3. Metadata and Context Standardization
This is probably the least flashy workflow, but one of the most useful over time.
A lot of environments accumulate rules from:
- multiple engineers
- multiple projects
- inherited content
- legacy content maintained over several years
In those cases, the rule logic may still be valid, but the surrounding metadata becomes inconsistent:
- descriptions
- naming
- MITRE fields
- context fields
- output structure
The workflow I use here is:
- preserve the detection logic itself
- standardize the metadata and context layer
- validate the transformed rule
- produce an output that is easier to operate and review
In practice, that means I do not treat the entire rule as something to rewrite blindly.
The goal is to preserve the behavioral logic while making the operational layer more consistent.
Why This Works Well in Google SecOps
One thing I do want to call out positively: this kind of workflow is possible because Google SecOps exposes a strong enough API surface for rule operations.
That is what makes this practical.
Without API access, many of these tasks stay trapped in repetitive manual work.
With the API, they can become controlled workflows with:
- retrieval
- scoped changes
- validation
- repeatability
- better operational consistency
That is the layer where Claude Code has been useful for me.
Again, this is not about replacing native AI capabilities in the platform. It is about using an external coding/workflow agent for a different type of work: repeatable operator-side execution on top of the API.
The More General Pattern
The interesting part is not Claude Code specifically.
The interesting part is the pattern:
If a SecOps task is:
- repetitive
- logic-driven
- exposed through an API
- annoying to do manually
- important enough to deserve consistency
then it is a good candidate for this kind of workflow layer.
That applies especially well to rule management.
Closing
This is simply a workflow I’ve found useful in practice.
I’m sharing it here because I suspect many teams operating Google SecOps run into the same operational problems around rule maintenance, validation, and standardization over time.
Curious if others here are using similar API-first rule management workflows, whether with native tooling, custom scripts, Gemini-related automation, or external coding agents.
Base skill I use:
https://github.com/gromerosec/google-secops-claude-skill
Longer write-up:
https://medium.com/@gromerosec/a-claude-code-skill-for-google-secops-working-beyond-the-ui-e1e22f7156aa
— gromero-sec | Detection Engineering | github.com/gromerosec/
