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 breaches 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 the standards necessary for security and data privacy certifications. This alone is an incredibly useful practice to assist 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. 

Streamline Audits with Compliance as Code

Compliance as code provides your development teams with a tool they can use to automatically validate whether their code is acceptable given the standards of a specific security or privacy regulation. Depending on the domain of the organization and the nature of the system, it may be required to adhere 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? 

• Are data resources appropriately encrypted and do they maintain policies of least privilege 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 needs to 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.

Decide How Far Left to Shift

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. Think of 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. 

Plug In Everywhere

There are a variety of ways to leverage compliance as code. One common pattern is to execute compliance and security scans during the deployment pipeline. If your team runs on cloud resources, there are often many built-in tools and plugins to help you scan and assess your compliance requirements and environment security. These can often be referenced or integrated within a deployment pipeline.

More complex security and CI/CD tooling can even block code from deployment if it adds security flaws or doesn’t provide sufficient logging or monitoring. Deployment pipelines have had compliance and security tools created specifically for their use. For instance, Jenkins has plugins, and Github Workflows has Actions developed by tool authors and the community. These offer simple ways to insert these tools’ scans and screen their results for compliance violations.

Example of a GitHub Workflow YAML file that runs ‘CodeQL’ analysis, a ‘gitleaks’ scan, and a ‘ShiftLeftSecurity’ scan on the code when a pull request is triggered on the ‘main’ branch.

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. It flips the existing strategy of researching new vulnerabilities and investigating where they may affect you; in this scenario, your resources volunteer that information directly to you.

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.

Use Integrations Liberally to Tie Everything Together

Compliance as code is becoming standard across the industry, so you can expect to find an auditing tool for just about any component of your teams’ efforts. As many of these tools have become mainstream, we’re seeing methods to integrate most of the more popular ones into the development pipeline as well as allowing you to build an automated scan for security and compliance review across every relevant procedure.

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. Integrating this tooling can be accomplished simply by adding a GitHub action.

Reap the Benefits Holistically

Ultimately, by leveraging the tools and practice of compliance as code, you and your organization will see strengthening, simplification, and increased comprehensiveness of your security posture. Utilizing the right tools for your frameworks and building them into your pipelines and requirements will set the bar high for what ends up being deployed to production. 

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 bring a significant amount of value and security thoroughness to your practices. 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.