Blog Insights Why building compliance as code in DevOps will benefit your entire company
August 19, 2019
6 min read

Why building compliance as code in DevOps will benefit your entire company

Read here on how to integrate compliance as code into your DevOps cycle and why it's important to have in your business

compliance-as-code-header.jpg

Compliance, both regulatory and self-imposed, is another area where the shift-left movement has taken hold. By building compliance into your workflow with compliance as code methods, 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.

The utilization of compliance as code tools enable stakeholders to ensure that production procesesses are compliant by means of defining how resources must be configured. Such a structure often allows these tools to automatically adjust resources into a compliant state in order to meet these pre-defined compliance requirements.

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.

Benefits of compliance as code

Adopting compliance as code brings a number of advantages and new operational capabilities.

  • It’s easier to stay compliant during compliance rule change periods. When a change happens in regulatory compliance frameworks, awareness and remediation of any issues happen more quickly because teams don’t have to manually overhaul processes or re-train.
  • More natural alignment between developers and risk assessment teams. There is more unity between teams when the compliance controls are already defined as code. It’s then possible to embed compliance rules into delivery processes and enable compliant delivery by default.
  • ** A lot of time and money saved.** Automation cuts out costly and time-consuming manual work. When automated compliance as code is in place, there’s a reduced risk of costly fines and data breaches.
  • It’s all scalable. Adopting compliance as code means adopting consistency across teams and an organization, regardless of size. This consistency prevents ambiguity and bottlenecks in maintaining compliance.

Challenges of compliance as code

DevOps means experiencing changes often and quickly, and despite the benefits that automated compliance as code brings, it can also be a challenge. It can sometimes be difficult for security to keep up with the speed of change.

And sometimes, even automated compliance as code isn’t perfect. It’s important to remember that there’s no cap on how careful you should be when it comes to DevOps compliance. Despite having automation in place, a pair or two of human eyes open to keep watch is still useful – even if it means a possible increase in human error.

How to impliment compliance as code

As Jim Bird wrote for O’Reilly, 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 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 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, 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 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, 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.

Common compliance as code tools

Google Cloud Platform, Amazon Web Services, and Azure are all cloud services that can be used in compliance as code. And oftentimes, these tools are even more effective when paired with native tools.

Through proper tool adoption, the three core actions of a compliance strategy can be automated: prevention, detection, and remediation.

Cover image by Hack Capital on Unsplash

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

New to GitLab and not sure where to start?

Get started guide

Learn about what GitLab can do for your team

Talk to an expert