DevOps mainly covers build, test, and artifact creation through pipelines. GitOps controls what gets deployed, where it goes, and how cluster or infrastructure state stays aligned with Git. In security terms, DevOps produces trusted outputs, while GitOps enforces desired state at runtime. Most organisations need both, because they solve different parts of the delivery and control problem.
Where DevOps stops and GitOps starts
DevOps is the delivery discipline that connects development and operations so software can be built, tested, released, and operated with less friction. In a security architecture, its centre of gravity is the software production path: source control, build integrity, test automation, artifact signing, pipeline permissions, and release approvals. GitOps begins where those outputs are deployed and continuously reconciled to runtime state.
The practical difference is control location. DevOps focuses on producing trusted software artifacts and reducing release risk through automation. GitOps treats Git as the source of desired state for infrastructure or clusters, then uses reconciliation to keep the running environment aligned. That makes GitOps especially valuable when you need a clear, auditable control plane for deployment drift, change control, and rollback behaviour.
For security teams, this division matters because the same pipeline can be used safely or unsafely depending on which stage is being protected. A compromised build pipeline threatens the artifact. A compromised GitOps path threatens the deployed state. Those are related but not identical failure modes, so the controls should not be treated as interchangeable.
Why the distinction matters in a security architecture
Security architecture needs to separate trust in Zero Trust Architecture from trust in delivery automation. DevOps typically governs how code becomes a release candidate, while GitOps governs how approved desired state is enforced after deployment. In other words, DevOps is usually about provenance and pipeline integrity, while GitOps is about runtime conformance and state drift control.
That distinction also explains why organisations often use both. DevOps without GitOps can produce good artifacts but leave operators relying on manual changes or ad hoc deployment steps. GitOps without DevOps discipline can faithfully deploy something that was never well validated. The security value comes from combining trusted build outputs with controlled, observable deployment enforcement.
This is also where configuration and drift risks surface. If a cluster or infrastructure layer can be changed outside Git, the runtime control loses some of its assurance value. If pipeline credentials or build steps are poorly governed, the artifact itself may be untrustworthy even if GitOps later enforces it cleanly. The architecture must therefore define which layer owns build trust and which layer owns runtime state trust.
Practitioner implications for control design
When you design the control model, decide whether a change should be approved at build time, at deploy time, or both. Build-time controls answer whether the software or manifest is acceptable to ship. Deploy-time controls answer whether the running environment matches the approved declaration. Treat those as separate checkpoints with separate evidence, separate ownership, and separate failure handling.
Useful implementation cues include:
- Keep pipeline credentials tightly scoped so DevOps systems can build and publish, but not silently alter production state.
- Use Git review and protected branches for desired-state changes that should trigger runtime reconciliation.
- Monitor for drift where runtime state diverges from the repository, because drift is the signal that GitOps assurance has been weakened.
- Preserve artifact provenance so a deployed object can be traced back to the build that produced it.
For runtime control, GitOps works best when the deployment agent can only make the changes the repository authorises. That is a strong fit for environments that value repeatability and fast rollback, but it requires discipline around who can change Git, how secrets are handled, and whether manual hotfixes are allowed. If exceptions are common, the architecture is drifting away from GitOps even if the tooling still looks compliant.
Practitioner takeaway: Use DevOps to harden the path from source to artifact, then use GitOps to harden the path from artifact to desired runtime state; most security failures happen when those two control planes are blurred.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST Zero Trust (SP 800-207), NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | 4.1 — Access Control Policy and Enforcement | GitOps runtime enforcement depends on policy-based control of what may change state. |
| Recommendation — Enforce policy-driven access decisions for deployment and reconciliation actions. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations | Separate build and deploy privileges so pipeline systems cannot overreach into runtime control. |
| Recommendation — Restrict pipeline and deployment permissions to the minimum required. | ||
| CIS Controls v8 | 6 — Access Control Management | DevOps and GitOps both rely on tightly governed permissions for repositories, pipelines, and deployment paths. |
| 16 — Application Software Security | DevOps is the software delivery path where build integrity and release quality are established. | |
| Recommendation — Review and revoke excessive access to source, build, and deployment systems. Build security checks into the software delivery pipeline before release. | ||
Related resources from NHI Mgmt Group
- What is the difference between embedding security in DevOps and adding more approvals?
- What is the difference between graph-native security architecture and simply visualising security data as a graph?
- What is the difference between single-tenant and multi-tenant architecture for SaaS security and operations?
- What is the difference between a static architecture diagram and a live software graph for security reviews?
