GitOps as a Model for Security Governance pt.II
In a previous entry, we discussed the GitOps model and how security initiatives will achieve their long-desired goal of SW-defined security governance through combining their existing framework through said GitOps model.
Generally, source control platforms provide a rich and well-liked user experience for notification, collaboration, difference visualization, provenance, and versioning. These are feature streams that security telemetry tools have historically struggled to bring to market in an enterprise-class way. These features are essential for helping with key security workflow elements like triage, root cause analysis, and remediation workflow. Tying into the platform that engineers already use comfortably to manage change and delivery reduces measures like mean-time-to-remediation and turn-around-time on remediation requests. Improvement can be stark. Weaveworks, a firm focused on GitOps, has seen this approach reduce the time needed to fix production bugs by 60% and the time required to field customer requests by 43%.
Yet, GitOps is not a panacea. A few things will complicate organizational adoption and roll-out.
- Standardization – First and foremost, while all organizations use source control systems, many organizations have not and cannot standardize on one. If they did standardize, they might not be using a modern git variant that supports pipelines, workflow, and the agents that deliver the features described above.
A governance regime that only works for a percentage of an application portfolio is not what security executives are after — they need complete portfolio coverage. If a CISO wants to leverage GitOps in an organization that uses Git[Hub/Lab] in some percentage of their application portfolio, they will need a mechanism to facilitate similar governance in product/business lines that aren’t leveraging git-based source control platforms. Legacy applications (especially those in a maintenance mode); those applications and systems acquired and operated (rather than built in-house); and 3rd party systems (such as SaaS) are all likely candidates for an alternative solution. - Maturity – Even if an organization has standardized on a Git-variant source control platform, many engineering teams use only a fraction of the provided core capabilities, let alone more recent additions such as Git pipelines, production agents, and so forth. Some of GitOps’ more compelling propositions depend on using these features to provide the automation and production delivery/orchestration capabilities described. Maturing use of source control platforms is no trivial task, and it may take months or years for engineering teams. Maturation of an organization as a whole is a multi-year objective.
- Comprehensive Lifecycle Visibility – Software’s lifecycle has many phases. Informally, many talk of ‘shifting left’ (earlier into development). Complete visibility demands telemetry within left (development), center (orchestration and delivery), right (operating in production), and ‘right-of-boom’ (incident response). A comprehensive governance program reflects this, applying controls left, right, and center, as well as right-of-boom. The fatal conceit of governance via a source control platform is representing comprehensive visibility when it will clearly only excel “left” in software development. GitOps is exciting, in large part, because platform features and IaC have allowed expansion into the “center” phase. Yes, production agents give GitOps a foothold on the “right,” but it will be challenging to convert this foothold into a stronghold in “right” and “right-of-boom” phases. SIEM/SOAR telemetry, their underlying data demands, and workflows are fundamentally different than the proactive security at which source control platforms excel and will frustrate a GitOps model for the foreseeable future.
The Concourse Labs platform presents organizations an important capability both in line with and as a complement to a GitOps approach to governance. Built on and with the modern approach to DX self-service in mind, Concourse Labs provides defect telemetry that can be readily plugged into source control pipelines and a GitOps governance model. Its ability to provide security telemetry on CSP config and IaC serves as an “engine” for defect and non-compliance discovery to drive the GitOps model. Telemetry can be fed to the source control platform where teams use it, and consumed from Concourse where they don’t yet use such a tool.
Organizations’ ability to encode their compliance drivers and secure coding and infrastructure standards into the platform, and the platform’s ability to translate that declarative policy into the necessary checks for a cloud service provider’s myriad APIs, means that organizations get consistent policy enforcement across a broad range of technology stacks, middleware, and service points. Concourse encodes policy and checks declaratively, just as GitOps prescribes, and provides the traceable accountability, versioning, and other features Git provides source material for policy and governance — a natural complement.
Pursuing a GitOps model of security governance assures security leadership a seat at the table in DevOps cultures. Adopting a platform such as Concourse Labs to enhance and augment the security governance will directly facilitate and complement the model.
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
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..
