Intro#

I’m thinking about what the best way is to manage vulnerability scanning in the SDLC.

Sitting down and really thinking about this is a culmination of talking with coworkers about this for a while, and stuff that’s been happening at work.

Specifically, if the goal is to:

  1. Provide developers vulnerability data as fast as possible
  2. Provide developers vulnerability data in a FULLY automated manner

(Maybe as a bonus, we can also)

  1. Tie a vulnerability to a specific “Artifact” (i.e. Git commit, but could be a software deploy, an update, or some other action)

How do we do that? When do we run security scans?

Let’s see…what do developers create? Developer I/O:

INPUT   Coffee.
OUTPUT  Source code -- features, automation, cool websites, etc;
OUTPUT  Vulnerabilities.

Where should developers receive security information?

As soon as possible!

Mint ice cream feature#

Let’s play pretend for a while.

Here’s a day in the life of a programmer: I’m a software developer, working on a website that people use to purchase ice cream. My job this week is to allow people to purchase Mint ice cream. I am programming and typing on a keyboard, into IntelliJ IDEA or whatever my favorite editor is. I program my classes/methods/functions/arrays/closures/s-expressions/whatever code I need to. Ideally I write unit tests, compile my code, my IDE builds and shows 0 errors and is nice and happy, ideally I run a local deploy, my code runs, no errors, cool! I make a commit in Git, I push my code to the Git repository, I build my code on a build server, deploy it and test in DEV, then in IT/UAT/PROD, and hooray! I have successfully added “Mint” as a flavor to the ice cream website, and we get hundreds of orders a day for Mint ice cream.

WTF is Shift Security Left?#

“Shift Security Left” is about getting security into the SDLC as early as possible. The earliest is: The developer is typing on a keyboard, into a code editor.

Ideally, they should receive information about security vulnerabilities before they check in their source code, but this is not always possible due to the nature of the scanning tool.

There are a few real killer benefits of this “Leftest as possible” approach to providing developers security information, triggered by Git commits/Git merges:

  • Security results are generated ASAP
    • Security results are in front of a dev’s face ASAP
    • It’s fresh in their mind
      • They just coded it
    • They can work on it immediately, don’t have to revisit it later
    • They’re probably less likely to use a “bandaid fix”
  • Security results can (ideally) be tied to an Artifact/Git Ref
  • Security results can be presented to developers ASAP
  • Automation like this can inherently speed up parts of the SDLC
    • …and how fast vulnerabilities get reviewed, evaluated, or fixed

Tool Types and their limitations on how “left” we can shift#

SAST#

Leftmost#

Integrated into an IDE!

The dream: Developers can say, “Oh shit, that does let users open an arbitrary file on the disk by XYZ (Example), let’s fix that real quick. I’m already editing this code anyways.”

A little less left#

Run each time code is committed.

The downside: This is still good, and early, but if a developer has already committed the code: It’s not as “fresh”!

  • It won’t be fresh in their mind
  • Maybe they already merged a branch!
  • Maybe other things have happened after the commit that make it hard for them to revisit the code
  • It might be a little more annoying for them to do this, but it’s better than running scans later.

SCA (OSS)#

Leftmost#

Integrated into the IDE as well!

If a developer realizes, “Oh, I use Log4j version 1.2.3, and it’s vulnerable, I just added it, and haven’t started using it. Might as well upgrade it because my IDE tells me to.”. This is good for the same reasons that integrating SAST results into the IDE (pre-commit) is good.

A little less left#

When a Git push occurs (or generic Version Control System (VCS)).

Again, same issues as SAST. It’s stale in our mind, it’s harder to fix, but this is much better than nothing, because it’s automated by VCS check-in (Git push).

DAST#

Leftmost#

Integrated into a pre-production environment. Ideally, if deploys are FULLY automated, then a merge into a pre-prod Git branch could trigger an automated DAST scan, and provide this information to a developer.

A little less left#

Run each time an application is deployed into DEV. This could occur weekly, monthly, or…whatever the release schedule is. Really not ideal, because depending on the cadence of the release, this might delay results to the dev team.