Policy as Code — Enforce Compliance Before Infrastructure Deploys
Compliance reviews that happen after deployment are too late. By the time a security team discovers an unencrypted database or a public S3 bucket, the damage window has already opened. Policy as code shifts compliance left — into the PR workflow where violations are caught, flagged, and blocked before they reach any environment. We implement policy frameworks using OPA, Sentinel, Checkov, or Pulumi CrossGuard that enforce your organization's rules automatically.
Need this done for your project?
We implement, you ship. Async, documented, done in days.
Why Policy as Code
Every organization has infrastructure rules, even if they are not written down. "No public S3 buckets." "All databases must be encrypted." "Production instances must be in private subnets." "Every resource must have a cost-center tag." These rules exist as tribal knowledge, enforced inconsistently through code review, and violated regularly when someone is in a hurry.
Policy as code takes these rules and expresses them as executable checks that run automatically in your CI/CD pipeline. A developer opens a PR that adds an S3 bucket without encryption — the pipeline catches it immediately, posts a comment explaining the violation and how to fix it, and blocks the merge. No security review delay. No back-and-forth. The feedback is instant and specific.
The policies themselves are version-controlled, peer-reviewed, and testable — just like your infrastructure code. When a new compliance requirement arrives (SOC 2 mandates encryption at rest for all data stores), you add a policy, and it is enforced across every future change automatically. Past violations are caught by running the policy against your existing codebase.
Policy Frameworks We Implement
Checkov / tfsec: The quickest to implement. These tools come with hundreds of built-in checks covering AWS, GCP, and Azure best practices. We configure them in your CI pipeline, set severity thresholds (block on HIGH and CRITICAL, warn on MEDIUM), and write custom checks for organization-specific rules. Custom checks are written in Python (Checkov) or YAML (tfsec), making them accessible to most teams.
OPA (Open Policy Agent) with Conftest: For teams that need complex, cross-resource policies. OPA uses the Rego language to express policies that can reason about the entire Terraform plan — not just individual resources. Example: "The total number of NAT Gateways across all VPCs must not exceed 4" or "If a resource is tagged as PII, it must be in a VPC with no internet gateway." Conftest runs OPA policies against Terraform plan JSON output in CI.
Sentinel (Terraform Cloud/Enterprise): HashiCorp's native policy framework for Terraform Cloud users. We write Sentinel policies that integrate directly into the Terraform Cloud run workflow. Sentinel has the advantage of running between plan and apply as a first-class step, with advisory and hard-mandatory enforcement levels.
Pulumi CrossGuard: For Pulumi users, CrossGuard policies are written in the same language as your infrastructure code. A TypeScript policy can validate TypeScript infrastructure with full type safety. Policies run during pulumi preview and pulumi up, blocking non-compliant changes.
Common Policies We Implement
We implement policies across four categories:
- Security: No public S3 buckets, no security groups allowing 0.0.0.0/0 on SSH/RDP, all EBS volumes encrypted, all RDS instances encrypted, no IAM policies with wildcard actions, CloudTrail enabled in all regions, VPC flow logs enabled.
- Networking: No public IPs on instances in private subnets, all ALBs use HTTPS listeners, WAF attached to public-facing load balancers, no overly permissive CIDR blocks in security groups.
- Cost: Instance types restricted to approved list (no accidental
x1e.32xlarge), mandatory auto-scaling on compute resources, S3 lifecycle policies required on all buckets, unused Elastic IPs flagged for removal. - Tagging: All resources must have
environment,team,service, andcost-centertags. Tag values must match a predefined list. Resources without required tags are blocked from deployment.
Each policy includes a clear error message explaining the violation and a link to documentation showing how to fix it. Developers should never see a cryptic policy failure — they should see exactly what is wrong and what to do about it.
Why Anubiz Engineering
Ready to get started?
Skip the research. Tell us what you need, and we'll scope it, implement it, and hand it back — fully documented and production-ready.