Compliance as programming language
One of the challenges for DevOps teams in financial/enterprise organisations is that they are heavily regulated and that they have the responsibility to prove that they are compliant and secure. Typical behaviour I have observed within in these organisation is that the DevOps teams only do this when an external party requires them to do this and when they need to do this they need to fill in a lot of sheets and/or documents and communicate these over for example e-mail.
Filling in these sheets/document makes the developer experience (DevEx) for the DevOps teams poor and causes the teams to become impeded and frustrated. These sheets/documents also are lacking the capability to be automated, integrated, versioned and validated. In the previous blog on DevEx interactions I have described how to improve interactions and in this blog I want to attempt to design a compliance programming language and command line tool that improves the developer experience for the DevOps teams.
Why is it important to have compliance as programming language instead of documents and sheets? The answer to this question can be found in the nature of a DevOps team. These DevOps teams love to code, from the actual functionality, to infrastructure to their build processes.
Another reason why these DevOps teams really like code, because they can put it into version control and track who made what change when. And the third reason is that tooling can be used to give a guided experience (like IDE plugins). And finally code really allows to be read by humans and machines when the language of the code is well-designed.
In the example compliance programming language I will try to describe the language necessary to have compliance written down for a web application. These elements are important in this compliance programming language:
- Human and machine readable
- Meta data (Describing for example name and type of the application)
- Controls (Describing what you have done to be compliant for an certain control)
Version: 1.0.0
Name: "Product name"
Description: "Description"
Type: "WebApplication"
Control: "CTRL-1"
Description: "Outside communication is secure in flight"
Control: "CTRL-2"
Description: "Communication is secure at rest"
Control: "CTRL-3"
Description: "Failing control"These compliance definitions should be ‘glued’ to code that actually can prove whether the compliance control is successful or fails. In Java an annotation can be created that allows for a certain method call to be called when a control is checked.
import com.example.compliance.Control;
public class SampleDefinition {
@Control(name = "CTRL-1")
public void control1(){
System.out.println("I am executing the validation of control-1");
}
@Control(name = "CTRL-3")
public void control3Failing(){
throw new RuntimeException("Failing control 3");
}
}Writing a language interpreter can be done for instance with ANTLR or Bison, these tools allow for definitions of a lexicon and a grammar and will generate parsers in a multitude of programming languages/platforms. These parsers can be used to create a command line tools that allows for validating and executing the defined definitions written in the compliance language.
If a compliance definition is written down in the compliance language, this definition needs to be interpreted by a tool. This tools allows for validation syntactical correctness of the definitions, executing the definitions and share the output with the compliance team.
This compliance tool should provided/developed/distributed by the compliance team and allows DevOps team to have a more validated/guided/standardised experience.
Other benefits of this compliance command line tool is that it can be used within the continuous delivery pipelines of a DevOps team and will allow pipelines to fail when compliance controls fail or when compliance controls are not implemented and should give a fast overview on the output. Also it allows the output to be standardised by compliance team which allows for automatic processing not only on the DevOps team side but also on the compliance team side.
I am aware that compliance has much more depth and is something to handle with care. This blog should help organisations to design their own compliance language and offer a better developer experience with less impediments and have a more guided means to be compliant where compliance becomes a part of the source code just like infrastructure or tests. It also gives DevOps teams the capability to do compliance automation, in a standard way offered by compliance department.
Join our community Slack and read our weekly Faun topics ⬇
