“Hey, can you meet with our SOC 2 auditors’ for a couple of hours next week to talk about our SDLC process?” Oh no! This question continually causes heartburn and eventual headachesfor software engineers. Spending multiple hours in a conference room explaining to auditors how your team deploys changes, what a pull request is and explaining how infrastructure as code works is not how engineers would describe a productive afternoon.
What is SOC 2 and why does this impact engineers?
SOC 2 (or other regulatory frameworks) examinations are not going anywhere, they have become the cost of doing business for technology-enabled service organizations that provide SaaS or other services that interact with, store or transmit their customers’ sensitive information. These examinations assist organizations with proving to current and potential customers how they are securing their data. The software development process is an integral aspect of SOC 2 examinations. Every SOC 2 examination regardless of in-scope Trust Services Categories or organization type, requires an evaluation of the change management processes and procedures. Often this means spending countless hours retrieving evidence of changes, answering questions about your DevOps process with internal compliance personnel and external auditors. During a SOC 2 examination, auditors are concerned with a few specific attributes related to each software change:
These questions sound like they create significant obstructions to collaboration, and speed, which is essential in a DevOps environment. However, there is a way to maintain a healthy, secure codebase while also encouraging collaboration and adherence to compliance requirements.
Protected Branches
Enabling protected branches and implementing native security policies on these branches will make these audit experiences tolerable and less painful. GitHub is one of the more common software development platforms in the industry, this article will focus on GitHub protected branch configurations however these same theories can be applied to other software development platforms. GitHub defines protected branches in the following manner, “Protected branches ensure that collaborators on your repository cannot make irrevocable changes to branches. Enabling protected branches also allows you to enable other optional checks and requirements, like required status checks and required reviews.” Protecting a branch eliminates the risk of a planned or unplanned catastrophic event where a branch is deleted. This is the first step in enabling guardrails to secure your branch. Some additional checks or requirements can be enabled with a protected branch to configure security policies
Recommended optional checks and requirement configurations on protected branches
Require status checks to pass before merging
Require pull request reviews before merging
Require review from Code Owners
Conclusion
Security and compliance can no longer be an afterthought for DevOps teams. Integrating security configurations into the software deployment pipeline will allow developers to bake software security in every stage of the process. Compliance assessments like SOC 2 or PCI-DSS are inevitably going to impact your development team and process. Enabling native configurations to systematically enforce these security requirements will make these compliance assessments easier to obtain, maintain, and hopefully make those conversations with auditors a little shorter and less complex for all parties involved.