Why Current Approaches to "Shift-Left" are a DevOps Antipattern

Tim Johnson, senior product marketing manager at CloudBees, and Welly Siauw, principal partner solutions architect at AWS, discussed some self-professed controversial opinions around compliance and “shift-left” in a recent webinar.

The speakers suggest that common implementations of compliance in DevOps, based on the “Shift-Left” philosophy, are an anti-pattern—it actually makes things slower rather than achieving the DevOps-related goal of continuous delivery.

There is some evidence that, in the enterprise, the burden of compliance can lead to exhausted developers and overly-burdened DevOps teams, Risk Managers, and CISOs. And the speakers have data to back this up a bit later in the talk.

What’s the burden that’s slowing down developers? It’s the time required to understand the policies related to compliance and making sense of the alert storms generated by all the security scanning tools.

Developers are required to understand and follow policies set by the CISO and other risk-management position-holders at the company. Yet they typically are not security experts so this takes away time from focusing on delivering features. Also, since security tools are notorious for generating thousands of alerts, developers have to waste additional time sorting through those results, prioritizing the most pressing issues, and then figuring out where they occur and how to fix them.

And then something in the environment, regulations, or policies changes. All this trickles to developers when they have to stop developing to do compliance reviews and learn about new policies.

The CISO stakes their career and reputation on the tools, processes, and people that are keeping the organization in compliance. Most decisions and compliance assertions are based on old data: a point-in-time snapshot of the organization.

You see, increasing complexity in the organization leads to higher rates of change from that snapshot data. Additionally, legacy systems, approaches, or sysadmin access can lead to gaps in compliance and security posture. CISOs are left to test to systems they can’t completely see (without endless meetings) based on data that is no longer current or comprehensive.

According to a C-suite security and compliance survey conducted by CloudBees, C-level executives doing shift-left are spending more time on compliance and less time on adding value to the organization.

And that’s not the only problem. Tim presented survey data showing that only 29% of developer time is actually being spent on innovation, and he posits that this number could be even much lower.

He also shared the shocking experience that one CISO had, starting his job at a global bank with over 600,000 security warnings. That’s a huge burden to step into! Where do you even start?

The issue at hand here isn’t about shift-left; rather, it has more to do with how it’s being approached. The current approaches are adding cognitive load on employees. It focuses on meeting compliance, but it doesn’t prioritize adding value. And what’s worse, it actually takes away from employees’ availability to add value.

What is a compliance tax? It’s the amount of effort needed to meet compliance. And every organization has to pay this tax.

Data from one of the ten largest banks in the world

The tax manifests as things such as pulling or generating auditing logs, reviewing policies, and updating pipelines to meet compliance. 

The compliance tax calculation includes not only the salaries but also the opportunity costs of every person fully devoted to compliance. In determining the full weight of the tax, you’d also have to include the time spent on these matters by those not dedicated to compliance. 

The burden of compliance tax will vary by industry and organization. To give you a general idea of what your compliance tax might look like, you can try this CloudBees’ opportunity cost tool. (Warning: results may be shocking!)

The inputs to meeting compliance are complex and often interrelated. They include four different classifications, as described by Tim Johnson. He lists these classifications as

• Continuous

• Digital estate

• Contextual risk

• Frameworks in use

Let’s discuss these in more detail.

On a continuous basis, compliance needs to consider a holistic view of the SLDC, real-time views, and real-time scanning.

The digital estate includes digital assets, like code, binaries, runtime environments, identities, data, and pipelines, the applications that use those assets, and the critical business services that use those applications to deliver value.

Contextual risk is related to the hierarchy of the organization, where in the SDLC process it occurred, the regulatory and internal requirements in place, and what needs are to be prioritized.

Frameworks can include those regulations mandated by external industry or government agencies, and those standards which are internal.

These aspects are interrelated. For example, the business has to consider its risk profile along with any regulatory standards such as PII and SOX compliance.

There’s value in improving how compliance is implemented.

First, engineers will benefit since they can accelerate their innovation and focus on priorities that add value. Plus, they don’t have to frequently switch contexts to understand compliance-related concepts.

Second, CISOs can benefit as well. They’ll accelerate innovation, assess with confidence, and assert compliance with fresh evidence. It frees them up to focus on working with engineering rather than getting in front of the load on compliance. The right tooling gives them the ability to step on the gas to increase delivery velocity and to “pump the brakes” when it’s needed.

And finally, the risk management department benefits from continuous compliance approaches as well. Improvements in this area include the ability to communicate in a shared language and measure effectively. They can close the gap between reality and their risk model.

On the whole, the organization gains in three key ways: 

• Their resources are freed up to accelerate innovation.

• They improve their risk posture.

• They increase their confidence that they’re compliant.

The philosophy of Shift-Left - to catch and eliminate issues earlier in the delivery cycle - is fundamentally sound. However, where it becomes a burden and innovation hindrance is when the responsibility to know what secure and compliance is and to interpret the results of the alert storms from scanning tools falls entirely on the shoulders of developers. Some companies conduct extensive security training with developers, others embed security/compliance unicorns into development teams, others do little more than add more tools and accept that the process is going to be painful.  

What’s really needed is a mindset and approach that focuses on what the right thing is, agreeing on that (and how to measure it), making the right thing the easy and defensible thing, and supporting it all with a continuous and holistic solution that reduces friction while enforcing compliance. Risk Management defines what safe and compliant is and those policies are mapped to automation without having to train everyone on what they mean. Engineering gets shielded from alert storms and only sees the top priority issues. DevOps and platform teams get to automate more and cross evidence collecting off their list of tasks. Auditors get the data they need without disrupting anyone else’s day to day business. Finally, CISOs can assert compliance confidently, based on current, contextualized data rather than stale or incomplete information.

You can check out the on-demand webinar here.