Git as the source of truth means every intended change is committed, reviewed, and deployed through the pipeline. Direct runtime changes bypass that control and create drift between declared and actual state. In practice, GitOps depends on committed changes, continuous reconciliation, and automated alerts so that emergency manual edits do not become permanent hidden configuration.
How GitOps Treats Change Authority
GitOps makes Git the declared control plane for desired state. The practical difference is not just where configuration lives, but where authority to change it resides. If the change is committed, reviewed, and reconciled by automation, the deployment is traceable and repeatable. If the change happens only at runtime, the live system can diverge from the approved record.
That distinction matters because “source of truth” is about governance as much as storage. A Git commit creates an auditable intent trail, while a direct edit to a running cluster, container, or service instance creates an unrecorded exception that may never be captured back into the pipeline.
GitOps also changes how teams think about recovery. In a mature workflow, the runtime is treated as disposable and reconciliation restores it to the committed state. In a manual-change model, the runtime itself becomes the de facto truth, which makes it harder to tell whether a fix is temporary, who approved it, or whether the environment still matches the declared configuration.
Why Direct Runtime Changes Create Drift
Direct runtime changes bypass the review, policy, and deployment controls that GitOps relies on. Even when the edit is made for a good reason, it can introduce configuration drift, because the live state now differs from what Git, the pipeline, and the rest of the infrastructure believe is true. That drift often stays hidden until the next reconciliation cycle, outage, or audit.
The problem is not limited to Kubernetes or any one platform. Any system that supports ad hoc edits, from manifests and secrets to runtime flags and permissions, can accumulate invisible differences. Once teams start treating the live environment as a convenient place for fixes, they also weaken rollback confidence, because there is no single change record that explains the current state.
GitOps works best when emergency edits are treated as exceptions that must be codified immediately. If a runtime change is valid, it should become a committed change as soon as possible so that the declarative record, the pipeline, and the deployed environment converge again.
What Practitioners Should Watch For in a GitOps Workflow
The real test is whether the pipeline can still answer four questions: what changed, who approved it, where it was deployed, and whether the live state still matches the desired state. If any of those are unclear, the workflow is drifting away from GitOps and toward manual operations with a Git backup.
For runtime change control, the most important signals are reconciliation gaps, unexpected config deltas, and privileged access paths that let operators edit production outside the normal workflow. That is where drift begins to become operationally significant, because a single well-intended hotfix can create a lasting gap between declared and actual state.
From a change-management perspective, the best discipline is simple: treat Git as the only durable record of intent, and treat the runtime as something that should converge back to it. CI/CD pipeline exploitation case study is a useful reminder that pipeline bypasses and exposed operational paths can turn an exception into a lasting control failure.
Risk and Threat Considerations
Direct runtime changes increase the risk of configuration drift, unauthorized persistence, and blind spots in change review. They are especially dangerous when secrets, access settings, or deployment manifests are edited outside the normal pipeline, because the system can continue operating with an unapproved state that no one has formally inspected.
Failure mechanism: An operator, script, or attacker alters the live environment without updating Git, so the reconciler, reviewers, and monitoring tools continue to trust an out-of-date declaration.
Impact: The environment can retain hidden misconfiguration, inconsistent rollback behavior, or unauthorized access paths until the next reconciliation, incident, or audit.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | GitOps depends on reviewed, controlled changes rather than ad hoc runtime edits. |
| CM-6 — Configuration Settings | The question centers on declared versus actual configuration state and drift. | |
| AU-2 — Event Logging | Runtime edits must be observable so hidden changes do not bypass the GitOps trail. | |
| Recommendation — Route all production changes through approved change control before reconciliation. Baseline configuration settings in Git and verify runtime matches them continuously. Log all privileged runtime changes with enough detail to reconstruct who changed what and when. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Git as source of truth is a configuration-management pattern that prevents uncontrolled drift. |
| Recommendation — Define Git-backed configuration rules and prevent unmanaged production edits. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | GitOps relies on secure, repeatable configuration rather than local runtime tuning. |
| Recommendation — Harden systems so production configuration changes are controlled and repeatable. | ||
Practitioner Guidance
What to verify: Confirm that reconciliation is actually authoritative, not just enabled. If a runtime edit is possible, verify that it is logged, detectable, and forced back into version control or removed automatically.
Common mistake: Teams often allow “temporary” hotfixes without a fast follow-up commit. That is how exceptions become undocumented production state, and undocumented state is the part that most often survives past the incident that justified it.
Decision rule: If a runtime change is necessary to restore service, treat it as a recovery action, then reconcile the change into Git immediately or revert it once the incident is stable. The goal is not to forbid urgent intervention, but to prevent runtime edits from becoming the enduring source of truth.
Practitioner takeaway: GitOps only stays trustworthy when the live system is subordinate to the declared state, and every emergency deviation has a short path back into the reviewed, versioned record.
Related resources from NHI Mgmt Group
- What is the difference between aggregated identity signals and direct source-of-truth verification in identity verification?
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
