Most people in the modern software defined infrastructure space have at least stumbled upon the term GitOps.

In short - at least in the head of your's truly - GitOps is an evolution from infrastructure as code. Basically it means consistent, controlled automatic deployments and updates of your infrastructure based on git pull/merge requests and CI/CD tools.

What?

Well, there are a few things going on here. First, I assume that you are aware of the basic infrastructure as code ideas. You use automation tools to set up your whole IT infrastructure using a variety of tools, some of which may be Terraform, Kubernetes, Ansible, Puppet, Chef, cloud libraries, etc. The state of your system is in a source code repository, as configuration code.

Let's say you have all this code available. Excellent. Now you need to put your code to work. You'll use this code to do deployment, change management, testing, etc. I need to scale up my web server amount? Run code. I need to deploy my QA infra from scratch? Run code. I need to change that one filesystem mount parameter. Run code.

You can manually trigger all these code deployments from e.g. your dev laptop, but you can also automate a lot of it.

The tool often used for this automation is git via a repository management service like Github, Gitlab or Bitbucket. These offer not only repository hosting, but also pull or merge requests (I'll use the term PR for the sake of simplicity), which are basically code review and approval processes for bringing in new code. In addition you get webhooks, which are automatic triggers based on changes in the repository, e.g. the creation, approval or merging of PRs.

With these hooks you can trigger external tools for automatic code testing before a PR can be approved, trigger automatic deployment of the code after PR is merged etc.

There is tons of material of this on the internet, so I'll if you want to know technical details, open your favourite search engine and dive in.

Uhm, the blog title says Compliance management

Yes, yes, we're getting there. So let's answer the question.

What does all of this have to do with compliance management?

A lot of compliance work (be it ISO27k1, another IT standard or some domain specific regulations) is documenting processes, making sure the processes are followed, leaving traces of these processes, and having different levels of sign-off on different processes or documents.

These git repository management services (but, alas, not git itself) have developed tooling to do exactly these things - for code. The features have not primarily been developed to follow standards, but they happen to be an excellent fit for that.

I guess.. if you say so, give me an example

Ok, this is a fictional example of document management. Let's take a somewhat easy one, the business continuity plan (BCP) of an IT service, including the risk assessment.

Let's say your company's policy is that the BCPs have to be approved by the service owner and the head of security. We'll start from a process that is not very mature. The company has the BCP in a word document which gets edited mainly by devs (I call them devs, in your world they might be something else, the ones who know the service/product in and out) and sent around for approvals by email (btw, I guarantee your devs hate this). Approvals are traces in the email that these documents have been approved. The document might even be approved in some meeting, with traces of this in the minutes.

This process is slow, hard to follow, hard to verify, and also doesn't support the involved parties by bringing the important information to the forefront.

Let's start by taking some pain away. Let's put this simple workflow in git, using the same word document. The goal is to have tools for the people who know the service to update the document, for the service owner to approve, suggest changes, and for the head of security to sign off on it.

• First create a repository. I won't go through the exact details as they differ per platform. The repository is owned by the service owner.
• Protect the master branch. That is, the only way of getting something into the master branch, is using PRs.
• Configure PRs for your repository so that each PR must have two approvals, and the the service owner and the head of security are eligible to approve PRs.

That's basically all the configuration you need to do (there are more advanced multi-level approvals you can set up if your use case demands it).

New versions of the documents are always uploaded to a newly created development branch. When the next version of the BCP is ready for approval, the devs create a PR. The service owner makes sure the changes are ok, comments, suggests edits, edits them himself, etc. All discussion is done within the PR's discussion tool. Once it looks good, the head of security can approve of the PR, and it can be merged.

So what was the result? You have the document, all discussions around the document, and approvals in one place, which has an user interface which is well suited for this. All discussion gets logged, we know who changed the document when, we know exactly who approved it and when. This basically implements your process in the repository manager, and provides the changes, approvals and logs out of the box. Suddenly we have removed a lot of the pain in changing this document.

Ok, that's somewhat simple, is that it?

Oh no, we're just getting started. Downloading and uploading the word document for changes is clunky, and it doesn't use git to its full extent.

The next step is to take the word document and just paste it into a file in git in the markdown format. All editing is done in raw text. No more uploading or downloading documents is needed.

Comparing versions of text (code) is exactly what git is meant for. For our purpose you'll see diffs of all the document changes directly in the PR view, you can easily make small edits in the web interface, and as the git repository mangers handle markdown natively, it'll render as a proper document. You can add a PDF generation step if you want.

Even better! Now it's easier than ever to edit the document and see what has changed.

Add a sprinkle of gitops

I'm pretty sure your devs are happy with you at this point, but we can take it a bit further and help the head of security. Let's say we have the risk evaluation in some specified form in the document,e.g. you have a table of risk probability X severity and get a risk score for each risk.

Risk	Probability	Severity	Score
Somebody misunderstands the blog	5	1	5
I get absorbed in writing the blog and forget lunch	3	3	9

It's not hard to write code that gets triggered on each commit, and highlights all risks with a score of let's say 10 or more. Now we have not only helped the dev team, we have helped the head of security to quickly see the major risks with each service.

Now, depending on what kind of document you're writing, you can probably do tons of automation to do sanity checking of the document (e.g. make sure each risk has a probability and an impact score), help highlight important information, or to do something else which is relevant to your specific document.

By adding some git workflows to our clunky compliance process, we have not only made the process clearer, it also leaves much better trace, the changes in content are easier to follow, and best of all, the tools are good, and the people who should use them are familiar with them.

Admin user management process

Document control is not the only facet of compliance work that can be mapped to git workflows. Another example is admin user management.

A quite common thing for a service is to have a whitelist of admin users. This list might need to be approved by the service owner.

Now we can do the exact same thing in git for this list of users. Have a repository with the names and usernames of your admin users in a format that's compatible with your configuration management. Any changes to this list can only be approved by the service owner.

When a change to this list is approved, via a PR again, you can trigger an update to your systems. Bonus points if you add sanity checks that e.g. there is at least one valid admin (so bad typos don't cause too big problems), and that all user accounts exist.

Extra bonus points if you include this git repository to your automatic deployment workflow, and all changes get deployed automatically.

Super extra bonus point if your deployment workflow also automatically fetches all provisioned provisioned admin users from the system, and compares them against the whitelist to make sure that the deployment worked properly, there are no extra users there for some reason. You'll also get a trace of the actual state of the system.

Here again you get all the perks of the tooling, minimal overhead to the service management processes and great traceability with proof of the current status of the system.

Integration to company systems

There are always the nasty practicalities like "Who's actually the service owner, and how do our systems know it?". Usually your access and identity management system.

Luckily there are quite decent identity integration options for these services, and e.g. GitLab and BitBucket can be self hosted if you don't want this data in the hands of third parties.

There are also other cool things you can do, e.g. sign commits, verify merging PRs with a password, requiring multi-factor authentication, adding tags etc. So the git repository managers should scale from implementing quite lightweight compliance processes to more strict requirements. All this done in a way your devs actually don't mind (well, too much at least, it's still compliance).

End of the blog stuff with wisdom and so forth

In a lot of cases, compliance processes need to be followed by the developers, engineers, or technicians, but the processes are not well implemented using good tools. This causes a lot of extra bureaucracy, process subversion, delays, frustration, with a result that the processes actually don't do what they should, and the people using them don't understand why they should be followed (anecdotal evidence with zero real proof, but I can't be far off, right?).

If you're already using git in your daily work, bringing the compliance processes close to the people using them can bring tons of benefits in process compliance, efficiency and improvement (again, zero proof, but try it and report back). However, in most cases this will take effort from the devs to understand the compliance processes, and sell this idea, since people working in compliance are less likely to have in depth knowledge about git workflows.

So that's my (probably not that original) take on Git Compliance or for short git-compl... git-c8e... cowcoto (compliance with codetools)... uhm. git-comp! Yeah. let's go with that. Git-comp! (although cowcoto sounds fun).

Next step. I should really try to push testing git-comp here.