Regulations vs. DevSecOps: Requiem

In this 15-minute lightning talk, Diptesh “Dips” Mishra, CTO for Shoal (a Standard Chartered Venture) talks about the governance challenges that financial services organizations face when they look to adopt DevSecOps. Dips has worked for Nationwide, Lloyds Banking Group, and RBS and he’ll share key strategies behind successful implementations.

Transcript

I’ve been in financial services looking at the overlap between regulations and DevSecOps over the last six years. It’s been an interesting journey, and I’ve looked at it from the startup lens, both within larger corporate banks, more traditional investment banks, and retail banks, but also upcoming startups, starting from pre-seed seed grounds.

My last role before Shoal was at Kroo Bank, where we built a digital bank in the UK from scratch, which is one of the most highly regulated environments. And now I’m at Shoal, where we are building a sustainability marketplace, where we are going to offer financial services products, but with a sustainability angle to it. It’s part of Standard Chartered bank, so we have all the regulations that we need to comply with. Hopefully I’ll keep it nice and interesting — let’s see how much I succeed!

As you can get from the theme, it’s based on Alien vs. Predator. Can I get a quick show of hands from everyone who has at least seen one of the movies or the game? Great, thank you, that really helps — I was worried for a bit!

So there’s this complex dichotomy between regulations and DevSecOps, and if you have been in modern financial services organizations, you can’t really escape it. It’s constantly there, be it whether you’re a fintech startup, a scale-up, a traditional or digital bank, retail private investment, in central banks — irrespective of what you do, you have got those challenges and it’s about picking a side, right? 

Before we pick any sides who you think might come out on top, it’s probably worth thinking about what each one of them are and their salient points, right?

Regulations: why do people love them? They’re very well defined, clearly documented, there’s limited scope of interpretation. So you know exactly what you are going to get, what you need to do, right? There’s less room for interpretation there. DevSecOps on the other hand: it’s a bird, it’s a plane, no, it’s an alien! Even Superman is an alien for those who don’t know the full story.

So it’s one of those where people are still trying to agree on one term for DevSecOps. If all of us went into a room and everyone had to write what they thought the definition of DevSecOps was, I’m sure we’d probably have tens of different answers in the room.

Who are the main cheerleaders, the fan groups that drive regulations? You’ve got the regulators themselves obviously; you’ve got the people who hold senior management functions as part of the senior management certification regimes; risk and compliance teams (every single regulated organization has them: the gatekeepers, the change haters, they’re known by different names, none of them were given by me!); and then you’ve got DevSecOps. Who are the cheering squad for them?

You’ve got digital and cloud-natives, you’ve got startups, as well as established tech behemoths like the FAANG organizations who are big, big proponents of it. You’ve got the disruptors, you’ve got agile coaches who are coming into organizations and saying: “You should have DevSecOps!” And of course you have got tooling companies, not naming anyone.

But at the same time, there are some common themes here. They’re not entirely different, but the regulators and DevSecOps see that it’s non-negotiable: you absolutely must have us for regulations. It’s about the license to operate. You’ve got a mandate from the regulators within your jurisdiction and you need to be compliant with those regulations to operate. Similarly on the DevSecOps, it’s about being agile, but able to promote continuous changes quickly and efficiently.

And so there are some common reasons they both think it’s non-negotiable, but at the same time, it’s about making sure that they have different reasons for it. Final part before we kick off the battle, the weapons! What do they bring to the table?

So DevSecOps have got agile and digital transformation on their side. They’ve got innovation, that’s the new kid on the block. The most important weapon at their disposal is DevSecOps tooling. Now, please don’t strain your eyes trying to understand any or all of it — I’m sure you’ll find it online. But the idea is there’s a growing plethora of different tools, new ones coming up every day, all of which provide different and new features as part of it, right? It’s a proper sprawl.

Regulations: what are their weapons? You’ve got forms, forms, more forms, death by forms. It starts with frameworks, you’ve got policies, controls, and audits. So there are different aspects that you would have all come across in any regulated space. What’s their nuclear weapon? You do not have our approval to deploy to production. That one sentence just kills everything. So that’s their main weapon.

But is it really a fight? We have looked at how they are set up. We have seen they are potentially trying to achieve different goals and objectives. But are they really completely opposites? Can we not come to a middle ground somewhere? Let’s take a step back and think about where they are coming from — what are the drivers?

And that’s one of the cool aspects, like when you get into a conflict resolution mode where you’ve got different viewpoints, you take a step back and start from the beginning, see where the people’s viewpoints are coming from. The regulations have a duty of care which starts from a good place — they want to protect the customers, but at the same time, some of it you sometimes wonder, "Are they doing this to protect the system itself?" They love inertia.

A majority of these issues that you see are caused by deployments or releases. Any changes you make to the system are very likely to have been the cause of problems. And of course they want to ensure there are proper processes, governance, and controls. In terms of DevSecOps, they’ve come from that mindset of being lean, having principles like the ability to fail fast, test and learn, continuous rapid change, almost on an ongoing basis. And lots and lots of automation.

Does anyone recognize this? This is the famous Agile Manifesto. Some of it has been lost over the years in translation, where people think that what was meant was only the things on the right are important. So while the manifesto itself was very clear that while the things on the left are also important, those on the right are the ones we would look to do more of.

But some of the things, like if you talk about a plan in an agile organization, you’ll hear things like, “We don’t do any plans, there is no need to plan, we are fully agile!” That’s not what is meant. Same for documentation — we have working software, our code works, right? But it doesn’t say don’t document anything. So there is room for all of the eight elements on this, and that’s kind of where you start looking at what’s the common ground, where do you get regulations which are kind of represented on this side to work with those from DevSecOps? 

So now that we understand a bit more about them, perhaps we can negotiate?

So to start with, we can look at testing everything. Figure out how we test — that can be a whole topic in itself, right? We were just discussing during the break that you can test everything, have 100% good coverage, every single test passing, but actually not test anything useful. So there is a lot to be done in that space. It’s about continuously learning in all environments. 

That is another area where if you look at changes that fail, once you get your pipeline and your processes sorted in terms of automation, one common thing that’s still different across environments are things like configuration. You will have a very different configuration in your production environment than what you would have in staging. And that might mean because you are connecting to a different backend, it could be because you have a third party system that has a sandbox and a production environment that’s separate. 

Any of those will give you differences and it’s about how you test work across these environments. And work hard to avoid failing — what people who are on the regulation side do not like is a more loose attitude where people are like, “It’s OK to fail.” But it is OK, and that’s where the psychological safety of the team and understanding of that comes in. 

But it’s not an excuse for taking things lightly or not being diligent about "Have you tested everything? Have you talked about possible exception and error scenarios?" So it’s about working through those. And when you do fail, fix it, learn it, and then work harder for next time

Continuous everything — one important part for this one is regulations. People think regulators have a lot of inertia, or risk and compliance have a lot of inertia to change. But inertia is not just about being addressed. It also can be about uniform motion. So you can actually move towards a continuous compliance pipeline which enables these to move at pace.

And yes, automation of processes, governance, and controls. I think that’s the recurring theme that you will see today at least. 

So what does it take? You’ve got fully engaged organizations — who must have buy-in from the leadership all the way to the grassroot levels. You can’t bring them to the table without one or the other.

You need to have empathy and patience. That’s a key part of leadership. It enables teams to understand each other, different viewpoints, and it requires a lot of work. Regulations have been built up over decades, sometimes even centuries, right? DevSecOps hasn’t had that many years to grow. If we had to work together, empathy and patience are both important from all sides.

And having a structured process. Think about what the requirements are. What are we trying to achieve? At the end of it, we are trying to release a deploy code. That code itself has a purpose. Why is it needed? What happens if it is not there? So every time we come across a control, think about being clear around why it is needed.

An important question is: if I now remove the control away, what is it that can happen? What are the risks?

And the third part is where it starts getting interesting. How can these requirements be achieved? That’s an open-ended question, but sometimes you might get the standard answer: fill out this form. By the time you complete this process, you will be well set. 

But what is it that filling out that form achieves? So the second question comes in: what are the different ways in which this requirement can be achieved? If you ask everyone who has a different viewpoint, you will get different answers, but in the end you will be better off because you can understand that there’s not just one way — which is a document-driven Excel spreadsheet based on some system where you need to fill out forms — it’s where you can bring different types of automation into place as well. 

Finally, what would provide assurance on the effectiveness of controls, governance, and processes? That’s the most important part from a regulatory standpoint, but that’s what we’re trying to achieve through automation. And so again, you boil it down to what are the outcomes and key results that we are looking for? And once you’ve got all of these answers, it’s just figuring out the next steps: who is going to do what and by when?

How long does it take? It takes forever. It’s a continuous process, right? It’s the journey. There is no final destination here. It’s about making sure the journey is as enjoyable for the alien as well as the predator.

So where do we start? Why not define and start with an MVP? Define the minimum process that you need, pick up one that you think you can automate, figure out how automated governance can be introduced in that area, and then maybe you can get them both to sit across the table from each other and play a nice game of chess instead!

And that’s it from me. Thank you very much.