Integrating GitOps into your Security Operations

Software engineering solved a problem two decades ago that security operations still lives with every day. When a developer changes production code, the change moves through version control: it is reviewed, it leaves an audit trail, and it can be rolled back in seconds when it breaks something. When a security team changes a detection rule, too often someone edits it by hand, in one console, in one tenant, with no record of who changed what and no easy way to undo it. Christopher Luft, a LimaCharlie co-founder who started his career as a developer, opened this session on that contrast, and the argument that follows from it is simple: the GitOps discipline engineering takes for granted works just as well for security, and once you have a taste of it there is no going back. The demonstration, run by senior security engineer Chris Botelho, is really about what changes when your detection logic lives in Git instead of in a UI.

Configuration becomes code, and code has a workflow

The foundation is infrastructure as code. In LimaCharlie, everything behind a tenant, down to the detection and response rules, is expressed as YAML rather than clicked together by hand. Botelho builds a brand-new organization this way, using the infrastructure-as-code generator to select what he wants, default automation and detection templates, the GitSync extension, and Windows event log streaming so the telemetry actually flows, and the YAML assembles in front of him as he goes. Pasting that template into an organization kicks off a dry run that shows exactly what will happen before anything is committed, and the apply itself is additive: it builds on what is already there instead of overwriting or deleting, so there is no risk of clobbering existing configuration. A single paste stands up an organization with a full rule set and the Hayabusa, Plaso, and Velociraptor extensions enabled, with no rule-by-rule definition required.

Putting that code in Git is what turns it into GitOps, and the payoffs are the ones software teams already rely on. Branching and pull requests. A complete audit trail of every change. Easy rollback when something goes wrong. Luft is not claiming this is novel technology. His point is that security has been slow to adopt a workflow proven everywhere else, and the cost of that hesitation is paid in manual effort and missing history.

One source of truth, many tenants

The argument lands hardest for service providers, because the manual model does not survive scale. An MSSP that wants to push a new detection rule or a lookup to every customer has historically had to open each organization and update it one at a time, which Botelho notes takes a long while for the larger providers. GitSync replaces that with a hub. You designate a main organization where customer-wide changes are made, connect it to a private Git repository, and configure each customer organization to pull the shared rule sets on a schedule or on demand. Change a rule once in the main org, push it to Git, and every subscribed tenant picks it up on its next pull. Distribution that used to be a day of repetitive clicking becomes a commit.

What keeps this safe rather than blunt is that the additive behavior carries all the way through. Pulling shared rules into a customer tenant does not erase what is local to that customer. Their own detection and response rules, their false-positive suppressions, and their lookups all survive. A provider gets to standardize the baseline across the entire book of business while each client keeps the tuning that fits its environment. That combination, central control without forced uniformity, is what actually lets managed detection scale.

The mechanics stay deliberately ordinary

The setup is intentionally unremarkable, and that is part of the pitch. GitSync needs an SSH key pair, a Git repository, and a deploy key, and because it speaks plain Git it works with GitHub, GitLab, or Bitbucket rather than locking you into one host. Exporting is a matter of choosing which artifacts to publish, general rules, false-positive rules, YARA rules, lookups, and the extension writes them into a tidy folder structure in the repository. Importing is the mirror image: an orgs folder keyed by organization ID, each with an index file that points at the exports it should consume, written as the kind of directory path any engineer would recognize on sight. Subscribing a customer organization and pointing it at the repository takes the same handful of fields as the export side.

Strip away the demo and the message is about posture. Security teams have long treated detection content as something you maintain by hand, tenant by tenant, with no version history and no safety net. Managing it as code in Git treats it the way every other critical system is already managed, with review, audit, and rollback built in. For an MSSP or MDR, that is not a convenience feature. It is the difference between rule management that scales linearly with your customer count and rule management that does not scale at all.