---
title: "Why building compliance into your code will benefit your entire company"
author: Vanessa Wegner
author_gitlab: vwegner
author_twitter: gitlab
categories: insights
image_title: '/images/blogimages/compliance-as-code-header.jpg'
description: "Build compliance into your code to streamline the DevOps lifecycle."
tags: collaboration, code review, DevOps, security, testing, workflow
twitter_text: "How to get started with compliance as code"
featured: yes
postType: content marketing
cta_button_text: 'Join us at our first user conferences in Brooklyn and London!'
cta_button_link: '/events/commit/'
---

Compliance, both regulatory and self-imposed, is another area where the shift-left
movement has taken hold. By building compliance into your workflow, your
team can save time while producing secure, low-risk code.

## What is compliance as code?

Compliance as code methods ensure that the correct regulatory or company
compliance requirements are fulfilled with zero-touch on the path to production.
It builds compliance into development and operations.

This type of minimal-friction compliance is a crucial solution for large
enterprises – especially those subject to complex regulation (such as enterprises
operating in healthcare or financial services). By building compliance into the
DevOps lifecycle, you will streamline the workflow and save developers valuable
time during review and testing.

## Implementation requires collaboration and transparency

As [Jim Bird wrote for O’Reilly](https://www.oreilly.com/learning/compliance-as-code),
compliance as code policies must be defined up front, and will bring together
management, compliance, internal audit, PMO, and infosec leaders. This group
will work together to define rules and control workflows. Management also needs
to understand how operational and other risks will be handled throughout the
pipeline.

How your company does establish compliance as code policies [will depend on how your team is structured](/blog/2019/06/12/devops-team-structure/)
but regardless of how your teams interact, transparency is required. To ensure
that information is shared and decisions are made collaboratively, consider
establishing the following guidelines:

- **Peer reviews**: The first review cycle for larger changes should be manual, to
ensure no changes are made without at least one other person verifying the
change. Reviewers can be assigned randomly to ensure the quality of review.
- **Static application security testing**: [Static
(or white box) testing](/blog/2019/08/12/developer-intro-sast-dast/) should be done for every code change, in addition to
manual reviews.
- **Subject matter expert reviews for high-risk code**: For code that the management team defines as
high-risk (such as security code), changes should be reviewed by a subject matter
expert.
- **Regulated access controls**: Management should keep access in check, both so that
changes aren’t made by a single engineer, and so that every change flows through
the workflow and can be reviewed by anyone with access to the dashboard.

### Enhance technology with culture

Technology and processes will only work if your team cultures are aligned with your goal – and culture starts
at the top. Team leaders should promote and exemplify a security-first
mentality and openness to collaborative change. This will be a new way of
thinking for some, but it will help teams adopt the shift-left trend, ultimately
saving everyone time and reducing business risk.

### Compliance and open source

In 2015, [The Linux Foundation found that more than 60% of companies build products with open source software](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/), but more
than half of those companies don’t have formal procedures in place to ensure their
software complies with open source licenses and regulations. Companies should
create a free and open source software (FOSS) compliance program not only to
abide by copyright notices and license obligations, but also to protect company
IP and third-party source code from disclosure.

## How we do compliance at GitLab

We [began our formalized compliance program](/blog/2019/05/07/choosing-a-compliance-framework/)
towards the end of our Series C funding round, which was fairly early compared
to other businesses of our size. The benefit of starting early was that we were
able to implement security controls while we were still developing and evolving
our operating processes, instead of retrofitting security to the business. The
key decision in our approach was choosing between independent or aggregate
security controls: We chose the aggregate route, leveraging [Adobe’s CCF](https://blogs.adobe.com/security/2017/05/open-source-ccf.html),
rather than implementing industry frameworks individually. This allowed us to
mitigate overlapping asks to GitLab teams, which enabled an agile and efficient
program standup, and gave the compliance group internal credibility.

## Compliance as code provides benefits across your ecosystem

There are benefits to everyone from the developer to the third-party auditor when compliance is baked into code from the beginning. These benefits include:
- **Time saved**: Your
teams will spend less time passing code fixes back and forth.
- **Compliance transparency**: Management will
understand where and how your software abides by compliance requirements.
- **Routine reporting streamlines auditing**: Reports throughout the DevOps lifecycle provide documentation and proofs of
record that will help management track and streamline any regulatory audit
procedures.

Cover image by [Hack Capital](https://unsplash.com/@hackcapital?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/code?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)
{: .note}