Compliance Without the Chaos: Building It Right Into Your DevOps Pipeline

Compliance Without the Chaos: Building It Right Into Your DevOps Pipeline

Speakers: Varun Gurnaney

Conference: BSidesSF 2025 — April 26-27, 2025, San Francisco

YouTube: Watch on YouTube

Reading time: ~8 minutes

TL;DR

Compliance teams are stuck running painful, manual evidence-collection cycles while the DevOps pipelines they rely on already generate exactly the data they need. Varun Gurnaney argues that embedding compliance checks directly into CI/CD pipelines — and building a purpose-built compliance data layer to consume them — can eliminate most of that pain without requiring engineers to change how they work.

Introduction

Varun Gurnaney describes himself as a security engineer who became an "accidental compliance therapist." His career started on the engineering side — writing Android and iOS apps — took a sharp turn into ISO 27001 vendor audits ("painful" is how he describes that experience), and eventually landed at the intersection of the two. His mission: make engineers hate compliance less.

The premise he presented at BSidesSF 2025 is that compliance teams and engineering teams are locked in a slow-motion collision. Audits require evidence. Evidence requires engineering time. Engineers resent compliance pulling them away from product work. The compliance team apologizes but keeps asking. Rinse, repeat, every six months — or more often, since most organizations juggle multiple compliance frameworks simultaneously: SOC 2, GDPR, PCI DSS, SOX, NIST CSF.

The fix Gurnaney proposes does not require anyone to change their tools or their workflows. It requires compliance teams to stop asking for evidence manually and start consuming the evidence that DevOps pipelines already produce.

Understanding What Compliance Teams Actually Do

▶ Watch: Compliance lifecycle and engineering partnership (05:00)

Before proposing a solution, Gurnaney laid out the problem in structural terms. Compliance work falls into two cycles. The first is achieving compliance: kickoff meeting, gap assessment, remediation, internal validation, certification. The second is the audit: pre-assessment, sampling (auditors typically want evidence for 5–25% of controls), validation, close.

Engineering teams are involved at almost every stage — gap assessment, remediation, sampling, validation. That involvement is mandatory because the evidence is in the systems engineers build and operate. The problem is that "involvement" usually means compliance walking over to engineering and asking someone to export a log, run a query, or take a screenshot to prove a control exists. That is an interruption, it is manual, and it does not scale as both the frequency of audits and the complexity of the infrastructure grow.

The ambitions of a compliance team are not unreasonable — they need to demonstrate that controls are operating as designed. The question is where the evidence for those controls comes from. Gurnaney's argument: it is already being generated, in machine-readable form, by every piece of the DevOps stack.

Compliance In the Pipeline vs. Compliance Of the Pipeline

▶ Watch: CIP and COP framework (14:00)

Gurnaney introduced a conceptual framework built around two distinct compliance responsibilities, each with different tooling and scope:

Compliance In the Pipeline (CIP) — Automated scanning and policy enforcement embedded in the CI/CD pipeline itself. Every artifact that moves through the pipeline is checked before it reaches production. This is the "TSA PreCheck" model: if the deployment is clean, it flies through. If it carries a suspicious YAML file or violates a policy, it stays on the ground.

Compliance Of the Pipeline (COP) — The compliance posture of the DevOps infrastructure itself. The Jenkins instance, the Kubernetes clusters, the container registry, the Spinnaker deployment tool — these all need to be secure and compliant, not just the workloads they manage.

The distinction matters because conflating them leads to gaps. An organization might have rigorous automated scanning of every container image (CIP) while the Kubernetes control plane running those containers has RBAC misconfigured and MTLS disabled between services (COP). Both need to be addressed.

For CIP, Gurnaney described the tooling chain for a representative control: "Only containers from authorized registries may be deployed." In Kubernetes, every pod deployment passes through the admission controller — effectively the nightclub bouncer for the cluster. By deploying OPA Gatekeeper (the Kubernetes-specific instance of Open Policy Agent), teams can write declarative Rego policy rules that the admission controller enforces. A container image pulled from an unauthorized registry triggers the policy, the deployment is blocked, and OPA generates a decision log. That decision log flows into the organization's logging platform and from there into whatever compliance tooling is consuming it.

Crucially, compliance teams do not need to write these rules from scratch. Gurnaney noted that modern LLMs are capable of writing Rego policies given a natural-language description of the control — a practical bridge between compliance requirements and engineering implementation.

A Concrete Example: Change Management via Spinnaker and Halyard

▶ Watch: Change management evidence from CI/CD tooling (20:00)

For the COP side, Gurnaney walked through a second example: demonstrating change management controls for Spinnaker (a CI/CD tool used by many large engineering organizations).

Spinnaker deployments are managed via Halyard, a configuration management tool. Halyard tracks every change made to the Spinnaker configuration — who made the change, when, and what changed. Change management as a compliance control requires demonstrating that infrastructure changes follow an approved, authorized process with a documented audit trail. Halyard's logs contain exactly that information: timestamps, user identity, and change descriptions.

The compliance insight is that the data already exists. Compliance teams do not need to ask engineers to do extra work. They need to know where to look, how to pull the relevant fields, and how to map them to the control requirements they are trying to satisfy.

Gurnaney generalized this pattern across the full DevOps stack: GitHub commit history, Jenkins build logs, Docker image registries, Kubernetes audit logs, Spinnaker deployment history. Every tool generates timestamped, attributed logs. The compliance job is to collect that data, serialize it into a unified evidence store, and map it to control requirements.

Building Compliance Tooling That Actually Works

▶ Watch: Compliance tooling requirements — evidence, audit logic, monitoring (26:00)

The final section of the talk addressed what good compliance tooling actually looks like — whether built in-house or procured from a vendor. Gurnaney identified three core capabilities:

Evidence collection. The tooling needs to be able to connect to the organization's logging platforms and data lakes, filter and query across large datasets to produce compliance trails, and chain events across tools. A change management audit trail might require correlating a git commit (with a timestamp and author) to a Jenkins build (with its artifact hash) to a Kubernetes deployment event — three separate systems, one coherent narrative. The tooling must be able to stitch these together automatically.

Scalable audit logic. Not all compliance frameworks want the same depth of evidence. SOC 2 might accept a screenshot demonstrating a vulnerability management program exists; PCI DSS wants every individual vulnerability with triage and remediation timestamps. Gurnaney used the analogy of packing a bag for travel — a carry-on for a day trip, two suitcases for three weeks abroad. Compliance tooling needs the equivalent: the ability to scale the evidence artifact set up or down based on which framework is being assessed. Crucially, this logic should be baked into the tooling, not reconstructed manually before each audit.

Continuous monitoring. Compliance posture changes daily as infrastructure changes. Finding a control failure two weeks before an audit is far better than finding it during the audit — but only if the monitoring is actually running continuously. Gurnaney also emphasized the need for point-in-time assessment snapshots: a CISO who needs to present compliance posture to the board on Monday morning should be able to pull a dashboard view as of a specific date, not just the current state.

The data architecture underlying all of this is a compliance data lake — separate from, though potentially drawing from, the security data lake. Compliance teams should own this data rather than relying on security teams' infrastructure to tell them what is passing and failing.

Notable Quotes

"I'm a security engineer who turned into an accidental compliance therapist." — Varun Gurnaney (02:00)

"Think of admission controller as a nightclub bouncer. If your container is on the allow list, you're getting in the club. Otherwise you're not." — Varun Gurnaney (18:00)

"Take these tools to your compliance team and tell them this is what we have. Can you please reuse this information versus coming to us with your questions?" — Varun Gurnaney (35:00)

Key Takeaways

• CI/CD pipelines already generate the evidence compliance teams need. The gap is collection and mapping, not data generation — which means compliance automation is primarily a tooling and process problem, not an infrastructure problem.
• CIP and COP are distinct disciplines. Compliance in the pipeline (automated enforcement of deployment standards) and compliance of the pipeline (security posture of the DevOps infrastructure itself) must both be addressed, and they require different controls.
• OPA Gatekeeper is the practical lever for Kubernetes CIP. It connects directly to the admission controller, enables declarative policy enforcement, and generates auditable decision logs — all of which feed directly into compliance evidence workflows.
• Compliance tooling needs scale-up/scale-down logic. Different frameworks require different evidence depths; tooling that produces one level of detail for all frameworks creates either over-disclosure or insufficient coverage.
• Build a compliance data lake. Compliance teams should own their evidence store rather than depending on security data infrastructure — serializing events from all DevOps tools into one queryable layer and building pass/fail status against controls from that data.