A developer’s guide to implementing Policy as Code

In 2022, the adoption of infrastructure as code (IaC) soared, with IaC domain specific languages like HCL, Shell and GoLang gaining popularity and momentum across the open source tools ecosystem. In fact, the rise of Policy as Code is the result of a new paradigm blurring the lines between IT, legal and R&D departments – everything as code.

But what do developers have to do with compliance and infrastructure provisioning? What does PaC entail, and what types of PaC are there? Where does a developer start their policy coding journey, and what tools and skills will they need to bring along? Let’s explore the answers in this blog.

What is Policy as Code?

Policies are rules, guardrails, and instructions that define and enforce particular user and application behaviors. Policies in software development can be applied in various areas, including:

1. Security, for example: ensuring all S3 buckets are encrypted at rest with SSE-S3 encryption
2. Compliance, for example: ensuring all EC2 instances are tagged with a Department and Owner tag
3. Governance, for example: ensuring that IAM users have MFA enabled 

When you think about it, policies are everywhere. An organization, its software development lifecycle, and the product have multiple policies that must be maintained and enforced without impacting operations. 

Traditionally, policy management entails defining policies in natural (human) language or other non-machine-readable formats (such as spreadsheets, documents, or verbal instructions). These policies are typically enforced manually by personnel responsible for monitoring and enforcing compliance with said policies. 

While this approach may work for things like corporate dress codes, it becomes much more challenging to manage when it comes to more risky and costly compliance regulation violations, such as access to critical systems and sensitive data.

Unlike manual policy management, PaC configures policies in machine-readable code, such as YAML, JSON, vendor-specific DSL, or Python, and enforces them through automated tools and processes. 

This approach enables policies to be defined and enforced more consistently and efficiently while reducing the risk of human error and improving the auditability of policy enforcement.

Benefits of PaC and what’s in it for developers

Compared to traditional policy enforcement, PaC offers several benefits, including:

1. Improved consistency: Policies defined as code can be enforced consistently across multiple systems and environments, lowering the risk of misconfigurations or errors due to manual intervention.
2. Faster feedback: Policy violations can be detected and remediated faster by implementing PaC, reducing the time to detect and mitigate compliance and security issues.
3. Increased automation: PaC enables the automation of policy enforcement, reducing the need for manual intervention and improving overall operational efficiency throughout the organization.
4. Greater audibility: PaC provides a more auditable trail of policy enforcement, making it easier to ensure ongoing compliance and identify issues before they become threats.

You may be thinking: okay, this is all nice, but shouldn’t this be left for IT, infosec, and compliance teams to handle? Isn’t PaC just additional work for developers? The good news is that PaC can significantly contribute to developers’ productivity. 

Here are just a few examples of policies developers can employ in their work:

1. Code Quality and Conventions: Policies that enforce code quality standards (like consistent coding style, formatting, and naming conventions) can help developers write easier code to read, maintain, and debug. It also ensures a more common ‘language’ convention among the organization’s developers so that they can all interact more easily with the code base and onboard new team members with minimal effort.
2. Testing: Enforcing testing standard policies (like requiring unit tests and integration tests before code is merged) can help ensure that code changes are properly tested and validated before deployment. While some developers may not instantly love this policy, they will see its benefits in the long run in the form of fewer crashes and bugs in production.
3. Continuous Integration and Deployment (CI/CD): Testing is not the only step you can (and should) enforce in your pipelines. You can codify policies that apply CI/CD standards that you define, from requiring code to be reviewed by other developers to ensuring that all code changes go through a standardized build and deployment process.
4. Vulnerability Scanning: Last but not least are code security policies. Policies that automatically scan code repositories for vulnerabilities, misconfigurations, and exposed code secrets can help identify security issues early in development. This enables developers to address these issues before the code is deployed to production, preventing expensive mistakes.

Ultimately, codified policies in your SDLC aim to enable developers to write higher-quality code more efficiently and confidently while improving the system’s security, maintainability, and compliance. All by doing what developers do best: code. 

Types of PaC: Static Vs. Dynamic Policies as Code

We can divide the types of policies you can apply as code into static and dynamic categories.

Static policies as code are defined and enforced at the time of deployment. Once the policy code is deployed, it usually remains unchanged until the next deployment cycle. Static policies are usually defined in configuration files or scripts and enforced by IaC tools.

Dynamic policies as code are policies you can update and enforce dynamically during runtime. Dynamic policies are often defined in code within the application or service and can be updated through APIs. Dynamic policies can be more flexible and responsive than static policies, allowing organizations to adapt to changing requirements and threats.

What you need to get started with PaC

1. Define the policies you want to encode

Start by identifying the policies you want to enforce before you define them in a machine-readable format. At this point, it’s worth sharing the responsibility of setting and enforcing policies between teams in your organization. Unless you’re part of a small startup, there’s no reason for a developer to be charged with creating and enforcing policies for things like network security.

Based on the policies you want to enforce, you’ll need to choose how you define them. For example, policies that interact with your development environment might be defined in your SCM. Policies in your pipeline may be implemented with whatever tool you use for CI/CD. Data protection should be configured to your Cloud, and so on. 

2. Select a PaC tool (or tools)

Various tools on the market could help you set up and enforce PaC. Common ones to consider include:

1. Open Policy Agent (OPA), an open-source policy engine that allows you to define, evaluate, and enforce policies across your infrastructure and applications. It’s written in a high-level DSL called Rego, a language unique to OPA that you’ll need to master if you wish to employ this tool. Rego is designed to be easily readable and writable by developers and security teams, but it can be a bit difficult when first grappling with it. OPA is vendor-agnostic and can integrate with a wide range of tools and services (including two tools in this list).
2. AWS Config, an Amazon-managed service that provides a detailed view of the configuration of your AWS resources and can help you ensure compliance with your organization’s policies. It provides a set of predefined rules that you can use to evaluate your resource configurations against best practices and industry standards. AWS Config also supports custom rules you can define using AWS Lambda functions.
3. Chef Compliance, a tool that allows you to define, test, and enforce policies across your infrastructure. It provides a DSL called InSpec, which allows you to write policies in a human-readable format. Chef Compliance integrates with Chef Automate, a platform for managing and automating your infrastructure, to provide end-to-end visibility and control.
4. Terraform Compliance, a tool that enables you to enforce policies on your IaC templates defined in Terraform. It supports several policy engines, including OPA and Rego, and allows you to define policies using a variety of formats, including YAML and JSON. Terraform Compliance supports several compliance frameworks, including CIS and NIST.

When selecting a PaC tool, it’s important to consider factors like ease of use, compatibility with your existing stack, support for the policies and compliance frameworks relevant to you and your organization, and the level of automation and integration you require.

3. Integrate with your development process

Once you have defined your policies and selected a tool, you must integrate PaC into your development process. This could involve configuring your CI/CD pipeline to validate policies at build time, integrating policy checks into your testing process, or using PaC tools to monitor and enforce policies at run-time in production.

4. Continuously improve

PaC is an iterative process, and you should continuously monitor and update your policies to adapt to changing requirements (such as regulations) and threats.

Shifting policies left with confidence

PaC can help you work more efficiently and confidently while improving the security, compliance, and reliability of the code base, the environment it’s built on, and the applications built with it. By incorporating PaC into your daily work, you can help ensure that your code is of the highest quality and meets the needs of the organization and its end users.

With Spectral, developers can define and enforce regulations and best practices (including GDPR, PCI, and others) throughout the SDLC. Spectral enables developers to integrate their own playbooks, build their own detectors, and implement mitigation policies to automate code scanning, including codified policy.

Schedule a demo to learn more about how Spectral can streamline your code security policy implementation and enforcement.