GitOps has become the operational model for many Kubernetes deployments. ArgoCD and Flux watch a Git repository. The repository is the source of truth. When the repository changes, the cluster changes to match. Deployment is automatic, auditable, and repeatable.
This model has genuine operational benefits. It also has a specific security gap: GitOps deploys what is in the repository. If what is in the repository includes an image with 400 CVEs, GitOps faithfully deploys that image with 400 CVEs. GitOps enforces consistency between declared state and actual state; it does not evaluate the security properties of the declared state.
Integrating runtime security into GitOps workflows requires understanding where GitOps ends and where security controls must be layered in.
Where GitOps Creates and Closes Security Gaps?
GitOps closes the unauthorized change gap: In environments without GitOps, developers can make ad-hoc changes to cluster state that are not recorded anywhere. GitOps eliminates this: every change must go through the repository. The repository is the audit trail.
GitOps creates the stale image gap: GitOps deployments reference image tags or digests. If the image tag is mutable (latest, or a version tag that gets overwritten), the cluster might be running a different image than it appears to from the GitOps repository. If the image digest is pinned, the cluster runs exactly what is specified but may continue running an image with newly discovered CVEs until a repository commit updates the digest.
GitOps creates the runtime security gap: GitOps reconciles configured state with actual state. Runtime drift — a container that has been modified after deployment — represents a deviation that GitOps cannot detect. GitOps ensures the pod spec matches the repository; it does not ensure the running container matches the image.
Hardening Images Before They Enter the GitOps Repository
The most durable integration point between image security and GitOps is the CI/CD pipeline that produces images before they are committed to the GitOps repository.
The pipeline pattern:
- Application code is committed to the application repository
- CI builds the container image
- Runtime profiling and automated hardening run on the built image
- CVE scanning validates the hardened image against threshold policy
- The hardened image is signed and pushed to the registry
- The CI pipeline commits an updated image digest reference to the GitOps repository
- ArgoCD or Flux detects the repository change and deploys the updated image
Step 6 is the integration point. The image that the GitOps repository references is always the hardened, scanned, signed artifact. ArgoCD does not deploy unscanned images because the process that updates the GitOps repository (step 6) only runs after the security gates in steps 4-5 pass.
Docker security tool integration in step 3 means every image that enters the GitOps workflow has passed through security hardening. The GitOps repository, by construction, only contains references to images that have been security-verified.
Detecting Runtime Drift in a GitOps Context
GitOps declares what should be running. Runtime security monitoring observes what is actually running. The combination enables a specific detection capability: detecting when what is running deviates from what GitOps declared.
Sources of drift in a GitOps environment:
Exec-based modifications: A developer or operator execs into a running pod and makes changes. GitOps does not track these changes; they are invisible to the reconciliation loop.
Admission controller bypass: In some configurations, admission controllers can be bypassed. If a pod is created without going through the standard admission flow, it may not match the GitOps declared state.
Mutable tag drift: If the GitOps repository references a mutable tag rather than a pinned digest, the image may change without the repository changing. The cluster runs a different image than the one that was validated.
Runtime drift detection that monitors running containers against their expected state — based on the image digest that was validated before deployment — catches all three scenarios. Container security software that compares running container state against the expected baseline alerts when divergence is detected.
Automating Security Updates in the GitOps Loop
One of GitOps’ operational strengths is that it enables automated updates: tools like Renovate or Dependabot can open pull requests to update image references when new versions are available. This mechanism can be extended for security:
CVE-triggered image updates: When a new CVE is disclosed against a package in a running image, a security automation tool can trigger a re-hardening and re-scanning pipeline. If the hardened image meets the CVE threshold, the automation opens a pull request updating the image digest in the GitOps repository.
Base image update automation: When upstream base images update, automation detects the new version, triggers re-hardening, and opens a pull request if the hardened image passes all gates.
This creates a closed loop: new CVEs trigger automated remediation, automated remediation produces updated images, updated images are deployed through the GitOps flow, and the deployment is recorded in the repository audit trail.
The GitOps audit trail — who committed what change, when, and why — extends to security updates. Security changes are not ad-hoc; they follow the same pull request, review, and merge process as application changes. The security posture of the cluster is as well-governed as its application configuration.
Frequently Asked Questions
What security gaps does GitOps introduce for container runtime security?
GitOps enforces consistency between declared state and actual state—it deploys what is in the repository faithfully, but does not evaluate the security properties of that declared state. This creates two specific gaps: the stale image gap (images may carry newly disclosed CVEs until a repository commit updates the reference) and the runtime security gap (GitOps cannot detect runtime drift where a running container has been modified after deployment, such as through exec sessions).
How does container runtime security integrate with GitOps workflows?
The most durable integration point is the CI/CD pipeline that produces images before they enter the GitOps repository. By running runtime profiling, automated hardening, CVE scanning, and image signing before the pipeline commits an updated image digest to the GitOps repository, ArgoCD and Flux only ever deploy hardened, security-verified images. The GitOps repository becomes a record of security-validated artifacts rather than unverified image references.
What is runtime drift detection in a GitOps context and why does it matter?
Runtime drift detection compares the actual state of running containers against the expected state declared in the GitOps repository—including the validated image digest. Sources of drift include exec-based container modifications, admission controller bypass, and mutable image tag changes. Detecting this drift catches security violations that GitOps reconciliation cannot see, since GitOps monitors the pod spec but not the running container’s internal state.
How can CVE remediation be automated within a GitOps workflow?
CVE-triggered automation can monitor deployed images for newly disclosed vulnerabilities and trigger re-hardening and re-scanning pipelines when CVEs are found. If the hardened image meets the CVE threshold, automation opens a pull request updating the image digest in the GitOps repository, which ArgoCD or Flux then deploys. This creates a closed loop where container runtime security updates follow the same pull request, review, and merge process as application changes, maintaining full audit trail in the repository.
The Policy-as-Code Integration
GitOps deployments benefit from policy-as-code enforcement that evaluates security properties of GitOps declarations before they are applied. OPA/Gatekeeper or Kyverno policies that enforce:
- All image references must be digests (no mutable tags)
- All images must have hardening attestations
- All images must be signed by a trusted key
- All pods must be configured with specific security contexts
These policies are defined as code in the GitOps repository alongside the application configuration they govern. The policies are version-controlled, reviewed, and deployed through the same workflow as application changes.
When GitOps tries to apply a configuration that violates policy (because a pull request slipped through without attaching a hardening attestation), the admission controller rejects the application. The repository may say to deploy a specific image; policy says the image does not meet standards; the deployment is blocked until the image is hardened.
GitOps provides the deployment consistency. Image hardening provides the security properties. Policy-as-code enforcement ensures the security properties are maintained as the deployment consistently applies changes. The three work together.
