DevSecOps 101 part 1: Detecting Insecure Dependencies (SCA)

In this tutorial, we will learn how to detect and avoid vulnerable dependencies when developing applications, by taking a voluntary vulnerable python app as an example.

DevSecOps 101 part 1: Detecting Insecure Dependencies (SCA)

I have been crawling through software engineering and cybersecurity blogs for a few years now, and I have always been surprised by the lack of cybersecurity resources targeting developers. Like if the cybersecurity and the developer community barely spoke to each other.

Our goal at Escape is to be a gap closer between those two worlds, thus I took this opportunity to write a full guide explaining how to secure an application during the development process. This guide targets CTOs, engineering leads, and developers. Therefore, it does not require any prior knowledge in cybersecurity.

To put it in practice, we will add complete security testing to Damn Vulnerable Python Web Application throughout the whole guide. DVPWA, as its name tells, is a vulnerable web app written in python. We will take Github Actions as an example of CI/CD, though this will be mostly generalizable

Security Step 1: Detecting Insecure Dependencies 🎯

The first step towards building more secure apps is detecting and avoid using dependencies that have known vulnerabilities. This process is called Software Component Analysis or SCA.

There are a few commercial options like Snyk, but for this tutorial, we will use the open-source pip package safety.

First, let's clone DVPWA, create a virtual environment, and install the dependencies.

git clone git@github.com:anxolerd/dvpwa.git
cd dvpwa
python3 -m virtualenv .venv && source .venv/bin/activate
pip install -r requirements.txt

Now, let's install safety and run it

pip install safety
safety check --full-report

Simple, right? You should obtain the following output:

With several additional vulnerabilities. Notice that safety, as most SCA tools, gives information on the package version for which the vulnerability has been fixed. Good guy safety.

Now we know which of our packages are vulnerable, but what about triggering safety inside the CI/CD?

Integrating SCA into the CI/CD process ⚙️

Let's add a Github workflow to our repository first. Create a: .github/workflows/main.yaml  file and copy the following content inside:

on: [push]

jobs:
  dependency_analysis:
    runs-on:  ubuntu-latest
    name: Test dependencies for security flaws
    steps:
      - uses: actions/checkout@v2
      - name:
        run: pip3 install safety && safety check
        shell: bash

And then commit it:

git add .github/ && git commit -m"Add safety SCA to CI"
git push origin master

Click on the actions tab of your dvpwa's repository on Github, you should see the following:

Notice that the action failed, which is perfectly normal since dvpwa uses a lot of insecure dependencies. Yay, our damn vulnerable app is less vulnerable now! 🍾

Conclusion! 😎

In just a few minutes, we added a first security step inside our CI/CD! Of course, we focused on Python in this tutorial, but SCAs exist for most common languages, and most of them work in the same way.

In the next tutorial, we will have a look at code analysis, aka programs that read your code to find security flaws inside.

Wanna know more about Security practices? Check out our blog post "9 GraphQL Security Best Practices" and learn how to build safe GraphQL APIs.


Automated security testing

Just like performance and reliability, security is a requirement to ship production-ready applications. But GraphQL just lacked the proper tooling so many teams just skipped security...

That's why at Escape, we created the first GraphQL Security scanner that allows developers to find and fix vulnerabilities in GraphQL applications during the development lifecycle before they even reach production!

Escape

It understands the business logic of GraphQL APIs and looks for more than 50 kinds of vulnerabilities so that you never have to worry again about

  • Resolver performance (N+1 issues, cyclic queries, query complexity DOS…)
  • Tenant isolation (access control, data segregation between users…)
  • Sensitive data leaks (personally identifiable information, tokens, stack traces, secrets…)
  • Injections (SQL, NoSQL, XSS…) and requests forgery

We constantly update our engine with state-of-the-art GraphQL Security research so that you never have to worry about the security of your GraphQL application again!

Start monitoring the security of your endpoints today with a 7-day free trial.
Get results in one minute – no credit card required.