GitOps is an operating model for infrastructure and application delivery in which a Git repository is the single source of truth, and an automated controller continuously reconciles the live state of a system to match what's declared in that repository. So what is GitOps in practice? It means every change to a Kubernetes cluster, a cloud environment, or an application deployment starts as a pull request against declarative configuration files -- YAML manifests, Helm charts, Terraform modules -- rather than a manual kubectl apply or a click in a cloud console. An agent like Argo CD or Flux CD watches the repo, detects the difference between desired and actual state, and applies the change automatically. Git history becomes the audit log, and rollback is just a revert. It's a natural evolution of infrastructure-as-code, but with Git itself acting as the control plane rather than just a storage location for config.
What Is GitOps, Exactly?
What is GitOps, at its core, is the discipline of using Git as the sole mechanism for changing infrastructure and application state, enforced by software rather than by process documents. The term was coined by Weaveworks in 2017 to describe how they ran Kubernetes: every operational change -- scaling a deployment, rotating a secret reference, updating an image tag -- was expressed as a commit, reviewed like any other code change, and merged before it took effect. A reconciliation controller running inside the cluster then pulled that state and applied it, rather than an engineer pushing changes from a laptop. This flips the traditional deployment direction: instead of CI/CD systems pushing credentials and commands out to production (push-based deployment), the cluster pulls its own configuration from Git (pull-based deployment). That distinction matters enormously for security, because it removes the need to grant external systems standing write access to production.
A concrete example: at Intuit, platform teams manage thousands of Kubernetes namespaces across multiple clouds using Argo CD synced against Git repositories. An engineer wanting to deploy a new service version opens a pull request updating an image tag in a manifest repo. Once approved and merged, Argo CD's controller -- running with in-cluster credentials, not the engineer's -- detects the diff and applies it within seconds. No one ever runs kubectl apply against production directly.
How Is GitOps Different from DevOps?
How is GitOps different from DevOps is a common point of confusion, and the short answer is that GitOps is a specific implementation pattern within the broader DevOps philosophy, not a replacement for it. DevOps is a cultural and organizational model: it emphasizes collaboration between development and operations, shared ownership of reliability, and automation of the software delivery lifecycle. GitOps vs DevOps isn't really a contest -- GitOps takes the DevOps principle of "automate everything" and adds a specific constraint: the desired state of every environment must be declared in version control, and changes only take effect through that path. You can practice DevOps with imperative scripts, manual runbooks, or ChatOps-style Slack commands that trigger deployments. GitOps forecloses those options deliberately. It trades some flexibility for auditability, consistency, and the ability to answer "what does production actually look like right now, and why" by reading a repository rather than interrogating a live system that may have drifted from anyone's documentation.
How Does Declarative Infrastructure Deployment Work in GitOps?
Declarative infrastructure deployment works by describing the end state you want -- three replicas of this service, this ingress rule, this IAM policy -- rather than the sequence of commands needed to get there, and letting a controller figure out the steps. This is the opposite of imperative deployment, where a script or engineer issues explicit commands like "scale to three" or "create this load balancer" in a particular order. In a GitOps workflow, a tool like Flux CD reads manifests such as a Kubernetes Deployment spec or a Crossplane resource definition, compares them against the cluster's actual API objects, and computes the minimal set of API calls needed to close the gap. If someone deletes a pod manually, the controller notices the actual replica count no longer matches the declared count of three and recreates it -- without anyone re-running a deploy script. Terraform popularized this model for cloud infrastructure; GitOps controllers extend it to live, continuously-enforced reconciliation rather than a one-time terraform apply that only runs when a human remembers to run it.
What Happens When GitOps Drift Occurs, and How Does Reconciliation Fix It?
GitOps drift occurs when the live state of a system diverges from what's declared in Git -- for example, an on-call engineer runs an emergency kubectl edit to bump memory limits during an incident, or a cloud console change is made outside the pipeline -- and reconciliation is the automated process that detects and corrects that divergence. Most GitOps controllers reconcile continuously, typically polling or watching the cluster every few seconds to minutes, comparing observed state against the Git-declared spec. When Argo CD detects drift, it flags the affected resource as "OutOfSync" and, depending on configuration, either alerts a human or self-heals by reapplying the declared state automatically. This is powerful for consistency but has a real operational sharp edge: during an active incident, a well-intentioned manual fix can get silently reverted by the reconciliation loop minutes later if the underlying Git state was never updated, re-triggering the outage. Mature GitOps practices handle this by pausing auto-sync during incident response and requiring the emergency change to be committed back to Git as the actual fix, closing the loop rather than leaving drift as a standing exception.
What Does the GitOps Security Model Actually Protect Against?
The GitOps security model primarily protects against uncontrolled, unaudited changes to production infrastructure by collapsing all deployment authority into a single, reviewable, cryptographically-verifiable path: the Git repository and its associated controller credentials. Because the pull-based architecture means no external CI system needs standing production credentials, GitOps significantly shrinks the blast radius of a compromised build pipeline -- there's no long-lived deploy key sitting in a CI runner that an attacker can exfiltrate to push arbitrary changes. Every change is attributable to a commit, signed if branch protection and commit signing are enforced, and reviewable before merge. But this model concentrates risk in two places that security teams have to take seriously: the Git repository itself, and the reconciliation controller's credentials inside the cluster. If an attacker gains write access to the manifest repo -- through a stolen developer token, a misconfigured branch protection rule, or a compromised CI job that can push commits -- they can get malicious changes deployed through the exact same trusted path defenders rely on, often bypassing the human review step entirely if merge checks aren't enforced correctly. This is not hypothetical: incidents involving compromised CI/CD credentials and poisoned pipeline execution, in the style of the 2020 Codecov bash uploader compromise, illustrate how a single foothold in the delivery chain can quietly propagate to every downstream environment. Treating the GitOps repo and controller as Tier-0 assets -- with mandatory signed commits, required reviewers, protected branches, and least-privilege, scoped service accounts for the reconciliation agent -- is what makes the model's theoretical security benefits real in practice.
How Safeguard Helps
Safeguard is built for exactly this shift in where deployment authority lives. As GitOps concentrates control into Git repositories and reconciliation controllers, Safeguard gives security and platform teams visibility into that control plane and the software supply chain feeding it. It continuously scans the manifest repos, Helm charts, and Terraform modules that GitOps controllers act on for injected secrets, unauthorized changes, dependency confusion, and drift from approved baselines -- catching a malicious or mistaken commit before it's reconciled into a live cluster, not after. Safeguard also maps the provenance of the artifacts referenced in those manifests -- container images, base layers, build dependencies -- back to their source, so a team can verify that the image tag a pull request is bumping to actually corresponds to a build from a trusted, attested pipeline rather than a tampered registry push. For the reconciliation layer itself, Safeguard helps enforce least-privilege on controller service accounts and flags configuration that grants a GitOps agent broader cluster permissions than its declared workloads require. And because GitOps turns Git history into an audit trail, Safeguard correlates that history with runtime and vulnerability signals, so a security team investigating an incident can trace a live misconfiguration directly back to the commit, author, and pipeline run that introduced it -- closing the loop between declarative infrastructure deployment and the accountability it's supposed to provide.