Governance is one of those things that DevOps (or DevSecOps) doesn’t worry a lot about. Not because it’s a bad thing, or unworthy of attention, it just doesn’t seem to be part of their turf.
But it is, of course, and that’s something software solution provider Benchmark Corp and its partners are trying to emphasize with the introduction of governance engineering.
The governance engineering methodology, described in a white paper available on the company’s site, is a set of practices to mitigate the security challenges in digital transformation.
“I think where we focus primarily is not fulfilling the thought leadership roles,” explained Shlomo Bielak, Benchmark’s chief technology officer, at the company’s DevSecOps event just before the COVID-19 lockdown took effect. “We focus on the practitioner side, which is where I think our customers are facing the largest challenge.”
The ultimate key performance indicator (KPI) that customers should be measuring, he said, is whatever constitutes customer experience. “You would have code quality being one of them,” he noted. “You will have their regulatory requirement which protects the customer data. It could be in relation to their contract as well – some customers have contracts with their vendors and you need to make sure you’re meeting those requirements. And beyond that, you can validate your metrics that say I’m running well or I am degraded.”
Benchmark, he emphasized, focuses on the enterprise. Where startups concentrate on pushing code, enterprises have more complex needs – they need to manage their brands, their Net Promoter Score (NPS), their service level agreements (SLAs) to honour contractual commitments, and they need to manage regulatory and security requirements.
But this is easier said than done, Bielak said.
“The model out there doesn’t solve all four components. The regulatory and security aren’t coming together with the ops and development teams at this point.”
And that’s where governance engineering comes into play. It asks security departments what they need DevOps to measure so the organization can be comfortable with its risk profile, then it automates the measurement and delivery of infrastructure. “You need to make sure you can deliver your infrastructure, not by a human being because that human being isn’t regulated by measurements,” he said. “Config as code; you don’t want to deploy into production and have 28 handcrafted changes that you didn’t document because it didn’t work. And then you need to measure. How do you know if you’re meeting SLAs if you don’t measure them?”
And you need logging, and then, he asked, why not integrate with incident management and change management and the ticketing system, so engineering knows what to fix as soon as an issue is seen.
“You can’t take a developer-centric perspective; a developer doesn’t have the understanding of what security actually requires,” he pointed out. “And ops doesn’t have the understanding of what development is doing. And if you try to force security into coding everything, you’re taking them out of the area that they’re best at, which is understanding regulatory requirements and governance standards. So a collaboration needs to occur.”
And, he added, you have to understand what risk you’re measuring, and then automate and measure all of the key factors involved. Then when the auditors come in, you don’t have to spend weeks proving you did everything right, because they can see it from the pipeline output.
“I compared one year before implementing this and then one year after,” Bielak said. “I had a seven-day audit, they found issues I needed to remediate. I had two weeks to remediate, which is the norm. We remediated, it was great. A lot of stress. The second time the auditors just wanted to see what the pipeline did. We gave them the output of the pipeline, and the audit was done in three hours.”
