Every organisation has security policies. Most of them live in a SharePoint folder that nobody reads, updated once a year during an audit, then ignored until the next one. The problem isn't that engineers don't care about policy — it's that policy documents are the wrong format for enforcing decisions at the moment they're made.
Governance as code is the practice of expressing policies as structured, version-controlled, machine-readable rules that integrate into the development workflow. When a developer makes an architecture decision, the governance framework runs alongside them — not against them.
The GATEKEEP framework
GATEKEEP is our internal governance framework, open-sourced as a markdown specification. It covers five decision categories: security, cost, design, deployment, and data. Each category has a checklist of questions. The answers produce one of three verdicts: Approve, Reject, or Defer.
The key insight is that governance doesn't need to be a bureaucratic process. It needs to be a fast, consistent decision aid that fits inside a pull request review. A five-question checklist that takes 90 seconds to run is infinitely more effective than a 40-page policy document that nobody runs at all.
From checklist to code
A checklist in a markdown file is better than a PDF. But a checklist enforced by automated tooling is better still. There are three levels at which governance can be encoded:
Level 1: Structured checklists
Markdown-based decision trees, linked from PR templates and architecture decision records (ADRs). Engineers run them manually, but the structure ensures consistent coverage. This is where most teams should start — low overhead, high signal improvement.
Level 2: Policy-as-code linters
Tools like tfsec, checkov, and trivy parse
Terraform/CloudFormation and flag violations against known policy libraries (CIS, NIST, SOC 2).
These run in CI and block merges on high-severity findings.
The ticketyboo.dev scanner implements a subset of this for free — no installation required.
Level 3: Open Policy Agent (OPA)
For organisations with complex, cross-cutting policies, OPA evaluates Rego policies against structured inputs (Terraform plans, Kubernetes manifests, API gateway configs). This is powerful but has a meaningful implementation cost — appropriate for teams beyond ~20 engineers.
What the scanner checks
When the ticketyboo.dev scanner analyses a repository, the governance category checks for:
- Missing CI/CD pipeline (no
.github/workflows/or equivalent) - No test suite detected (
tests/,test_*.py,*.test.ts) - No README at repository root
- No SECURITY.md or vulnerability disclosure policy
- No CODEOWNERS file (means anyone can merge to main)
- Branch protection not configured (detectable via GitHub API)
Each finding links to the relevant GATEKEEP section and includes a concrete remediation. Governance findings are rated medium by default — they don't break production, but they represent compounding technical and organisational debt.
Architecture decisions as first-class artefacts
The most underrated governance practice is the Architecture Decision Record (ADR). An ADR is a short document (one page) that records: the context of a decision, the options considered, the decision made, and the rationale. Stored in version control alongside the code, ADRs create an auditable trail of why the system looks the way it does — invaluable during incident response, audits, and onboarding.
# ADR-001: Use SSM Parameter Store instead of Secrets Manager
## Status: Accepted
## Context
We need to store a GitHub PAT for API authentication. Two options: Secrets Manager ($0.40/secret/month)
or SSM Parameter Store SecureString (free, AWS-managed KMS key).
## Decision
Use SSM Parameter Store SecureString for all new secrets.
## Consequences
No automatic rotation (acceptable — PAT can be rotated manually on compromise).
SecureString values do not appear in Terraform state (created via CLI).
Saves ~$4.40/month vs existing 11 Secrets Manager secrets.Governance at ticketyboo scale
This platform deliberately runs on a single AWS account, a single Lambda function, and a DynamoDB single-table design. At this scale, governance is lightweight by necessity: a GATEKEEP checklist for each infrastructure change, automated scanning in CI, and a documented deviation log for any intentional deviations from the standard patterns.
The deviations are as important as the policies. Blindly following a governance framework designed for a 500-person enterprise will produce unnecessary complexity in a two-person project. The goal is appropriate governance — enough to catch real risks, not enough to slow down every decision.