Neviar Rawlinson, MBA

Posted on Nov 24

Automating Compliance Checks in CI/CD Pipelines with Rego

#cicd #opa #devsecops #rego

In a modern DevOps environment, compliance can't be a last-minute audit concern. It needs to be embedded in every deployment pipeline.

That’s where Policy as Code (PaC) and tools like Open Policy Agent (OPA) and its language Rego come in.

Why Automate Compliance in CI/CD?

Manual compliance reviews don’t scale. They’re slow, error-prone, and often ignored when deadlines approach.

Automating compliance in your CI/CD pipeline enables:

Early detection of violations
Faster, safer deployments
Fewer audit issues
Alignment with DevSecOps

What Is Rego and OPA?

OPA is a general-purpose policy engine. It runs policies written in Rego, a declarative language purpose-built for defining and evaluating rules.

Use cases include:

Kubernetes admission control
API and microservice authorization
Terraform plan validation
CI/CD compliance gates

A Real Example

Let’s say your policy is:

All S3 buckets must be encrypted at rest.

In Rego, that becomes:

package s3.policy

deny[msg] {
  input.resource_type == "s3_bucket"
  not input.encrypted
  msg = "S3 bucket must be encrypted at rest."
}

You feed this into OPA with your Terraform or infrastructure input. It returns violations before you deploy.

Add to CI/CD (GitHub Actions Example)

Here’s how to automate the check:

name: OPA Compliance Check

on:
  push:
    branches:
      - main

jobs:
  opa-check:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Install OPA
        run: |
          curl -L -o opa https://openpolicyagent.org/downloads/latest/opa_linux_amd64
          chmod +x opa
          sudo mv opa /usr/local/bin/

      - name: Run OPA Policy
        run: |
          opa eval --input input.json --data policy.rego "data.s3.policy.deny"

Swap input.json with your actual config input.

Scaling Compliance Coverage

To scale this across environments:

Organize policies by domain (IAM, S3, network, etc.)
Test policy logic as part of PR checks
Visualize violations in dashboards
Involve security and GRC in early stages

GRC Teams Can Still Participate

Even without coding, GRC professionals can:

Define governance rules to enforce
Validate technical policies cover critical risks
Review violation trends
Partner with engineers in policy design

Rego and OPA make it possible to embed compliance into your pipelines, not after the fact, but during development.

By shifting compliance left, your teams reduce risk and build trust across the SDLC.

You don’t need to be a developer to drive compliance forward.

But you do need to understand how policy is being enforced.

Have you used Rego in your CI/CD pipeline? Share your use case or lessons below!

DEV Community