While presumably no one likes an audit, DevOps teams do have some built-in advantages when it comes to intense levels of internal and external scrutiny. Here’s a quick look at DevOps audits, why they matter, and how teams can set themselves up for audit success.
Looking under the hood
In most organizations, there are two types of audits: internal and external. At their most simplistic, internal audits are conducted by people within the existing organization, while external audits are conducted by third parties. Either way, audits look to ensure an organization is compliant, and that’s where things can get a bit complicated.
Being “compliant” can mean an organization is meeting standards set by the government (like NIST frameworks or HIPAA regulations), living up to its own governance rules regarding data, security policies and processes, and more, or it can mean some combination of the two. Also, depending on the type of organization and its vertical industry, compliance can have wildly different requirements.
In the end, it comes down to being compliant means keeping track of any data and processes that can prove compliance is happening, and that’s what auditors need to be able to easily access.
Obviously, it’s a big job. Way back when, external auditors would literally set up shop in an empty office and spend weeks (or months) sifting through written records, interviewing employees, and even walking the factory floor if necessary. Today, technology, especially automation, have made audits easier to prepare for and carry out, but the plethora of standards bodies and a growing focus on security risks mean more time spent auditing than ever before.
Enter DevOps
The largely seamless nature of DevOps not only makes it easier to get software out the door more quickly but it also streamlines the audit process. Why? Because automation tracks every step that happens, creating an auditable record, and the “continuous” nature of DevOps also naturally supports the idea of “continuous” or more frequent (and thus easier) audits.
“DevOps is all about building: writing code, building code, testing code, and compiling it,” says Sam White, GitLab’s principal product manager, Protect. “And it's about getting that code built into a deliverable that's actually shipped out to the end user and runs in production. Compliance [in this sense] is all about what regulatory controls and processes have to be followed within the context of writing, building, and shipping software.”
Audits and DevOps
DevOps processes naturally lend themselves to audits, White explains, because each of the steps can be traced and many, like merge requests, require signoffs. “Compliance regulations can vary across industries and geography. But, generally, what I hear from compliance teams is they need to make sure all of their commits are signed. You want to make sure you don't have a malicious actor putting in bad code. So finding the commits helps you verify who the person was who wrote the code,” he says.
Code review is another obviously “auditable” step in the process, he says, because “it’s very common for organizations to require at least two people to review any code before it gets merged in.” Auditors want to follow the path and DevOps makes it simpler to look at the flow of commits/MRs and code reviews to make sure nothing untoward has happened.
Track everything
While DevOps audit checklists do exist, industry compliance requirements vary so widely that a generic list is really only a starting point. But there are basic steps DevOps teams should follow:
- Ensure all code commits have signoffs.
- Review code on a regular cadence and require at least two signatures.
- Logging tools are critical – are they widely used and is the data easy to access?
- Make sure everyone on the team understands the concept of compliance as it relates to a particular industry.
- Acknowledge that developers aren’t auditors 😀.
- Check in on operations pros, who are increasingly being tasked with compliance but also report suffering from information overload.
Learn about GitLab’s vision for compliance management.
Lauren Minning contributed to this blog post.
