Shifting Left Your Appsec Program

A lot of people talk about “shifting left” their application security, but what does that really mean? I’ll break it down for you a little and provide some actionable steps you can take. This won’t be a complete guide. For that you can check out James Chiappetta’s BetterAppsec.

What Is Shifting Left in Appsec?

Shifting left, in appsec, basically means that you are moving security closer to code in the pipeline.

The change is where security was a more reactive state, done after the fact… either after code has been committed, or usually way after it’s shipped.

Why Shift Left in Application Security?

Well, this goes to one of the most basic tenants in cybersecurity…

Think about it as tech debt. You can work a little extra now and take care of future tech debt, or just punt it down the road. As we all know though, fixing tech debt is NOT EASY.

The cost of tech debt is often lack of scalability and/or reliability and/or increased cost.

Here’s a good illustration by Mike Privette from Return on Security

However, in the case of information security, the cost can be a minor, major, or critical vulnerability. Fixing it will take additional engineering time.

How Do We Shift Left In Appsec?

Before I get into the technical aspects, I want to emphasize that shifting left is a CULTURE shift. It’s almost impossible to do it alone. So whether you’re a security engineer, engineering manager, CISO, or CTO… it’s a joint effort. Oftentimes security is leading the charge, but we need the buy-in from engineering.

The old way of doing things was for security to find an issue and throw it over the fence for engineering to fix.

OLD WAY:

Shifting left is a concerted effort to fix code.

Security’s role is help facilitate and make the process as easy as possible for engineering.

However, we can only bring a horse to water.

Security will have to help engineering with the culture shift. It starts both from the top and at the ground level.

DESIRED OUTCOME

Shiftling Left Tactics

Level Up Your Bug Bounty Program

So you have a bug bounty program. Awesome! Now, let’s take it to the next level. This was going to be the entire article, but I decided to expand it a bit and talk about Shifting Left.

JIRA Integration of Bug Bounty

Automate all the things. There are a lot of detailed that can be missed from just opening a simple JIRA ticket saying “Fix XSS flaw”. 

Things that be missed can include:

• Conversation with the security researcher

• Images and videos of proof of concepts

• Attachments

• Severity information

After enabling automatic JIRA integration, all this additional context can be missed. Don’t worry though, JIRA tickets won’t automatically be created from the start, someone, typically the security team, will need to triage and verify the bug, then they can send it to the appropriate JIRA board.

Give Engineers Direct Access To Bug Bounty

One of the first things I advocate security teams to do is get engineers as involved as possible to bug bounty programs.

In the automated JIRA ticket, there will likely be a link back to the original bug. If an engineer wants to review the details on the bug platform, then let’s help them do that a little easier.

In fact, you may likely want to give engineering access in the event you need help triaging or verifying the bug.

Major bug bounty platforms support Single Sign On, so if you have SSO at your organizations, use it. This reduces friction for engineers for them getting access to bug reports.

Security will still triage and verify security issues and can be the primary communication with the researcher, but let’s face it we can’t know everything. What better way than to involve the engineer that will eventually push the fix. They can even discuss optimal ways to fix the problem with the researcher.

Security Engineers Can Make Pull Requests

This is where security can take more of an active role in fixing security issues. If a security engineer knows where the problem is and has identified solutions to the problem, then why not open a pull request?

This goes back to culture. 

Some common reasons this doesn’t happen are:

• Engineering is over protective about their code

• The code is WAY too complicated or brittle (see tech debt)

• Security doesn’t have the skills (soft or hard) in house to do this gracefully

Pre-Commit Checks (Advanced)

Another tactic worth mentioning is pre-commit checks. I call this advanced because there is a lot of heavy lifting required and it directly impacts workflows. Honestly it’s part of a whole bunch of DevSecOps tactics that I won’t go into detail right now. 

However this is a huge prevention tactic that would prevent a key or secret from being committed to source.

Prevention is the ultimate security control, but harder to implement.

Summary

As you can see Shifting Left is a concerted effort and can not be done in a silo. If you try to push too hard or too fast, you fall flat on your face. 

It often comes down to 2 things IMHO:

• Getting everyone aligned on security goals and habits

• Facilitating as much as possible and reducing friction

Hope this was as fun a read as it was to write it. Have a secure week! 💪🏼

Thank you for reading Last Week As A vCISO. This post is public so feel free to share it.