What is Policy as Code?

Overview of Policy as Code

Policy as code (PaC) is the practice of defining security, compliance, and operational rules as version-controlled, machine-readable code that automated engines test and enforce before changes reach production.

The idea behind policy as code is that it replaces static documents and much of the manual review work with an automated process. Not only does this save you time, but it also reduces the risk of manual error when reviewing changes. An engine evaluates changes based on the defined rules to help reduce security and compliance risks automatically.

Policy as code evaluates three main components:

• Policy: The defined rules that the engine uses to test changes.
• Data: The environmental context or state.
• Query: The specific action that triggers the evaluation.

Policy as code replaces written documentation and much of the manual review work with rules written in programming languages. When changes are made to an application or infrastructure, an engine automatically tests those changes using the predefined rules. Any violations are blocked or flagged for review automatically.

Codifying rules is crucial because cloud and CI/CD environments often scale beyond what manual review can handle. Using predefined rules and automated tests allows you to validate changes in these larger, more complex environments.

What is the Difference Between Policy as Code, Infrastructure as Code, and  Compliance as Code?

You may hear policy as code, infrastructure as code, and compliance as code used interchangeably. While these terms are often conflated, they’re three separate concepts.

Infrastructure as code

Infrastructure as code (IaC) provisions servers, networks, and databases to help you set up systems. This allows you to quickly build identical test and live systems, track changes, and reduce manual mistakes during setup.

Compliance as code

Compliance as code maps validation to regulatory frameworks. Policies, controls, and audits are embedded directly into code, so code is tested for compliance risks the same way it’s tested for security risks.

Policy as code

Policy as code (PaC) validates changes and enforces compliance and security guardrails. When applications are changed or deployed, they’re automatically scanned by engines that block or flag any changes that violate the rules you’ve defined in your code.

While PaC, IaC, and compliance as code are distinct concepts, they’re closely intertwined. Infrastructure as code provisions servers, networks, and databases to automate the setup process, reducing the risk of human error and making it easier to track changes. Policy as code validates any changes that are made within that environment using codified policies. Compliance as code continuously tests your code for compliance risks, supporting end-to-end security and compliance efforts.

You may also hear the term security as code. This refers to embedding security checks directly in the SDLC to identify potential threats before they cause harm.

Integrating policy as code, infrastructure as code, and compliance as code is a core aspect of shift-left security. The goal is to implement security and compliance into the earliest stages of the secure software development lifecycle (SSDLC) to catch potential issues as early as possible.

How Does Policy as Code Work?

Policy as code relies on codified policies and a policy engine that evaluates policies, data, and queries. Teams use policy engines like Open Policy Agent and languages like Rego to define policies and automate validation.

The policy is written in a language like Rego or YAML. Security teams must define specific policies and store them in a repository. The data is in the form of a JSON or a structured object that captures the current system or environment state. The query is the automated call that’s made to the policy engine that triggers it to review changes against policies.

Common policy engines include Open Policy Agent (OPA), HashiCorp Sentinel, and Kyverno. Different policy engines use different languages and offer unique benefits. Open Policy Agent uses Rego, while Kyverno uses YAML.

Policies run at several points throughout the software development lifecycle. CI/CD pipeline gates serve as checkpoints where code is validated against defined policies. Policies can also be integrated directly into the Kubernetes admission control phase, and cloud provision checks can identify policy violations before setting up cloud infrastructure.

There are different types of enforcement modes for policy as code, so violations aren’t always blocked automatically:

• Warn: This enforcement method flags any policy violations for manual review, saving you the time of manually reviewing each piece of code while still allowing for human oversight. Flagging policy violations is ideal during the policy rollout stage.
• Block: This enforcement method blocks code changes that violate policies, preventing changes that may result in risks. Blocking code is ideal for mature policy violations.

What are the Benefits of Policy as Code?

Implementing policy as code makes it easy to stay on top of code changes and track violations, but what does that do for IT teams? Learn more about some of the key benefits of policy as code:

• Consistency: Applying a single, authoritative rule set across teams and environments results in more consistent policy reviews. This reduces human bias; every change in scope is checked against a predefined set of rules, and any violations are flagged or blocked automatically.
• Speed: Policy as code enables rapid deployment because it reduces the need for manual approvals and long review queues. Code is automatically reviewed against the policies you’ve defined, so teams can focus on development instead of constantly reviewing code or waiting for approvals.
• Auditability: Policy as code can provide a version-controlled, timestamped record of policy decisions for use in an audit. This can make it easier to gather records if you’re audited.
• Risk reduction: By automatically checking code against policies, you can identify misconfigurations and violations before deployment.
• Compliance readiness: The detailed audit trail policy as code creates can also serve as evidence for SOC 2, GDPR, HIPAA, and PCI DSS audits, which can help you prepare for an audit.

Common Policy as Code Tools and Engines

There are a variety of tools IT teams use to implement and enforce policy as code. Tools use different languages and offer different features, so choosing the right policy as code tool can help you achieve the best results.

• Open Policy Agent (OPA): OPA is a widely used open-source, cloud-native policy as code tool. OPA uses its own Rego policy language, and there is extensive documentation available because of its popularity.
• HashiCorp Sentinel: HashiCorp Sentinel is tightly integrated with Terraform, Vault, and Consul, making it a good choice for IT teams who are already using these tools.
• Kyverno: Kyverno is a Kubernetes-native option. Policies are expressed as YAML rather than using a separate language, so IT teams that use Kubernetes should feel familiar with Kyverno.
• Conftest: Conftest also uses the Rego policy language to test policies against configuration files and IaC templates in CI.

Choosing the right solution for your team can simplify AI governance and security, so it’s important to evaluate your needs when choosing a policy-as-code tool.

Policy as Code Across the Software Supply Chain

Policy as code is often seen as a validation solution for infrastructure, cloud, and compliance, but it also plays a role in the artifact layer. Policy as code should gate the binaries, containers, and open source packages that make up the software, not just the software itself.

• Policy-gated artifact promotion is designed so that only artifacts that pass the policy checks move from development to staging to production repositories.
• Package curation policies can block vulnerable or license-non-compliant open source packages before they enter the pipeline, reducing downstream risk.
• Security and license policies can be enforced at the binary and container level, not just the IaC template level.
• SBOMs and provenance evidence can act as policy inputs, feeding upstream data into downstream policy decisions.

Best Practices for Implementing Policy as Code

Implementing policy as code effectively is an important part of achieving the best results. IT teams should follow best practices when implementing PaC, including:

• Start policies in “warn” mode before switching to “block” to help keep delivery smooth
• Keep policies modular, reusable, and stored in version control alongside application code
• Write policy test cases before deploying policies to production
• Scope policies narrowly to avoid false positives that erode developer trust
• Combine static (pre-deployment) and runtime (post-deployment) checks for in-depth defense.

How JFrog Helps Enforce Policy as Code

JFrog goes beyond the IaC template level to enforce policy as code at the artifact layer. Instead of treating policy enforcement as a pipeline-only concern, we apply it continuously to the binaries, containers, and packages that make up the software supply chain.

Here’s how JFrog helps enforce policy as code:

• JFrog Curation automatically blocks non-compliant or vulnerable open-source packages from entering the pipeline if they violate policy rules.
• JFrog Xray can evaluate security and license policies against the artifacts and container images it is configured to scan, failing builds or blocking promotion when policy conditions aren’t met.

Schedule a demo or start a free trial to see how the JFrog Platform can help automate security and compliance policy enforcement across your software supply chain, from open-source packages to production-ready artifacts.