Package Vulnerability Scanning

Let’s consider you are writing an application. To implement the application, you divided the problem into sub-parts and created packages for each. Maybe you wrote these packages yourself or you prefer to use open source 3rd party packages. And everything works perfectly. Now you need to deploy your application or deliver it to your customer. Did you check everything?

So let’s ask one last question, is your app secure enough?

The security of each package you write or use in the applications you create is extremely important. In this article, we will see how to do a security scan on packages.

Let’s take a quick look at the content of the article:

What is package?
Package Vulnerability Scanning
Docker Security Scanning
- Snyk
- Trivy
Lab
- python:3.9
- python:3.9-slim
Extra
- python:3.9-slim vs python:3.9-alpine

What is package?

Packages are software components that perform operations and, when compiled together an application. Though programs are designed for a variety of objectives, the majority of them rely on well-known functionality, such as authentication or compression. As a result, developers frequently design applications by developing parts of their own packages (first party code) and integrating existing packages (third party code) to handle these routine operations.

These existing packages facilitate faster application development and provide access to highly specialized processes that application developers seldom wish to rewrite, but they are risky. This is due to the fact that they are produced and maintained by someone outside of your business or a community of persons (open source code), making it hard to determine whether packages were designed with security in mind. Because many of these third-party software are freely available, attackers can access them and identify techniques to exploit their weaknesses. While using third-party packages speeds up time to market, it also introduces application-layer attack vectors.

Package Vulnerability Scanning

Vulnerability scanning is a basic step toward securing virtually any modern software delivery pipeline. Package scanners significantly reduce the risk of releasing insecure software into production.

Vulnerability scanners can inspect virtually any type of package. They can be used to scan Docker container images, for instance, Debian or RPM packages that developers create to deploy software on Linux systems.

How it works?

Package scanners typically function by determining if the contents of a software package match elements that are known to be vulnerable based on databases that track security issues in applications and libraries. A vulnerability scanner, for example, may identify that a package has a certain version of a software library that contains a known security bug. The scanner would detect the problem and alert developers to the need to update the library to a more recent, secure version. It is critical to note that they only look for issues that have previously been identified in vulnerability databases.

Docker Security Scanning

You might want to read this post to understand more about Docker before continuing.

Finding known security vulnerabilities in the packages mentioned in your Docker image is done through the process of security scanning Docker images. Before publishing an image to Docker Hub or another registry, you can use this to identify vulnerabilities in container images and fix them.

Snyk

The docker scancommand uses a third-party tool, called Snyk Container.

Official definition:

Find and automatically fix vulnerabilities in your code, open source dependencies, containers, and infrastructure as code

Usage:

docker scan <image-name>

You might want to check this cheat sheet before beginning the lab:
Docker Vulnerability Scanning CLI Cheat Sheet

Docker Vulnerability Scanning CLI Cheat Sheet from Snyk

Trivy

Official definition:

Trivy (tripronounced like trigger, vypronounced like envy) is a simple and comprehensive vulnerability scanner for containers and other artifacts. A software vulnerability is a glitch, flaw, or weakness present in the software or in an Operating System.Trivydetects vulnerabilities of OS packages (Alpine, RHEL,CentOS, etc.) and application dependencies (Bundler, Composer, npm, yarn, etc.).Trivy is easy to use. Just install the binary and you're ready to scan. All you need to do for scanning is to specify a target such as an image name of the container.

Trivy can be run in two different modes:

Trivy can scan three different artifacts:

Usage:

trivy image <image-name>

For installation visit this site.

Lab: Get your hands dirty

Think about creating a Flask application.

$ mkdir flask-app
$ cd flask-app

Create a requirements.txt file:

$ nano requirements.txt
----------------------------Flask==2.0.2

Then write flask app:

$ nano app.py
----------------------------from flask import Flask
app = Flask(__name__)@app.route('/')
def hello_world():
    return 'Hello, Docker!'

And now Dockerfile:

$ nano Dockerfile
----------------------------FROM python:3.9WORKDIR /appCOPY requirements.txt requirements.txt
RUN pip3 install -r requirements.txtCOPY . .CMD [ "python3", "-m" , "flask", "run", "--host=0.0.0.0"]

Build your application with tag:

$ docker build -t flask-app .

Flask-app image is created.

Image from author

If you are using Linux, run the following command to manually install the latest version of docker scan:

$ apt-get update && apt-get install docker-scan-plugin

After upgrading docker scan, verify you are running the latest version by running the following command:

$ docker scan --accept-license --version

Everything is fine, let’s scan our image:

$ docker scan flask-app:latest

The scan produced a massive amount of data, the report summary is displayed below.

As you can see in the last line “Tested 3 projects, 1 contained vulnerable paths.” 3 projects are app, libraries and base operating system. These are seen in the figure below:

According to the report, the Python base image contains 299 vulnerabilities in all, of which 4 were critical, 37 were high, 10 were medium, and 248 were low severity.

This is not a surprise; Snyk had made notice of it in their report:

47% of Python projects contain known vulnerabilities
An average vulnerable project consists of 33 known vulnerabilities

However, there is also good news:

We can eliminate 87% of known vulnerabilities by upgrading the vulnerable package
Most container vulnerabilities can be fixed using slimmer image

If you are certain that your base image is current, you might try selecting a slimmer version of it.

Let’s test the 3.9-slim version of Python.

Change the Dockerfile slightly:

FROM python:3.9-slim

Build with different tag:

$ docker build -t flask-app-slim .

Image from author

As can be seen, the image size was decreased from 926 MB to 136 MB.

Now let’s scan:

$ docker scan flask-app-slim:latest

Results from scanning the python:3.9-slim image were significantly better.

Why did the slim version produce better results?

Attack surface is decreased by using a slimmer base image. You can use multi-stage builds, where you start with larger images to make building and testing your code easier and move the necessary production packages to a slim image in the last stage.

Let’s quickly examine a few Python base image choices to see how their sizes and vulnerabilities differ:

For more statistics, check out Snyk Report — September 2021

You can jump into extra step if you’re curious about the alpine version.

Let’s continue to discuss Snyk Advisor

Without effort, you can identify weaknesses in Python base images. You may search and compare more than 1 million open source packages using Snyk Advisor. You can choose a suitable base image in this way quickly and with minimal effort.

More About Python Security

Python security best practices cheat sheet by Snyk

This cheat sheet’s detailed explanation may be found here.

I recommend checking out all of Snyk other security cheat sheets to learn how to stay safe in other ecosystems.

Extra

You could wish to give the alpine version of your Python base image a try, but I should reminder alpine’s drawbacks.

Things start to go wrong when we try to create a package of a Python program using alpine version.

Let’s make a few minor changes to the Dockerfile and requirements,

$ nano requirement.txt
----------------------------Flask==2.0.2
numpy==1.22.4$ nano Dockerfile
----------------------------FROM python:3.9-alpineWORKDIR /appCOPY requirements.txt requirements.txt
RUN pip3 install -r requirements.txtCOPY . .CMD [ "python3", "-m" , "flask", "run", "--host=0.0.0.0"]

Then build image with different tag and time option:

$ time docker build -t python-alpine-numpy .

You will got an error like that:

The cause is that Alpine is incompatible with standard PyPI wheels. You must compile all of the C code in each Python package you use if you’re running Alpine Linux.

Modify the Dockerfile as indicated below:

FROM python:3.9-alpine
RUN apk --update add gcc build-base freetype-dev libpng-dev openblas-devWORKDIR /appCOPY requirements.txt requirements.txt
RUN pip3 install -r requirements.txtCOPY . .CMD [ "python3", "-m" , "flask", "run", "--host=0.0.0.0"]

That was the result:

Image from author

Check out the comparison:

This result showed up after our scan of the Alpine version.

I simply wanted to present some results and comparisons. This is a great article if you want additional information.

Conclusion

We have seen examples of how we can easily scan packages using Docker scan and Trivy. We examined the effect of differences in base images on security vulnerabilities and tried to improve them.

Let us remind you once again that it is necessary to carefully select the image size and version in order to ensure image security without losing the functionality of the application.

Bu Blogda Ara

CRYPTTECH BLOG