In one of our recent webinars on audit reporting, the panel was asked if there’s a way to shift compliance left in the software delivery pipeline without overburdening the audit team. That’s a great question, because, for enterprises with hundreds of applications, moving compliance execution left involves putting more control in the hands of developers, which requires that the audit team work with each individual application team while executing audits. This is different from the past where the audit team was more focused on providing the frameworks and tools and validating whether they were used. I’ve seen first hand that, when companies give their development teams too much freedom to build their own pipelines without providing clear boundaries, it can be really hard for audit teams to keep up.
But there are a couple of steps you can take that will give your developers greater freedom without overburdening your audit team.
Step 1: Standardize and automate parts of the pipeline
A critical ingredient in not burning out your audit team when you left shift compliance is to standardize and automate certain elements of the pipeline. For example, if there’s a change going to Production, you could easily integrate with ServiceNow or with BMC Remedy and handle the whole change request and the CMDB update in a fully automated manner. It doesn’t matter if it’s your cloud deployment, or your SQL database, or something else. That part of the pipe is exactly the same.
I’ve also worked with many large organizations who’ve standardized security scanning on Fortify and Checkmarx or on one or two other tools. So you can say to your developers, sure, you can build that CI pipeline yourself. You can do unit testing as long as you can track it all the way to Production. But before that code leaves Dev or Test, it must go through these formal, standardized validations.
Keep in mind that freedom doesn’t mean you get to shirk responsibility. If developers truly are going to have more control over the application delivery process, they need to be responsible for that delivery.
Step 2: Agree ahead of time on a set of compliance principles
Before giving developers greater freedom to build their own pipelines, your development and audit teams should come up with a standard set of compliance principles that apply to the delivery process. These principles could be requiring the use of a build breaker, putting certain quality gates in place, or agreeing that you don’t push bad code down the line. Just break and start over again. Whether you do that with Fortify or Gatling or whatever tool you use in your pipeline, it doesn’t matter. You just need to adhere to that principle.
I’ve seen many instances where the left side of the delivery process is thought of the Wild West, and the Staging and Production side is the control element. That’s why you need to find a balance where you implement a consistent process from Development through Production, and build compliance into your process. Your developers will feel freer—they won’t have to think about the rules because the rules will just be part of the delivery process.
In my experience, companies who are really serious about accelerating delivery while maintaining compliance know that crafting an effective set of compliance principles requires going back in time—years and years—to identify what the real checks are, what validations must be in place, and so on. They drill down and ask hard questions about why they’re doing certain things. Is this thing we’ve been doing crucial and, if so, why?
I know companies that have reduced their number of controls by 60%! That alleviates a lot of burden on Dev and Audit, and accelerates delivery. And keep in mind, this has NOTHING to do with automation. It’s just a new way of thinking about your process.
To sum up, by standardizing parts of the pipeline and boiling down your compliance controls to those that are absolutely critical, you can free up your developers to work faster without overburdening your audit team.