Open Policy Agent (OPA) is a policy engine that streamlines policy management across your stack for improved development, security and audit capability.
Impact of Using OPA
We used OPA to enforce security and quality policies before releasing software in one of my projects.
OPA changed our go/no‑go from a subjective meeting ritual into a transparent, automated, and explainable decision system that teams can trust. This blog explains what changed in our process, how we wired OPA into our SDLC, and our learnings and takeaways.
Before OPA: Go/No‑Go As A Meeting
Used to be long meetings close to release where people debated risk, readiness, and “gut feel.”
- Checklists in spreadsheets, inconsistent across teams and projects.
- Security, architecture, and compliance criteria existed in docs and weren’t integrated into CI/CD.
- Exceptions were handled via email, weakening audit trails.
- Questions like: “Did we run all tests?”, “Is performance signed off?”, “Are production configs compliant?” was randomly asked, and their answers varied.
In short, we did “go/no‑go” as an event, not as a continuous, evidence‑driven decision.
Reframing Go/No‑Go As Policy
OPA brought a shift in our mindset, treating go/no‑go as a policy, not a meeting.
- Translating our release criteria into policy‑as‑code using OPA’s Rego language: what tests must pass, who can approve which environments, what risk controls must be satisfied for a “go.”
- Rules becoming explicit: minimum test coverage, security scan thresholds, infra guardrails, migration approvals, change‑ticket link checks.
- Centralized logic, allowing pipelines and services to query the same policies.
- Version‑controlling policies enabling traceability and change history.
Conceptually, OPA became our policy decision point, while our CI/CD and deployment tools acted as enforcement points that call OPA before allowing a step to proceed.
Wiring OPA Into the Pipeline
Technically, the transformation happened because we put OPA directly into the CI/CD flow, turning “go/no‑go” into a real gate.
- In CI, we used OPA to evaluate test results, coverage reports, and static analysis outputs, failing the pipeline if policies were violated (for example, coverage below a threshold or high‑severity issues).
- For infrastructure and configuration, OPA validated manifests (Terraform, Kubernetes, app configs) to enforce security and governance rules before deployment.
- In deployment pipelines, a dedicated “Release Eligibility” job built a structured input (who is deploying, to which environment, what change type, what risk tags) and asked OPA for an allow/deny decision.
- Depending on the answer, the pipeline either continued to deploy automatically (“go”), blocked with a clear reason (“no‑go”), or routed to a manual approval step for exceptions.
A simple but powerful example: only users with the right role could deploy to production, and only after all mandatory checks passed, as expressed by a few Rego rules rather than scattered scripts and documentation.
How Our Go/No‑Go Actually Changed
Once OPA was in place, the nature of our go/no‑go changed in several important ways.
- Continuous gating vs. one‑time gate: Every commit and every pipeline run effectively performed a mini go/no‑go, so the formal meeting became a confirmation, not a discovery session.
- Evidence‑driven decisions: OPA decisions were based on structured inputs, test data, scan results, and change metadata, rather than memory or status slides, and decision logs captured what rule fired and why.
- Consistent enforcement: The same policies applied across teams, services, and environments, eliminating the “policy depends on who you ask” problem.
- Clear exceptions: When a “no‑go” was overridden, we treated the exception itself as policy data (for example, a temporary waiver with scope and expiry), keeping the process auditable.
In practice, our go/no‑go meetings became shorter and more strategic because automated policy checks already handled the mechanics.
Organizational Impact and Lessons Learned
OPA reshaped how teams collaborated around risk and compliance.
- Security and compliance teams started contributing directly to Rego policies and tests, eliminating static guidelines.
- Developers received faster feedback on policy violations inside their pipeline.
- Audits improved with policy versions, decision logs, and release inputs.
Conclusion
If you still treat go/no‑go as a calendar event, OPA is a strong way to encode your criteria as a living, executable policy, turning your release decision into something that is engineered, consistent, explainable, and continuously enforced instead of debated at the last minute
