How to Adopt a Seamless Shift-Left Security Process

In today’s world of growing security threats, many organizations are adopting a shift-left security approach, moving security to the start of the application build process — but this puts more pressure on teams to deliver code fast.

We spoke to GOTOpia Chicago 2021 keynote speaker Matt Brunt, software engineer at the SANS Institute, one of the largest security training companies, to hear his thoughts on what it takes to adopt a successful shift-left security program for a seamless shift-left process.

What is shift-left?

Matt: In short, spend a bit more time upfront, save more time later. If you think of your development as a timeline, you just shift those processes — in this case security processes — further to the start and get more people involved in them.

The struggle

Matt: As a developer I wanted to be involved with things sooner rather than later, so the idea of moving everything upfront, spending a bit of time at the start and saving a lot of time further down the line has always made sense.

What I’ve struggled with in the past is with managers and higher ups having the thinking that “spending more time upfront means we’re going to ship the product later, therefore that’s bad, so we don’t do that.” With that mentality, what they don’t realize is that you ship the product sooner, but it’s a whole lot worse than if you spent the little bit of time upfront.

So… how do you run a successful shift-left process while delivering software fast? And is it even a good idea?

Get the full team involved from the start 

Matt: Realize that not everyone thinks of everything, and each person will have their own ideas, areas of interest and concerns (design, dev (front and back end), ops, PM, QA).

Every person has a different idea and approach to it; a designer has a very different idea of security than an ops person, or the developers do, but each is valid and needs to be taken into account.

For example, the designer is wondering how people are going to interact with your program and by extension, how people are going to mess with it. Make everyone aware of the shift and get more people involved from the start.

Make security concerns a part of your acceptance tests

Matt: In our team at SANS, we have tests for ensuring people who shouldn’t have access to things don’t have access to them.

It’s not just about what people should be able to do, but what people should not be able to do.

We have a test for, if ‘this’ particular kind of person in the system shouldn’t be able to access this particular resource. We look at a particular page, what data has it got on it, who is meant to be looking at that data. 

That’s not something that’s done after we’ve built the feature, that’s something that has to be done at the very start, because it’s the designer thats laying out that page and saying who should be on this page, who should have access to it and then developers looking at it at the same time should be thinking where does that data come from, it comes from right back at the start.

Automate scans / checks of project dependencies

Matt: With static analysis tools, automated dependency checkers, along with tests running automatically in CI, we can ensure that when code is pushed to our repository, it's checked for known issues and bad patterns that gives us more confidence that things are as they should be.

Github itself does vulnerability checking of your project dependencies, if you have a node project it will be able to scan your dependencies in your package.jason and package.lock files, and it will be able to tell you what things have known vulnerabilities that you need to update.

Github also has a bot that can put in a PR with updated dependencies and if CI pases you can have that automatically merged.

I like automating things because I like not having to think about this stuff, but with security you can’t automate everything, so ultimately making it part of the conversation at the start will see it flow through the whole process. But it’s quite difficult, you have to build a habit to do it.

Maintain good habits with peer review

Matt: Bad habits can creep in, and building good habits is hard. There will be a bit of time upfront where it takes a bit more time transitionally. You’ve got to actively make that discussion happen and actively talk about it but over time it just becomes a natural part of the process.

As well as peer review being a great way to get everyone else’s knowledge in on something because everyone has a different take on security, it’s a great way of ensuring that everyone can chip in with responsibility.

Keep software/dependencies up to date

Matt: Ensure that you are able to deploy your code without that deploy being scary.

How efficient is a shift-left mentality?

Matt: Addressing things earlier in the life cycle is often much more efficient than later on! Every time I’ve seen this shift left mentality adopted It’s beneficial and it gets everyone on the same page.

IBM released a study on the relative cost of fixing deficits. It’s a report on how much it costs to fix deficits in different instances — if you consider fixing a thing in production it’s going to cost you 100 time units, if you fix that during a testing phase it’s only going to cost you 15 and if you fix it during implementation it’s only going to cost you 6.5 and if you fix it in design it’s only going to cost you 1 — the point being, if you can spend that one block of time upfront, you’re going to save yourself 100 later, it’s a no brainer.

However, people see spending that one block upfront and think if they one block upfront and ‘that thing’ never happens, they’ve spent that one block for nothing. My advice: It’s going to happen at some point and if you average it all out, if you spend that one block upfront you’re going to save yourself a lot of time overall.

Delivering fast while shifting left

Matt: Anyone can deliver software fast, but to do it fast and well is a different skill set. I can ship out a piece of code tomorrow, but if it doesn’t do what it needs to do, then ultimately it’s useless. If I spend a little bit more time on the design, the discussion and thinking about it before I write it, I can save myself a whole load of time down the line.

People think about delivering software fast as it has to go out as quickly as possible, but it’s also about how quickly you can fix things and if you’re fixing things after it’s been delivered that’s a long time. If you’re addressing it before it’s been delivered, well that’s as quick as it can be because you’ve fixed the problem before it’s happened. 

It’s not just about time to launch. If the system is buggy broken and vulnerable, then it’s useless.

Spend a bit more time upfront, it will launch later, but to get to a usable state it will happen a lot quicker

It’s all connected!

Matt: Peer-review, static analysis, automation, up-to-date dependencies, good testing, these things that people talk about all factor into building a foundation for a robust and secure application. It’s all connected — all these development best practices factor into security and a good shift left process.