How to implement PaC for a more secure SDLC

Policy-as-Code (PaC) — designed to write and manage security policy code that can be automatically tracked, tested and enforced — is rapidly shifting from an emerging concept to a strategic priority for a growing number of organizations. However, putting it into practice remains a challenge for many teams.

Key hurdles include a lack of familiarity with policy languages like Rego, fragmented tool ecosystems, and the ongoing struggle to align application security, compliance, and engineering around a unified, codified approach to policy.

The PaC approach, which is typically focused on coding in organizational policies for identity and access management (IAM), infrastructure, compliance and audit, is gaining traction because manual policy management just can't up with the speed, scale and complexity of modern cloud-native systems.

Organizations are also adopting PaC to improve consistency, reduce human error, and enable real-time enforcement of security and compliance controls directly within their development and deployment workflows.

Here's what your application security team needs to know about PaC — and key considerations for implementation.

Download Today: The 2025 Software Supply Chain Security Report

PaC is more than automation and infrastructure

Ashley Ward, principal solution architect at Minimus, said PaC covers two big ideas: First, it’s about turning an organization’s policies into something machines can understand and act on. Second, it’s about treating those policies like code: version-controlled, testable, and integrated across the development lifecycle. "That means anyone working on software or infrastructure can pull in those policies and apply them automatically," Ward said.

PaC isn't about automating enforcement. It's true value lies in shifting policy checks and validation earlier in the development lifecycle and providing visibility and consistency to the process. PaC allows teams to understand and apply policies early, whether those are related to security, compliance, cost controls, or operational guardrails, Ward said. The key difference between PaC and traditional policy enforcement lies in when the checks happen — and who is able to make them.

A static document describing security rules isn’t PaC because it’s not machine-readable, testable, or enforceable in an automated way. Someone with the right context has to read through human-written guidance and figure out what it means in practice, meaning policy enforcement often happens right at the end just before a change goes into production, Ward said.

With manual reviews or static checklists, the effort to interpret and apply a policy is high. At that point, you either delay go-live while you fix something, or you let a non-compliant change through. Neither outcome is ideal, and both create unnecessary risk.

Ashley Ward

PaC is also not just about the infrastructure. It covers the entire application stack, Ward said. While infrastructure compliance is a common use case, PaC doesn’t replace Infrastructure-as-Code (IaC) tools like Terraform or Helm. "Instead, it works alongside them as a distinct layer, enabling organizations to apply, test, and manage policies in a controlled and scalable way," he said.

PaC can operationalize Secure by Design

The goal with PaC is to embed security and compliance checks directly into the earliest stages of the development process. The idea is that by baking policies right into code and CI/CD pipelines, teams can automatically catch misconfigurations, enforce security guardrails, and stop risky changes before they go live.

Shane Barney, chief information security officer at Keeper Security, said that PaC allows security to be built in from the beginning, rather than added in later. It ensures that policies, whether they’re tied to access, encryption or configuration, are consistently applied across systems and environments.  

This makes Secure by Design a reality and not just a concept. It also helps bridge the gap between security and development by providing guardrails that support development at speed without compromising safety.

Shane Barney

From a leadership perspective, policy-as-code is an important part of driving both accountability and efficiency at scale, he said.

Jason Soroko, senior fellow at Sectigo, said to think of PaC as turning organizational rules into executable text that travels with the repository and runs in the pipeline. Unlike checklists or peer review, PaC is about inspecting every commit at machine speed.  

It behaves like unit tests for risk and gives reproducible outcomes that auditors can rerun. Shifting these rules left makes design lapses fail fast, so fixes cost little.

Jason Soroko

Why OPA is key to PaC implementation

Organizations have several options for implementing PaC, depending on their environment and use cases. Examples include tools like Kyverno for Kubernetes and other cloud native environments;  HashiCorp Sentinel, which is tightly integrated with Terraform and Vault; Conftest for validating configuration files; and Checkov, primarily for infrastructure. Cloud vendors too offer tools for implementing PaC—such as Cedar from and Azure Policy as Code from Microsoft. While each of these toolsets can help organizations implement PaC, they are typically designed for specific platforms and use cases.

That's one reason why a growing number of organizations are coalescing around Open Policy Agent (OPA), an open source policy engine that lets teams write rules — like who can access what — in code and apply them across different systems. OPA eliminates the need for building policy logic into every application or service. It allows teams to manage policies separately and have each app or system ask OPA for decisions based on those polices.

As the application security leader Derek Fisher noted recently in a post: "Instead of hardcoding rules into your services, you write them in Rego, OPA’s declarative policy language." Then, the services query OPA to get decisions like whether a user can access a specific resource, or whether Kubernetes deployment is secure or whether a Terraform plan might be violating any security guardrails.

PaC can decouple policy from code and runtime environments greatly simplifying the cloud-native setups, Fisher told RL Blog. Using a tool like OPA, policies can validate IaC, container configurations, or Kubernetes manifests before deployment and continue to make real-time decisions as services spin up and scale down, Fisher said. 

"As environments shift, centralized policies provide consistency without needing to embed brittle rules in every microservice. This means you can enforce least privilege, secure defaults, and compliance across clouds without rewriting app logic each time."

Derek Fisher

OPA has become the default tool for PaC because it’s general-purpose, open-source, and vendor-neutral, said Minimus' Ward. It is also now a graduated Cloud Native Computing Foundation (CNCF) project, meaning it has strong community backing, and the project meets CNCF’s strict requirements, as noted in the project documentation: "OPA integrates well with a wide range of systems like Kubernetes, Envoy, Terraform, and most CI/CD platforms."

That said, Rego isn’t the easiest language to pick up, Ward noted. Rego has a steep learning curve, especially for those familiar with something like YAML (Yet Another Markup Language). "For simple use cases, OPA can feel like overkill. It often requires some scaffolding around it for things like result formatting, or integration with existing developer workflows," Ward said.

Ian Botbyl, security strategist at Qwiet.ai, said PaC excels when used in coordination with DevOps workloads such as infrastructure provisioning, pipeline enforcement, containers, and API authorization. Any workload not limited by latency — such as a trading apps or a gaming app — would be a good use case for PaC noted, he said.

What are the best use cases for PaC?

Despite these implementation challenges, the effort put into PaC pays off when applied to the right use cases. The key is identifying scenarios where automated policy decisions can happen without disrupting performance-critical operations.

PaC excels when used in coordination with DevOps workloads such as infrastructure provisioning, pipeline enforcement, containers, and API authorization noted Ian Botbyl, security strategist at Qwiet.ai. In fact, any workload not limited by latency — such as a trading apps or a gaming app — would be a good use case for PaC. 

It's important for organizations to first build a foundation for DevOps with a decentralized operating model within their AppSec teams. Then adopt IaC and attempt PaC. Once those have been established, you should have less friction creating a policy lifecycle that includes all the phases of the SDLC with ownership from AppSec, Botbyl said. 

Fisher said the build stage is where PaC delivers the biggest bang for the buck. By integrating PaC early, organizations have the opportunity to catch security issues before they progress further in the pipeline. This shift-left approach prevents insecure containers, open IAM permissions, or non-compliant IaC templates from becoming headaches later. "A byproduct of this integration is the increased speed as development teams trust that the CI/CD pipeline enforces clear, codified rules, and security teams spend less time on late-game audits."

Ultimately, it's the places where stakeholders find themselves having to make a lot of repetitive decisions that PaC delivers the most returns by way of consistent, automated guardrails, Ward said. The key is not to go too wide, too fast. When teams write a slew of rules without understanding how they impact workflows, bad things can happen and PaC ends up slowing everyone down, he said.

Getting it right means collaboration. Security teams need to adopt the same development practices they expect from engineering: version control, automated testing, clear documentation. Developers need to see PaC not as red tape, but as a way to catch issues early and avoid last-minute blockers at release time.

Ashley Ward

How should you start implementing PaC?

Teams looking to implement PaC should start with the basics. Focus on the policies that matter most across the organization before attempting to embed them into code. Teams should then be given the flexibility to adapt or extend them where it makes sense and make sure everything is transparent, Keeper Security's Barney advised. "People need to know when a policy is triggered and why, and they should have a straightforward way to respond," he said.

What's key to remember is that PaC isn’t just a technical framework, but a way to strengthen trust between security and the rest of the business, Barney said.

When PaC is seen as something that helps teams move faster and safer, it becomes much easier for organizations to scale.

Shane Barney