What’s the fuss with ‘Compliance as Code’ ?

What’s the fuss with ‘Compliance as Code’ ?

Today, I wanted o bring in a different topic to what we’ve been discussing so far in the blog, and that is the concept or idea of ‘Compliance as Code’.

In recent years, and with the increased adoption of DevOps, another of the feedback loops that had to shorten in order to enable speed and agility for organisations, particularly ones under heavy regulations, was to ensure that Developer and Engineers get immediate feedback on how compliant with those laws and regulations what they created is. If your organisation is using Continuous Integration or Continuous deployment, they already have this immediate feedback loop for functional testing, so why not security and compliance ?

Providing an example, if you work in developing software for medical applications, there are a number of compliance regimes you need to be compliant with, so you’d want your developers and engineers to know sooner rather than later, that something they produced would be a red flag for compliance, implying it would need to be re-done at a later date and before servicing actual customers, bringing both direct costs and opportunity costs (the cost of not working on he next feature, for instance).

‘Compliance as Code’ can be summarised as the organisational capability to automate the implementation, verification, remediation, monitoring and reporting of compliance status. This automation comes in the form of code, and integrated into the code repositories used by Devs and Engineers. It becomes “just another piece of code”.

Before providing some examples and bringing it to life, let’s compare it to the typical current practice:

Security Requirements > Development > Testing is Done > Checklist against requirements > Penetration test to validate

What this typically means, if you’ve worked in Compliance long enough, is that send you send a bunch of requirements in a list (spreadsheets galore) to Engineering or Development teams which are typically copy/paste across all your organisations projects, implying little detail or context, then after all the development and testing are done you (may) get an opportunity to check the list against what was actually delivered, but even so you’ll typically dozens if not hundreds of requirements which ended up not being met make it to your Penetration test report (if you’re into that kind of thing), which then you’ll scream and shout at the organisation trying to remediate stuff before GoLive.

You can probably tell I’ve lived through that one too many times. 🙂

When Compliance IS Code, especially in Agile or DevOps environments, that feedback loop relating to Devs, Engineers and Compliance can be shortened to close to real time any time a developer commits code to their project repositories (that’s the beauty of Continuous Integration).

In order to do Compliance as Code, the job to be done is to codify your policies into tests which the software must/should pass for successful integration. The difference between must and should here is critical.

Until you’re mature enough, you should aim to add “Guard Rails” so nothing gets into production without all the required compliance checks. So, a “must” if it’s something important or critical.

For day to day code submissions to develop a test or development environment, and because you don’t want security to be the ones hindering speed and agility, it “should” pass the tests but everyone can probably live with them failing, provided the outputs of the compliance tooling used are informing the creation of backlog items which are to be delivered before the solution can go into Production.

A typical modern Software Development Lifecycle looks like this:

Plan > Code > Build > Test > Release > Deploy > Operate

Let’s see how Code can be used to integrate compliance into these different activities (note that this isn’t meant to be exhaustive list but an introduction):

Plan — This is the area that I believe is currently lagging in terms of maturity compared to the other SDLC stages. There are Open Source solutions out there like Security RAT which lets you create your security requirements as code so they can be integrated into each software project as an auditable artifact. I haven’t used it, but plan to in the future.

Build — You probably have within your dozens of security policies the following 2 statements in some form: Secrets and password must not be stored in the application code and Components and libraries used for software development must not have known high severity vulnerabilities. Assuming you do, you can codify those policy statements into the development pipelines by invoking a few software tools to help you achieve those. For scanning secrets, you can use Open Source tools like Trufflehog, Git-Secrets or Gitty Leaks. In order to codify the policy statement regarding components and libraries, you can use Open Source software like retireJS for Javascript libraries or OWASP Dependency Check

Test — Here we can go all-in in terms of codifying our unique environments and this is what is typically referred to as Compliance as Code.

My tool of choice for this is Inspec by Chef and I’ll soon be dabbling in Open Policy Agent, particularly it’s ConfTest module.

You get the ability to define what you’re looking for, and set an expectation to the information that should be there. For instance, if you have a requirement to only have SSH version 2 on your Linux servers and running over port 22, this is what the Inspec test would look like:

Using these tools in Build stage, means that Developers (and if you get to the party soon and get access to the output of these tools when they’re run) and Compliance can get immediate feedback on how compliant the recent submissions were. I’ll do a series of more technical blog posts on how to use and develop some of these tools, but don’t feel daunted as there are many pre-built profiles out there already that you can readily use. Another great resource is the page Dev-Sec.io, which has a collection of Inspec profiles for typical use cases.

And you also get as output a report that tells you how compliance to the CIS Linux baseline it is, for example:

Deploy — typically here you want to ensure systems deployed are hardened following industry best practices such as the CIS benchmarks.

To perform this hardening, you also have dozens of tools to make it happen. If your organisation already uses IT automation Frameworks such as Chef, Puppet or Ansible and have your Deploy process apply them every time “one of those” is built. What I mean is that every time a new NGINX, Linux VM, Docker container or whatever ‘thing’ you’re building, you can ensure that those are provisioned following those guidelines and it’s easy to check if they’re not.

You can also find dozens of playbooks or recipes in Dev-Sec.io to apply

Conclusion

Hopefully this was helpful to illustrate what Compliance as Code is and what it means to you. If you’re a Compliance expert either a) working for organisations that use Compliance as series of boring meetings and spreadsheets or b) Compliance expert working for an organisation adopting DevOps, then there’s something for you here.

If a) please think how you can leverage the IT automation your organisation is already doing so you start getting some actual telemetry and visibility into your environment, and not just what people are telling you.

If b) then know if you’re not doing Compliance as Code, you’re not speaking the same language as your stakeholders and will one day come back to bite you. You’ll keep being perceived as outsider who doesn’t understand their job, and what’s that DevOps promised it would fix. It still hasn’t for most of us.

Finally, understand that the Risk and Compliance professional of the next decade (the one’s who will strive and be in high demand) are the ones that have the ability to codify their requirements as code so that their organisations can leverage those artefacts across their teams at scale and which ultimately enable Compliance to be just another element of Quality Assurance in the software your organisation delivers. No one can afford an army of Compliance people nor should they have to.

If you’re not comfortable with anything on a Command line, I suggest now is the time to add that to your learning and development plan before you risk your skills becoming irrelevant in the marketplace.