Digital resilience being taxed by tools? Time for a DevSecOps platform strategy

Financial services firms have embraced DevOps in the shift to digital, but it’s not living up to expectations – and that’s a problem as regulators respond to banking’s IT outages.

Firms’ DevOps practices are underperforming at precisely the time they must up their game on resilience

British authorities and the European Commission have separately published rules that raise the bar on digital resilience. Firms must not only ensure continued digital operations during an outage or attack, but regularly test systems to identify vulnerabilities and prove their resilience.

Politicians have responded to past and potential problems. A UK Parliamentary Committee report for 2019-2020, for example, noted a 187% increase in IT failures or reported incidents across the financial services industry. The Committee, meanwhile, has become concerned that a “concentrated set of vendors” providing cloud services could mean that problems affecting a single cloud vendor could potentially take down a raft of banks.

This has put the IT infrastructures behind digital business in the hot seat – and with it, DevOps.

DevOps goes hand in hand with digital transformation: it’s a philosophy of rapid and effective software delivery uniting developers, operations, security and the business. Unfortunately, the prevalence of teams with a “you built it, you run it” mindset, a lack of communications and the continued presence of manual deployment processes has seen the opposite occur.

In its State of DevOps in Financial Services report, professional services firm Contino found IT professionals were unimpressed with their employers’ DevOps implementations: more than half awarded their implementation two or three points out of five. This matters because poor DevOps practices hinder delivery of the secure and resilient digital infrastructure sought by regulators.

Our research has shown the past year saw a dramatic jump – from 21% to 53% – in the number of developers claiming to be “fully responsible” for their organisation’s security. This should be a positive, suggesting developers are taking greater responsibility for securing software, but the growth has not been matched by an increase in confidence among security pros. Quite the opposite – 43% feel “somewhat” or “very” unprepared for what the future holds. Why? Because 75% of bugs in first-time code are still being found by the security pros – in other words, being missed by developers.

DevOps can’t be reduced to just technology, but it can’t be divorced from it either. DevOps isn’t functioning as planned because of a proliferation of tools. Management consultancy Bain calls it a “wild west”, with the presence of multiple tools for the same function. Our preferred term is “toolchain sprawl”, with 41% of developers juggling six to 10 tools and another 44% running two to five.

Toolchain sprawl is a problem for two main reasons. First, dysfunction: team members that operate in different tools on the same project may not be able to communicate effectively or ensure security and regulatory controls run through the entire lifecycle of the software. The second issue is productivity: developers can be consumed with the task of maintaining, securing, integrating and orchestrating toolchains – at the expense of building valuable new services.

This is the toolchain tax.

Tax free? Think “platform”

The obvious conclusion is to consolidate tools but – on its own – this can simply produce new variations of the tax.

In Bain’s wildest of western scenarios, we see different tools for the same function – for example, source-code management. Typically, the first step in consolidation is to standardise within a segment of the DevOps chain, but this often creates a silo around each DevOps segment. Next comes an attempt to integrate those silos by creating homegrown toolchains, but this can involve a huge ongoing engineering commitment at potentially a great cost and with potential security risks.

Consolidation is part of the answer. A more coherent approach than homegrown or DIY approaches is to adopt DevSecOps as a platform – in other words, integrate capabilities such as planning, development, secure testing and monitoring through a simplified and streamlined branch of tools. That integration should also extend to systems for compliance and policy enforcement.

This is not cobbling together disparate DevOps tools – rather, it is using a set of pre-integrated capabilities to enhance inter-team productivity, collaboration and communications.

When we look at a DevSecOps platform strategy, a few things stand out.

The first is to foster a more cohesive culture of software delivery that’s founded on a collaborative model of development that makes the best use of team members’ skills. Toolchain consolidation is the first step towards achieving this. Employing a single tool for shared functions eliminates context switching, giving individuals a single view of the state of a project. By sharing the same tools, individuals can check in, comment and offer suggestions as projects move through development. The unified view and collaboration this produces places security and monitoring at the heart of development and ensures they flow through the software’s lifecycle. Consolidation has a receptive audience: 69% told our researchers they want fewer tools.

Next is integration between tools and compliance systems. In a platform-level strategy, integration is supported through unified processes and workflows that are tool-agnostic so that they can flow between different phases in DevOps and down stages in your software’s lifecycle.

Standardised processes are a way to capture best practices for build, deployment and monitoring. Enabling them as a set of workflows means processes can be applied consistently across your DevOps toolchain. When it comes to security, for example, compliance controls can be built into every step of the development and software’s lifecycle rather than being bolted on.

Finally, there’s automation. An AI or machine learning engine executes processes and workflows automatically. Automation can reduce the need for repetitive, hands-on work from development through to deployment and it reduces friction between teams by undertaking task and project handover. An ideal use of automation is in testing: historically, this has involved too many tests conducted too late in the process.

Automation overcomes this by triggering tests based on process and policy. As Forrester Research director Charles Betz notes in a recent blog post, automation of processes means DevOps teams can focus on “irregular, experience-oriented and non-sequential practices that demand human attention”. Translated: build new systems and respond to unplanned IT outages.

DevSecOps: meeting business and regulatory needs

Digital has transformed the financial sector and DevOps has accelerated delivery of services – but firms’ DevOps practices are underperforming at precisely the time they must up their game on resilience. It’s time to tame the toolchain with a platform-led DevSecOps strategy that marries consolidation with integration for the resilience needed to satisfy your business – and regulators.