A DevOps Approach to Compliance: What It Really Takes to Build Compliant Apps
Written by: Dan MacKenzie, Content Marketing Manager, Palo Alto Networks
If you Google a term like “software compliance,” you’ll be met with a seemingly endless lineup of blog posts, how-tos, and explainer articles promising to tell you everything you need to know about writing and deploying software in a compliance-friendly manner.
Some of them are good, especially the ones that delve into meeting compliance requirements associated with specific regulatory frameworks. (Articles that make generic recommendations like “secure your data!” are less helpful, but I digress.)
In this blog, I aim to contribute something new to the conversation about software and compliance, especially as it relates to modern, containerized, microservices-based environments. I’m not going to rehash all of the existing content about compliance best practices. Instead, I’d like to offer a new way of thinking about how you actually build compliant applications — by taking a DevOps approach to compliance.
What does that mean, exactly? Let me explain.
Why DevOps Compliance?
I know. When you hear a term like DevOps compliance, your first thought is likely: Well, there’s another meaningless buzzword.
However, when I use that term, I’m thinking about more than marketing hype. I’m referring to the actual practice of using DevOps processes as the basis for building compliance into your applications.
I’ll explain what that looks like in a moment. For now, let me explain why the concept of DevOps compliance matters.
The main reason is that it drives home the truth that, in order to create compliant applications, you need to make deliberate design decisions and follow specific processes for implementing them. This is what makes the concept of DevOps compliance, as I’m presenting it here, different from typical recommendations for achieving software compliance.
Instead of treating compliance as something that you worry about once your application is written (or as a process that lives in its own silo, if you want to describe it in DevOps-y terms), the innovation behind DevOps compliance is to bake the compliance process into the rest of the software delivery pipeline, ensuring the software that’s created is secure from the beginning of the development process.
For starters, ensure that everyone who plays a role in software delivery understands what compliance means and which specific compliance requirements affect the software they are building. This is not often the case by default. Typically, compliance is something that your lawyers and security team know about, but not something developers, software testers or IT Ops team members spend much time studying.
In order to do DevOps compliance, that has to change. Your engineers need not become compliance experts, but they need visibility into the specific compliance challenges that they must meet. They must also understand how those challenges change — compliance frameworks have a tendency to be updated regularly.
Tracking compliance across the CI/CD pipeline
Second, achieving DevOps compliance requires implementing processes that allow you to verify and vet the state of compliance at all stages of the software delivery process. When developers are designing new code, they should be thinking about how that code can be compliant. When the QA team is testing the code, they should verify that it meets compliance goals. And when IT Ops deploys the code, they should monitor to ensure that it is actually fulfilling compliance needs in production.
A third key process is auditing the software delivery lifecycle. While the precise audit reporting requirements vary from one compliance framework to another, it’s a best practice to make sure you are actively logging and able to report compliance-related data.
The problem is that many organizations only think about audits when software is in production. To do DevOps compliance, you should be baking audits into all stages of the CI/CD process by documenting how you are working to meet compliance goals, then measuring your success in achieving them. This ensures if something goes wrong, you have full visibility into where the issue originated and how to fix it.
Ideally, you would never make a compliance mistake. In reality, you will sometimes experience oversights. When that happens, it’s much better if you know exactly what went wrong so you can quickly develop a plan for fixing it. This helps you avoid repeating the same mistake, and it can help keep regulatory authorities happy. They tend to be more forgiving of compliance errors if you can proactively show, using your own auditing data, that you know what went wrong and how you are going to fix it.
The Truth About DevOps Compliance
Compliance is not something most developers or Ops engineers enjoy thinking about. In fact, it’s something many of them don’t think about at all. And that’s a problem.
As software-related compliance challenges grow increasingly complex, and as the consequences of non-compliance grow (both in terms of regulatory fines and a loss of reputation), it is something that all participants in the CI/CD pipeline need to support. They should be doing so at all stages of the software delivery process, and in a way that maximizes visibility into compliance efforts via a clear audit trail. That’s what DevOps compliance looks like.
Have you had challenges with compliance when it comes to your DevOps process? Or have you just begun to explore a shift to DevOps methodology? Share your experience with other community members, and check out a recent webinar on the topic. Visit the Cloud Native Security Summit page.