What's Inside

A trending topic for the past few years, compliance as code is the practice of deploying security and compliance checks and validations to monitor for security vulnerabilities and compliance gaps throughout the software development lifecycle. It allows its practitioners to know that security guidelines are present and being adhered to on their projects from the very beginning. 

At face value, this approach amounts to having tools check your code to ensure that it complies with security, compliance, and privacy standards. This alone is an incredibly useful practice for assisting with security and compliance, but expanding the concept and implementation can achieve even deeper benefits for your organization.

Using the same channels that DevOps has brought to automating the deployment of infrastructure and code, it is possible to ensure that security and compliance are built into the software development lifecycle (SDLC). Embedding compliance as code into your SDLC with technologies that assess your infrastructure resources and configurations can highlight areas of concern and create a security-first mentality within your development teams.

In this guide, we examine compliance as code, explain the benefits it brings to teams, explore how a deeper application of the practice can raise your standards of security company-wide, and share some best practices, common tools, and mindsets you can adopt to help your team immediately. 

Summary of Key Compliance as Code Best Practices

Streamline Audits with Compliance as Code

Compliance as code provides your development teams with a tool to automatically validate whether their code is acceptable given the organization’s internal standards or the standards of a specific security or privacy regulation. Depending on the organization's domain and the nature of the system, adherents may be required to any of a variety of compliance standards. 

Some standards are based on the operational specifics of a company. For example, online services, especially those with sensitive user information, should aspire for SOC 2 Type 2 compliance. Groups that deal with medical records must prove that they are HIPAA compliant. Other standards are dictated by the location of a company, its customers, or its data. Europe has created the GDPR standard for data protection, and California has created the CCPA and CPRA regulations.

Inside any given certification’s audit process, there are hundreds of controls that correspond to strategies or specific requirements for the construction or configuration of your systems. These controls address a multitude of concerns across your entire system’s stack:

• Are there any SQL injection vulnerabilities in the code? 

• Is data appropriately encrypted, and does the app ensure minimum necessary access?

• Do any staff have inappropriate permissions, or are there any ex-employees with access? 

These examples demonstrate just a handful of the security concerns that might exist anywhere from your code to your data strategy and infrastructure to your HR practices. Performing an audit to validate your organization’s compliance must be thorough and require a review of every element of your security strategy and procedures. Implementing these controls manually and reviewing every new change for them would require significant amounts of development time. At scale, this is not a sustainable way to maintain compliance.

Compliance as code was developed to quickly review code to ensure that known compliance violations aren’t present. The tools that can validate this can also be combined with an automated deployment process, which can massively simplify the effort it takes to identify and resolve issues before they end up deployed and causing actual problems. In larger systems, especially ones that aim to stay compliant across multiple standards, utilizing these tools and strategies becomes nearly mandatory to keep up with every change.

Once your system is set and you’re ready to begin or review your compliance with an auditor, the output of these tools also doubles as a resource to quickly demonstrate your adherence to the standards.

Shift Left with Automation

Thinking about implementing compliance as code requires understanding the languages, frameworks, resources, and environments that your organization is currently using. Security should take a proactive approach in identifying what those are and helping shape organizational decisions on which new strategies to adopt and when. This ties in well with the concept of shifting left, which means taking the paradigm of security as far to the “left” of the development and deployment process as possible. Ideally, you consider security at the very outset of planning and even when giving new team members orientation.

Keeping security at the forefront of the development process allows you to stay ahead of changes and additions and be prepared to secure them. Consider the common adage: “An ounce of prevention is worth a pound of cure.” This approach will end up costing you less resources and time than trying to add and implement security concerns reactively, i.e., only starting once the work is done.

Getting involved in planning and reviewing new projects’ requirements will help you and your teams better understand how to integrate the new work into your framework with plugins, tools, or necessary libraries. Making this research mandatory for the approval process of a new project will help your team stay ahead of new technology, keep your organization secure as it grows, and reduce the amount of time and tech debt that teams would encounter if they had to figure out how to implement security right as projects near their launch date.

Even further left than the planning phase itself would be your hiring and training practices. While this doesn’t typically get attention as a vector for security, training your developers on security before they even set the keyboard to code is technically the earliest stage where you can intervene with a security strategy. 

Fit Into Existing Infrastructure and Software Development Workflows

Development teams can seamlessly integrate compliance as code throughout the entire software development lifecycle, from local development to production deployment. This integration enables continuous scanning and validation of code at critical checkpoints: during the writing process, before code commits, prior to deployment, and after deployment in production environments.

A well-established practice involves implementing compliance and security scans within the deployment pipeline. Teams operating on cloud platforms benefit from an extensive ecosystem of built-in tools and plugins designed to assess compliance requirements and maintain environment security. These tools can be effectively integrated into deployment pipelines, providing automated compliance validation.

Security-focused CI/CD tooling enhances deployment safety by preventing the release of code that introduces security vulnerabilities or lacks essential logging and monitoring capabilities. Modern deployment platforms have fostered the development of specialized compliance and security tools. For example, Jenkins offers a rich marketplace of security plugins, while GitHub Workflows provides Actions developed collaboratively by tool authors and community contributors. These integrations create streamlined pathways for implementing compliance scans and monitoring their results for potential violations.

Infrastructure as code (IaC) provides another vector for your team to add compliance as code. Besides utilizing these tools to review your software code, you can also apply the checks and validations to infrastructure code to keep that element of your system in compliance.

Setting up the appropriate configurations and supplemental resources for your infrastructure is essential for security. Many security flaws can be detected in a code scan before the resources have been created and deployed. These issues include open public network access, a lack of encryption on resources, or insufficient logging, auditing, alerting, or retention for those logs established. Preventing those scenarios (and more!) from getting deployed out to production environments by default is a huge boon for your entire organization’s security posture.

Stay Up-to-Date

Our earlier points demonstrate how compliance as code can help bring your security standards to the forefront of your development teams’ minds. Incorporating these practices can also help bring your environments up to a higher standard of security once these validations and tools are in place. Continuing to utilize compliance as code helps ensure that standards stay in place, and constant monitoring allows you to be notified if there are any new vulnerabilities that target resources managed by your organization.

One scenario where this comes in handy is when a new CVE is discovered for a container that you use. The tools you use to monitor compliance should receive an update in their validations and point out the issue as soon as your tool is updated, potentially before your team is aware of the CVE through manual research. Since this notification would be delivered to your development team in the course of a PR or regular validation run, they would immediately have the information necessary to begin finding an implementation that would satisfy the potential violation. All of this short-circuits the need to discover this vulnerability, assess where it may be occurring in your system, and notify the relevant teams of the need for a fix.

Additionally, many of these tools can help you generate and automate the creation of reports detailing the completeness and validity of your security implementation. You can have an overview of the performance of your teams sent directly to your inbox, rather than needing to investigate the status of security manually at regular intervals. You can also build tools to feed this directly into a public or client-facing security synopsis. 

Compliance as code brings you more complete security and saves you the time and resources needed to design a custom reporting strategy and toolset from scratch. For example, SOC 2 Type 2 requires monitors and alerts to be set for cloud resources. If the development teams are responsible for creating an alert on whatever they create, you just need to communicate a shared standard for those, which makes building a dashboard to monitor resources across teams much easier. This not only prevents your team from deploying infrastructure that would be out of compliance but also helps you maintain a standardized strategy for logging and reporting since every team has to adhere to the same minimal requirements.

Integrate Across the Entire SDLC and Centralize Reporting

Like all DevOps processes, compliance as code is effective only when integrated with other tools used in the code release lifecycle. That's why it’s important to rely on a tool that supports native integrations with all popular tools. 

The benefit of setting up an abundance of integrations is that it will expand your security monitoring coverage and easily maintain standards across your services. Creating a Venn diagram of coverage over your internal services and practices can help you find the shortcomings of certain scanning tools and ensure that each area of concern is comprehensively tested and reviewed. Additionally, the automation of compliance scans across your teams will make monitoring and maintaining appropriate security more accessible, and that ease of use will encourage attention to security throughout your teams.

Ultimately, with thorough coverage, you can tie all of these different tools and monitors into a unifying security framework. Drata is one such platform and has set out to offer as extensive a set of integrations as possible, as well as its compliance-as-code tool that allows teams to establish policies, resource requirements, and infrastructure standards. This has built-in alerting to direct the issue to the right team and the capability to design auto-fix pull request (PR) creation. 

No matter which service you use, the benefits of having all of the monitors and reviews reported to a central system are immense. 

Additional validation, testing, monitoring, and reporting are all great improvements to any process, but making sure that these efforts become habits and get interwoven with your team culture will set a strong foundation for good security. As new employees join your development teams, they’ll be walking into a situation that leads them directly to best practices. Compliance as code provides the tangible benefits of increased, measurable security and helps your organization level up its security chops as a whole.

Adopting the strategy of compliance as a code for your organization can help an organization maintain compliance with every release and reduce the risk of failing audits, while building a better development process that allows developers to prioritize compliance and address issues without leaving the dev environment. Security is an element of your organization that shouldn’t operate reactively, and finding ways to inject it into the code layer allows you to think proactively about your standards and strategies. It’s also an element you can’t afford to get wrong, so rather than risking security thoroughness and doubling back when a problem is found; include the validation of your security with every code release.