Why we need to stop shifting cyber security left

We need to have an honest conversation. It’s about shifting security left in software development and why we need to stop doing it.

The phenomenon of shifting left

You’ve seen it in numerous articles, books, magazines, and marketing materials.It's the concept that the future of cyber security isn't about what we do now — it's about shifting responsibility and activity left.

What do we mean by this?

At its simplest, shifting left is supposed to mean we move cyber security from siloed security teams and spread it evenly throughout our software development lifecycle.

However, the naive interpretation — and the one we see more commonly — looks more like standing in a line and passing a parcel from person to person, constantly shifting the parcel one step to the left.

There’s a big problem with this.

Eventually, you're going to run out of people, and the person at the end of the line will carry much more than they can manage.

And that's what we're doing in cyber security.

We’re shifting the responsibility, accountability, and actions needed — for application security — to stages earlier in the lifecycle or to other teams in our environment.

A tale often told

Imagine you’re part of a fast-paced development team. You have a security team nearby. They're there to help you identify and remove weaknesses early in the process and make sure the software is secure. Great!

But there's a problem. There are 600 of you in the development area, or even 6,000 in some cases. And in the application security team, there are about six.

In this scenario, owing to the imbalance between the team sizes, your security team is more like an audit or consultancy function. They only have the capacity to do a fraction of the security work needed — they just don’t have the hours in the day to do any more.

So when they shift left, they're often packaging up part of their world, passing it down the line and hoping somebody else can take it, so more work can be done.

The aim here is logical, but it causes unspoken friction that’s causing many shift-left approaches to fail.

Finding friction

Imagine the security team wants to make it easier for your team to spot vulnerabilities in third-party code or for you to scan your code for security weaknesses as part of your build.This isn’t something the cyber security team has the resources or time to do, plus they don’t have the deep knowledge of the codebase they need to do it effectively.

What do they do instead?

Maybe they go to a trade show or conference and find a tool or device that could help the development team do this work themselves. They have the budget, so they purchase it, bring it back, and try to get it implemented.

This is where the issues start.

Implementing this tool or device isn’t part of the security team’s world. They don't control the build pipelines. They don't build code at all. In most cases, they’re completely divorced from the development areas.

That means once they’ve completed their well-intentioned gesture of buying a device or a tool, the implementation of it gets passed along to the development or operations teams.

These teams have their own challenges and constraints. They may not have the time to work something new into the pipeline, or perhaps there are pipeline elements that would be disrupted or damaged by adding this product in. After all, it's untested in this context.

We’re beginning to see how shifting left in this way shows a lack of respect for others. We shifted left and gave responsibility to a different team but didn't respect the resources and time they needed to make it work. We didn't look at the friction it causes with our existing lifecycles and try to address that first.

Taking all this into consideration, it’s no surprise that many application security initiatives that shift left eventually shift left into the sea. They never get started; or they start, get a terrible reception, and never see the light of day again.

Devices, tools, libraries: all of these things we spend hundreds of thousands of dollars on per year, and are all too often relegated to the bottom of the build pipeline within months. Expensive, well-intentioned purchases gather dust in the tool library, unused until somebody sets out to implement it again, only to realize it's already there.

Is this a cynical view? Undoubtedly.

I won’t argue that. But it's a scenario playing out all around the world.

Attendees of global cyber security conferences share their experiences of it at length — these security leaders who have tried to shift left but been left cold by the results.

Whether it's in multinational banks or small high-growth companies, we're seeing a pattern of shifting left into an area without respect for the needs of whoever will be responsible for these new activities.

Let’s change direction

So if our current way of shifting left isn’t working, what should “shift left” mean? Is it even the right term anymore?

For me, it’s a less than ideal choice of words to describe a vital need.

What we need is collaborative cyber security.  Or in other words, a way to make sure all the people involved, accountable, and responsible for application security are working together side by side.

We need to find ways to collaborate on cyber security, all the way from having a great idea through to design, implementation, testing, build, deployment, and the ongoing lifecycle and maintenance of that tool when it’s no longer in active development.

It’s not about shifting left. We’re not shifting something from our application security teams into our development teams.

Instead, how about expanding our teams?Instead of giving solutions to our development teams, how about listening to their challenges?

Instead of shifting, how about sharing?

Perhaps even that subtle language change can help us get to where we need to go.

Time to follow a new leader?

We must stop shifting our security needs to another team, leaving them carrying more than they can handle.

If we’re really going to make application security work, we need to come closer to software development. We need to really understand each other, and that requires a healthy dose of empathy and collaboration from all of us.

SafeStack has a vital role to play in this. By providing developers, testers, analysts, and architects with the skills they need to understand application security as it impacts every stage of the software development lifecycle, we’re empowering development teams to own application security.

The SafeStack community provides a safe space to come together, compare approaches, and share solutions. This is a new generation of cyber security product that exists to understand and enable others and then get out of their way.

Maybe if we let the development teams lead, and we share our skills and resources, we can turn what's currently a high-friction and low-success space into something that works — something we very much need if we’re going to secure the future of our software ecosystem.