I’ve heard a lot of questions recently about how security, audit, and compliance fit into the “new ways of working” with DevOps. Often those questions are asked with a lot of frustration as many see security, audit, and compliance as blockers in their quest for better throughput and stability after adopting DevOps patterns and practices.
As such, here are three ways to integrate security, audit, and compliance into your DevOps transformation.
Automate security, audit, and compliance.
Many organizations use paper-based processes and sign-offs to implement their controls. This creates what Jez Humble calls “risk management theater.” Paper-based processes and sign-offs are ineffective and counter-productive. They lengthen cycle times and feedback loops, involve decision-makers who are distant from the actual work, create waste and inefficiency, can be circumvented by bad actors, and hurt situational awareness.
Instead, use automation to implement the controls. You can integrate the automation into the pipeline so automated tests run on every build, only software without known vulnerabilities is used, and hardened infrastructure is deployed into various operating environments. Automation has the added benefit of producing much of your audit evidence to prove the controls are effective and operating as intended. This audit evidence includes information from check-ins to source code control, access control configurations, and logs from builds and deploys. How would you like to spend a lot less time gathering audit evidence, while improving how you mitigate your risks in the process? Automation can help.
Involve security, audit, and compliance early and often.
Most organizations tend to involve security, audit, and compliance at the very end of the software development process just prior to release — when change is the most painful. The typical result is delayed releases and lots of waste from rework. Stop doing that.
Instead, start discussions with security, audit, and compliance as early in the process as is reasonable. Find out what the non-functional requirements are and integrate them into the pipeline from the beginning with automation.
Also, be transparent with security, audit, and compliance, and share information with them. Yes, be transparent and share information. You might be saying now, “But don’t you know what can happen if I share information with them?” You mean better identifying and mitigating risks to the organization? That may not be what you meant with your question, so see the next point.
Change how you view security, audit, and compliance.
Here’s a multiple choice test to make my point. Why do security, audit, and compliance exist?
A. To make more work for everyone.
B. To prevent progress.
C. To assign blame.
D. To help the organization manage risk so bad things don’t happen to us.
I’ve heard many people share their opinions that security, audit, and compliance are unrealistic, untrustworthy, and obstructionist. Those people would answer A, B, or C (or even all three). However, the correct answer is D. Sorry, not sorry.
The 2014 State of DevOps Report contains the following statement about DevOps:
“DevOps, a movement of people who care about developing and operating reliable, secure, high performance systems at scale, has always — intentionally — lacked a definition or manifesto.”
We all care about developing and operating reliable, secure, high performance systems at scale — including security, audit, and compliance. So let’s show some empathy and treat them as valuable, like-minded partners in our DevOps journey.
There are now resources out there to help bring security, audit, and compliance together with dev and ops and everyone else who cares about developing and operating reliable, secure, high performance systems at scale. These resources include the DevOps Audit Defense Toolkit and The DevOps Handbook to name just a couple.
Security, audit, and compliance play valuable roles in any DevOps transformation. Let’s change our practices, processes, and attitudes to reflect that.