GitOps as a Model for Security Governance pt.I

Engineers within DevOps cultures get excited about the prospect of IaC, and rightfully so. IaC turns sprawling instances and networks and the myriad steps required to recreate them into a human-readable declarative configuration that can be stored, shared, and reasoned over, just like any other code or config. This allows for consistency at scale and faster delivery.

When IaC is considered together with CSP configuration, a clear picture of an application’s security posture comes into focus. This picture isn’t entirely complete; particularly missing are telemetry regarding source code controls and defects, OSS composition, as well as operational drift and monitoring. But increasingly, IaC + CSP config reflect a ‘critical mass’ of security posture telemetry in one place, declaratively specified, and easy to parse and reason over.

In a previous entry, we presented a taxonomy of cloud security defects and vulnerability. A complete picture of an application’s security posture spans the concept space of IAM, Trusted Sourcing, Configuration and Context, Monitoring, Privacy, and Resilience. And if understanding and managing an application’s security posture involves this span of visibility, then effective governance requires controls in every phase of the development and operational lifecycles. The question is:

At what key points can organizations govern as much of what impacts security posture as possible, and early in the lifecycle?

The GitOps model provides some insight. In a way, GitOps is for governance what IaC was for DevOps: a sufficiently large lever to galvanize culture change “at scale.” What is GitOps? First and foremost, GitOps relies on a source control technology platform — presumably Git. It then overlays governance on the process conventions and workflow provided by the platform. Different vendors talk about GitOps differently, but there are some undeniable precepts:

  1. Express as much as possible declaratively. This includes IaC, platform orchestration, and pipeline/delivery.
  2. Check EVERYTHING into source control repositories.
  3. Build governance workflows on top of a source control platform. This includes:
    1. Defect discovery and coding standard enforcement;
    2. Triage, assignment, and change request workflow;
    3. Peer reviews, escalations, and sign-offs.
  4. Leverage orchestration agents to automate CI/CD on platform events (like check-in or PR).

Consider the first and second bullets above. Evangelists speak in absolutes, but your organization will benefit dramatically from pursuing these goals directionally. For instance, some production asset orchestration may still require imperative script to deliver, but it can be expressed as code and checked in.

Building governance workflows, such as defect discovery, becomes much simpler once more of what impacts posture is written as code/configuration, made easier to reason over declaratively, and reposited in a single technology platform — the source control platform. Note that nothing in bullet three above is “security-specific” — this is simply how engineers manage quality within their git-based toolchain. Cloud and application security initiatives can overlay their own governance controls naturally on the existing engineer workflows and conventions without generating the historically prevalent technology and cultural friction and flashpoints.

The benefits provided by integrating security activities into a GitOps model are several and worth enumerating. Git provides:

  • Traceable accountability – Engineer actions (e.g. commit, merge) are automatically traceable and accountable, owing to the record of changes tied to performers that the source control platform excels at keeping.
    The ability to definitively trace code or configuration changes to an engineer is a boon for security governance. It facilitates routing security testing and other defect discovery telemetry back to the appropriate engineer automatically for remediation. Accountability, from a security perspective, comes in the form of requiring engineers to address a security change request within a certain SLA — blocking the progression of delivery, or asynchronously, within an SLA, to which security and engineering agree.
  • Gold source configuration – Accountability isn’t just for engineers; it’s for code as well. Version control and traceability of commits allow organizations to make sure that required elements of their quality regimen have been applied before promoting to production.
    Security governance benefits from the ability to define a gold source by making security activities a subset of the applied quality regimen. Understanding what source, configuration, and IaC are certified, once security testing, configuration, and hardening have occurred, allows organizations to ensure that ONLY code that’s been subjected to security controls is released.
  • Automation – With GitOps, organizations are encouraged to drive (CI/CD) pipeline execution from the source control platform; for instance, with GitHub or GitLab pipelines rather than Jenkins. Although, organizations don’t need to make a platform switch to head in this direction; even modern versions of Jenkins provide for declarative pipeline configuration and execution as YAML and event-driven workflow invocation.

Those adhering to the full extent of GitOps prescription even involve production agents, such as flux for k8s, that orchestrate production changes once IaC and configuration are checked into source control.

Automating CI and CD pipelines, as well as production orchestration, prevents unapproved drift without the need for bespoke products. Ubiquitous broad privilege among engineers — a common negative security consequence of DevOps — is therefore mitigated by access confined to the platform team and the automation code itself. The engineering population operates with less privilege. Secrets management tools for source control further reduce the scope of access/exposure of credentials needed to package for production, and the creation, storage, and use of those used in production themselves.

In light of the above, both functionally and in the opportunity presented to security governance, the imperative for those leading software and cloud security initiatives becomes:

Security initiatives seeking to combine their framework with a GitOps model will achieve their long-desired goal of SW-defined security governance.

In combining traceability, enforcement of a gold source, and compulsory automation, security governance gains a tremendous amount: security governance becomes a compulsory part of the software delivery lifecycle — the very brass ring we’ve been reaching towards for decades. The value of this can not be overstated.

Whether your organization’s goal is compliance or enhanced security, the key to scale is weaving automation to that end into the normal delivery processes and toolchains.

Concourse provides institutions a complete out-of-the-box solution designed to cover all security domains and keep organizations in compliance with regulators’ requirements for cloud security, risk management and governance.  Concourse gives enterprises the necessary policies and controls, visibility into cloud usage, and automation of cloud compliance functions.

Learn more here and read part two of our GitOps blog series here.

Editor’s note: John Steven is a software security expert with 20+ years of experience bringing innovation to market as products and services. Reach out to him and/or follow him on LinkedIn and Twitter.

Related Resources

Learn more about one policy architecture and Concourse Labs.