Compliance checks with GitHub Actions

OptiTech provides a GitHub Action that runs your compliance checks in CI: every pull request is evaluated against the controls you select, violations fail the check before merge, and passing runs land in the evidence log as change-management evidence. The reasoning behind the pattern is covered in compliance checks on every pull request; this page is the setup.

Getting started

The action authenticates with an API key scoped to CI checks.

Set up your repository

1. Create an OptiTech API key. In the Console, go to Settings > API keys and create a key with the CI checks scope. See API key for scoping guidance.
2. Add the key to GitHub. In your repository, go to Settings > Secrets and variables > Actions, click New repository secret, name it OPTITECH_API_KEY, and paste the key.
3. Add your workspace ID as a repository variable named OPTITECH_WORKSPACE_ID. You find it under Settings > General in the Console.

If you connected the GitHub integration, the org-level secret and variable can be provisioned for all selected repositories at once, and repository controls (branch protection, reviews) are already being verified continuously; the action adds the per-PR gate on top.

Add the workflow

Create .github/workflows/compliance.yml:

name: Compliance checks
on:
  pull_request:

jobs:
  compliance:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run OptiTech checks
        uses: optitech/compliance-check-action@v1
        with:
          api_key: ${{ secrets.OPTITECH_API_KEY }}
          workspace_id: ${{ vars.OPTITECH_WORKSPACE_ID }}
          mode: advisory # or: blocking
          comment: true # post a summary comment on the PR

What the action does per run:

• Evaluates the diff (and, for infrastructure repos, your terraform plan output if you pass it via plan_file) against the mapped controls: exposed storage, weakened IAM, disabled encryption or logging, and your custom rules.
• Reports pass or fail as a check run; in blocking mode, required-check branch protection stops the merge.
• Posts a summary comment listing each evaluated control and its result, so reviewers see compliance status inline.
• Logs the run as timestamped evidence against the mapped controls.

Advisory first, then blocking

Start in advisory mode: checks run and report, but nothing blocks. Fix the recurring findings, tune thresholds through the reviewed change process, then switch stable checks to blocking and mark the check required in branch protection. From that point, compliance regressions can't merge.

In monorepos, scope checks per path so one service's violation doesn't block unrelated teams:

with:
          api_key: ${{ secrets.OPTITECH_API_KEY }}
          workspace_id: ${{ vars.OPTITECH_WORKSPACE_ID }}
          paths: 'infrastructure/**,services/payments/**'
          mode: blocking

Other CI systems

The same checks run anywhere the CLI runs: see Compliance checks with CircleCI, the GitLab CI pattern, and Terraform for managing the platform configuration itself as code.