Shifting Security Testing Left in DevOps

Security Testing Published on:
Shift Left Security

Shift-Left Security Testing

Everything in software development is accelerating.

That means now is the time to develop the right mindset as it relates to security in DevOps.

I recently had Kevin E. Greene as a guest on my security podcast, and he got me to thinking more about this security transformation.

Kevin told me the goal is to get your entire team to think about ways hackers can attack your software; they can use formal threat modeling, misuse, and abuse cases—whatever works.

The key is to get your developers to think carefully about the security design decisions that they make.

Codify as early as possible the security requirements that need to be part of your solution.

This will reduce your risk and reduce the attack surfaces known to be associated with software development.

Why shift security left?

A myth that holds many organizations back is the belief that it's the security team's job to do security for everyone.

That’s the old way of thinking.

Instead, you need to embrace Agile.

The critical aspect is getting everyone on the entire team, including the product team, product owners, product managers, developers and engineers to think about security.

This security-focused collaboration will ensure that everyone is taking shared responsibility when it comes to security.

This will help to build the mindset needed to make an excellent product.

Like most things in the software development lifecycle, the technical stuff is secondary.

Focus on developing a security culture.

This mindset is crucial because you can't build security if you're not thinking about it from the onset.

Security Hacker

DevSecOps Secure Software Best Practices for Developers

For secure software, you need sound security requirements.

This leads to good, security-focused design principles and system architecture choices.

It's vital that developers are aware of security design principles and controls so that when they’re coding, they understand the consequences of their coding on security.

They should also look out for existing code that has security problems.

This approach will also avoid any technical debt.

Simply put, to scale application security, you need to bring in developers.

They have to be a part of it.

Why can't the security team handle everything?

Most have enterprises that have tens of thousands of developers, but only a handful of application security engineers.

This ratio doesn't work out for a security team that is attempting to take care of everything.

There's also a real problem when it comes to being able to hire enough qualified people.

Everyone knows that the real technical security folks are harder to find. They're just not out there.

If only for that reason alone, you need to shift the focus to developers.

Do things earlier.

Empower developers so you can scale application security.

Otherwise, it's a losing battle.

Security Implications in the Software Development Life Cycle

Why is it hard to even get developers interested in software security?

Arthur Hicken from Parasoft told me he sees this often with the development teams his company works with.

For example, he assisted with a simple penetration test at a device manufacturer.

They were hacking into their device with some idiotic, simple automated techniques, and were shocked by what they found without even trying very hard.

The response they got from the development team about their findings was typical.

Have you heard any of these before?

I don't know why that's important.

I don't believe that's important.

That would never happen in production.

I don't see why that one would matter.

The fact is that most developers don't know how security issues occur, or how they look in their development.

So, when you show me something like, say, the Heartbleed bug, they'll say it’s not a big deal.

This kind of mindset can have a devastating impact on your software development.

So how do you fix it?

Application Security Development Training

An essential aspect of creating a more secure code base is developer training.

To avoid costly security bugs getting into a developed application in the first place, engineers must understand offensive and defensive security programming.

They need to be aware of the ways in which attackers are trying to ambush a particular application or system. Understanding secure coding principles is important as well.

One way to get developers more engaged is with hands-on training.

Using security training platforms like HackEDU, developers can log in to a browser application and work with a real-world application with built-in vulnerabilities.

This helps them to use a realistic approach to learning how to find and fix issues.

They’ll also pick up best practices like:

  • Mitigating vulnerabilities
  • How they should be coding
  • What are secure coding techniques?

To see a demo of this type of training check out HackEDU's lesson on SQL injection. An injection attack allows attackers to inject code into a program or query. Injection attacks come in many forms and they explore SQL Injection in this lesson.

I'm still shocked that in this day and age many developers are unaware of this common top ten web application security risk. according to OWASP.

In my own experience, the only way I effectively learn and apply things to my day-to-day job is to learn actionable, real-world techniques.

Security in the SWAMP

Another training option Kevin recommended was SWAMP.

SWAMP is a Homeland Security program and stands for the Software Assurance Marketplace.

The main reason they designed SWAMP was to provide a place for people to test their software.

Kevin said one of the most significant barriers for teams to do some level of software assurance is access to risk, compute power, resources, and tools.

He worked on designing SWAMP to help lower the bar in order to formalize some aspects of software testing assurance.

The goal was to create a platform where there's free computing power, and resources like test data and test targets.

It also has the advantage of leveraging open-source tools.

You can bring your software into their platform, or you can download SWAMP in a box to run your software through and have some level of visibility into what's going on in your software.

Doing this can identify some of the low-hanging fruit as it relates to bugs that can expose vulnerabilities in your software.

As you've seen, training is one key to getting developers more engaged in writing secure code.

But let's be honest.

A lot of what we call “software development” nowadays is just gluing things together.

How's your developer's code hygiene?

Security Hygiene

Component Hygiene Security Vulnerabilities

Jeffrey Martin from WhiteSource says there's not much “software development” going on at most companies.

It's more about using existing components and frameworks to develop and engineer a system.

Because of this, it’s also essential to understand the hygiene of a component, and understanding how these components can potentially expose an attack vector or attack surface that could lead to a security breach.

Did you know that 80% of all code is actually made up of open-source, third-party components, according to WhiteSource research on how developers are taking over application security (AppSec)?

Because of this fact, you can shift security even farther left than other software testing activities like functional testing, because much of security revolves around which third-party components you decide to use.

Your team can detect potential issues before anything even reaches your codebase.

You can do this by looking at the open-source project's repo for the component to see if there are any known vulnerabilities. Also, be sure you are using the most recent version.

This sounds like common sense, but people often bring in older versions, either by accident or because that's what they used last time (or because they're copying a different project).

You can also determine whether a component has known vulnerabilities by looking at the national vulnerability database (NVD).

Of course, if you’re like me and love everything automated, you can use a security tool and automate the whole process.

And actually, several products will give you that information inside your IDE or a browser plugin before you even implement it.

For example, MicroFocus Fortify offers this functionality in IDEs like Visual Studio and Eclipse.

It's a product called Security System.

It's fantastic to be able to give that initial feedback to developers as they're creating code.

One of the easiest places to start your security testing efforts, according to Adhiran Thirmal of MicroFocus is through static analysis.

To be able to take a look throughout your actual application to identify vulnerabilities that might exist within your code and be able to start mitigating there.

That's the first action that you can make, and you can do that using a security tool like Fortify Static Code Analyzer or using Fortify On Demand.

These tools will automatically tell you whether a component has known vulnerabilities.

It doesn't get much more left than that.

It’s also essential to maintain component hygiene over time.

Software applications are constantly evolving sprint over sprint.

You need to be able to verify the security of your code during every sprint.

It’s also helpful to keep an inventory of everything you're using so that you're alerted when new vulnerabilities pop up.

You can then remediate the issue as part of your sprint.

At some point, it becomes a good use case for automation, so you need to integrate these checks into your continuous integration (CI) and continuous delivery (CD) pipelines and have it as automated as possible.

At a minimum, you want security tools that will let you and your developers know when there is an issue as soon as they check-in code.

The automation should assist your team in detecting what you have, match it correctly to the right repos, the right sources, then give you the information to understand the problem and the right path towards a solution.

Shift-Left Security—More Than a Catch Phrase.

Shifting left security has to evolve into something more than a catchy phrase.

Your product team (and the organization at large) must be thinking about security from the onset.

You should also be thinking about ways in which software can be attacking misuse and abuse.

If you do that, you can be well on your way to improving the health and hygiene of your software.

The bigger picture: remember that software is part of every aspect of our lives, powering everything from critical infrastructure to hospitals, medical care, and automobiles.

By focusing on security in your software, you’ll be doing your part to improve the confidence of software worldwide.

Secure Guild 2020

Another great way to educate your developers and testers about security testing is the annual SecureGuild online conference. Why not register your whole team now to jump-start your companies culture of security

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Shift Left Security