Blog

Ubuntu Docker Container Scanning – Is it enough to protect your app?

In this post, we are going to look at Docker container scanning:

  1. First, we will build an Ubuntu Docker container, add some software to it, run a Docker scan, and record the vulnerabilities.
  2. Then, we will try to resolve some of those vulnerabilities, run another scan, and examine the results.
  3. Finally, we will determine whether container scanning is enough to protect your applications and data from compromise. 

Building the Docker Container

We will build our Ubuntu Docker container using the Ubuntu Xenial image. Since it is a few versions behind, it will hopefully contain a few vulnerabilities. We are also going to install Python, PIP3, and a vulnerable version of urllib3. If we search the CVE database, we find CVE-2021-28363. According to this CVE, the urllib3 library 1.26.x before 1.26.4 omits SSL certificate validation in some cases involving HTTPS to HTTPS proxies.

The first step in our process is to pull the Ubuntu Xenial Docker image from Docker Hub and run it as a container on our Docker host. The command below will get the image, start the container in interactive mode, and name it ubuntu_xenial. 

docker run -it –name ubuntu_xenial ubuntu:xenial

Once the process completes, you will be presented with the Ubuntu prompt, as shown in the text output below.

PS C:\Users\docker> docker run -it --name ubuntu_xenial ubuntu:xenial

Unable to find image 'ubuntu:xenial' locally

xenial: Pulling from library/ubuntu

80bce60046fa: Pull complete

55a738a15540: Pull complete

e19cf0706c62: Pull complete

de4cdd6c27d1: Pull complete

Digest: sha256:9775877f420d453ef790e6832d77630a49b32a92b7bedf330adf4d8669f6600e

Status: Downloaded newer image for ubuntu:xenial

root@a317929cf5d7:/#

The next step is to install Python and PIP by running the following command:

apt update && apt install python3-pip

root@a317929cf5d7:/# apt update && apt install python3-pip

Get:1 http://archive.ubuntu.com/ubuntu xenial InRelease [247 kB]

Get:2 http://security.ubuntu.com/ubuntu xenial-security InRelease [109 kB]

Get:3 http://archive.ubuntu.com/ubuntu xenial-updates InRelease [109 kB]

Get:4 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages [2051 kB]
.....
Fetched 19.4 MB in 42s (458 kB/s)

Reading package lists... Done

Building dependency tree

Reading state information... Done

5 packages can be upgraded. Run 'apt list --upgradable' to see them.

Reading package lists... Done

Building dependency tree

Reading state information... Done
.....
The following packages will be upgraded:

libc6

1 upgraded, 85 newly installed, 0 to remove and 4 not upgraded.

Need to get 98.7 MB of archives.

After this operation, 289 MB of additional disk space will be used.

Do you want to continue? [Y/n]

 

After installing Python and PIP, we are ready to install urllib3. However, since the development team fixed the vulnerability in version 1.26.4, we need to install an earlier vulnerable version. For the purposes of this exercise, let’s install version 1.26.0 from requirements.txt. 

We can check that our requirements.txt file includes our vulnerable version by running the cat command.

root@a317929cf5d7:/# cat requirements.txt

urllib3==1.26.0

We can use PIP to install the  requirements.txt file.

pip3 install -r requirements.txt

root@a317929cf5d7:/# pip3 -r requirements.txt

Collecting urllib3==1.26.0

  Downloading https://files.pythonhosted.org/packages/7e/a7/746338eb8addda2e7662ee5e10a9f85150aba013cd610c9569c17146b914/urllib3-1.26.0-py2.py3-none-any.whl (136kB)

    100% |################################| 143kB 3.9MB/s

Installing collected packages: urllib3

Successfully installed urllib3-1.26.0

You are using pip version 8.1.1, however version 21.1.2 is available.

You should consider upgrading via the 'pip install --upgrade pip' command.

root@a317929cf5d7:/urllib3_test# pip3 freeze requirements.txt

urllib3==1.26.0

You are using pip version 8.1.1, however version 21.1.2 is available.

You should consider upgrading via the 'pip install --upgrade pip' command.

Now that we have updated our container, it is time to commit it and create our image by running the following Docker command from the docker host.

docker commit ubuntu_xenial

PS C:\Users\docker> docker commit ubuntu_xenial

sha256:130de6a9e3822dd3bbf19131469f3de441967756cd6faf70f52c92183ddea37e

Let’s check that Docker created the image by running the docker images command.

docker images

As we can see in the text output below, Docker created the image. 

PS C:\Users\docker> docker images

REPOSITORY   TAG      IMAGE ID      CREATED              SIZE

<none>      <none>    130de6a9e382   About a minute ago   465MB

ubuntu       xenial   9ff95a467e45   12 days ago          135MB

However, to make our lives easier, let’s give the new image a tag to identify it by running the following command.

docker tag 130de6a9e382 our_ubuntu_image

If we rerun the docker images command, we can see that Docker updated the information.

PS C:\Users\docker> docker tag 130de6a9e382 our_ubuntu_image

PS C:\Users\docker> docker images

REPOSITORY         TAG       IMAGE ID       CREATED        SIZE

our_ubuntu_image  latest   130de6a9e382   3 minutes ago   465MB

ubuntu             xenial    9ff95a467e45   12 days ago     135MB

As Docker’s scanning feature only works on images and not containers, we are now ready to scan the image for any vulnerabilities. Let’s start the Docker container scanning by running the following command.

docker scan our_ubuntu_image

PS C:\Users\docker> docker scan our_ubuntu_image

Docker Scan relies upon access to Snyk, a third party provider, do you consent to proceed using Snyk? (y/N)docker y

/ Analyzing container dependencies for our_ubuntu_image

/ Querying vulnerabilities database...

Once the scan completes, the final report indicates 193 issues, as shown in the text output below.

Package manager:  deb

Project name:     docker-image|our_ubuntu_image

Docker image:     our_ubuntu_image

Platform:         linux/amd64

Licenses:        enabled

Tested 185 dependencies for known issues, found 193 issues.

Vulnerability Analysis and Resolution

If we study the vulnerability report, we find that Docker container scanning highlights some vulnerabilities that can be fixed, as shown in the text output below.

✗  Low severity vulnerability found in glibc/libc-bin

  Description: Improper Data Handling

  Info: https://snyk.io/vuln/SNYK-UBUNTU1604-GLIBC-345675

  Introduced through: glibc/libc-bin@2.23-0ubuntu11.2, meta-common-packages@meta

  From: glibc/libc-bin@2.23-0ubuntu11.2

  From: meta-common-packages@meta > glibc/multiarch-support@2.23-0ubuntu11.2

  Fixed in: 2.23-0ubuntu11.3

✗ Low severity vulnerability found in glibc/libc-bin

  Description: Integer Underflow

  Info: https://snyk.io/vuln/SNYK-UBUNTU1604-GLIBC-571388

  Introduced through: glibc/libc-bin@2.23-0ubuntu11.2, meta-common-packages@meta

  From: glibc/libc-bin@2.23-0ubuntu11.2

  From: meta-common-packages@meta > glibc/multiarch-support@2.23-0ubuntu11.2

  Fixed in: 2.23-0ubuntu11.3

If we look at the message for the two vulnerabilities in the image, we need to update those particular packages to resolve the issue. First, we need to create a container from the new image to make sure we are working with the latest version. As we did previously, we need to execute the docker run command as shown in the image below.

docker run -it –name our_ubuntu_image our_ubuntu_image

PS C:\Users\docker> docker run -it --name our_ubuntu_image our_ubuntu_image

root@0dfcbff2e3d1:/#

After executing the docker run command, we can run the following commands to update Ubuntu from the container’s command line.

apt update && apt upgrade

root@0dfcbff2e3d1:/# apt update && apt upgrade

Hit:1 http://security.ubuntu.com/ubuntu xenial-security InRelease

Hit:2 http://archive.ubuntu.com/ubuntu xenial InRelease

Hit:3 http://archive.ubuntu.com/ubuntu xenial-updates InRelease

Hit:4 http://archive.ubuntu.com/ubuntu xenial-backports InRelease

Reading package lists... Done

Building dependency tree

Reading state information... Done

4 packages can be upgraded. Run 'apt list --upgradable' to see them.

Reading package lists... Done

Building dependency tree

Reading state information... Done

Calculating upgrade... Done

The following packages will be upgraded:

  apt libapt-pkg5.0 libc-bin multiarch-support

4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Need to get 2458 kB of archives.

After this operation, 70.7 kB of additional disk space will be used.

Do you want to continue? [Y/n]

After running and installing the updates, we need to commit and create another Docker image to save the changes. 

docker commit our_ubuntu_image

PS C:\Users\docker> docker commit our_ubuntu_image

sha256:bf5809ae94d91ea37ac94fcc7260d607d15925347267bba911e9d3e2308dd93f

We can check that Docker created the image successfully by running the docker images command.

docker images

As we can see in the text output below, Docker confirms the new updated image exists.

PS C:\Users\docker> docker images

REPOSITORY         TAG       IMAGE ID       CREATED          SIZE

<none>             <none>    bf5809ae94d9   2 minutes ago    476MB

our_ubuntu_image   latest    130de6a9e382   19 minutes ago   465MB

ubuntu             xenial    9ff95a467e45   12 days ago      135MB

As we did before, let’s give the new image a tag to identify it by running the following command.

docker tag bf5809ae94d9 updated_ubuntu_image

If we rerun the docker images command, we can see that Docker updated the information.

PS C:\Users\docker> docker tag bf5809ae94d9 updated_ubuntu_image

PS C:\Users\docker> docker images

REPOSITORY             TAG       IMAGE ID       CREATED          SIZE

updated_ubuntu_image   latest    bf5809ae94d9   3 minutes ago   476MB

our_ubuntu_image       latest    130de6a9e382   21 minutes ago 465MB

ubuntu                 xenial    9ff95a467e45   12 days ago       135MB

We are now ready to scan the updated container to see if our efforts resolved any vulnerabilities. As before, to run docker scan execute the following command. Note that we are now scanning our updated image.

docker scan updated_ubuntu_image

PS C:\Users\docker> docker scan updated_ubuntu_image

/ Analyzing container dependencies for updated_ubuntu_image

/ Querying vulnerabilities database...

Once the scan completes, the final report indicates 191 issues, as shown in the text output below. This result demonstrates that updating our Ubuntu container resolved two vulnerabilities. 

Package manager:    deb

Project name:      docker-image|updated_ubuntu_image

Docker image:      updated_ubuntu_image

Platform:          linux/amd64

Licenses:         enabled

Tested 185 dependencies for known issues, found 191 issues.

However, if we search both the original vulnerability report and the report generated after our updates, neither report contains an alert for CVE-2021-28363. If you recall, when we created our image, we installed a vulnerable version of urllib3. Since neither scan picked up this vulnerability, we need to consider alternatives that mitigate this risk.

MergeBase Vulnerability Analysis and Resolution

To test the validity of Docker scan’s analysis and reporting, let’s run the same scans using MergeBase.

As in the first example, we first need to run a scan on the Docker image named our_ubuntu_image before we run any Ubuntu updates. 

First, we need to get the docker image repository and tag by running the following command:

docker images

As we can see in the text output below, the repository name is ‘our_ubuntu_image,’ and its tag is ‘latest.’

REPOSITORY TAG IMAGE ID CREATED SIZE

our_ubuntu_image latest 130de6a9e382 18 minutes ago 462MB

ubuntu xenial 9ff95a467e45 3 weeks ago 135MB

Using the MergeBase command-line tool, we can scan this image using the following command:

java -jar mergebase.jar –mode=profile –name=our_ubuntu_image our_ubuntu_image:latest

If we look at the summary scan report on the MergeBase portal, we can see that it found 301 vulnerabilities. This number exceeds the 193 found by Docker scan by 108 vulnerabilities.

Below is the text output from the command-line tool. As you can see, it details multiple CVEs and categorizes them by severity.

java -jar mergebase.jar --mode=profile --name=updated_ubuntu_image updated_ubuntu_image:latest

Saving application profile to https://demo.mergebase.com

  Vulnerable Files Overview

  =========================

  CRITICAL (12)

  -----

  CVE-2017-7614, CVE-2017-7226, CVE-2017-6969 (binutils@2.26.1-1ubuntu1~16.04.8.UBUNTU)

  CVE-2017-8283 (dpkg-dev@1.18.4ubuntu1.7.UBUNTU)

  CVE-2017-8283 (dpkg@1.18.4ubuntu1.7.UBUNTU)

  CVE-2019-18218 (file@5.25-2ubuntu1.4.UBUNTU)

  CVE-2008-1530 (gnupg@1.4.20-1ubuntu3.3.UBUNTU)

  CVE-2016-6309 (openssl@1.0.2g-1ubuntu4.19.UBUNTU)

  CVE-2017-12814 (perl-base@5.22.1-9ubuntu0.9.UBUNTU)

  CVE-2017-12814 (perl@5.22.1-9ubuntu0.9.UBUNTU)

  CVE-2018-1126 (procps@3.3.10-4ubuntu2.5.UBUNTU)

  CVE-2020-15801, CVE-2017-1000158 (python3.5-minimal@3.5.2-2ubuntu0~16.04.13.UBUNTU)

  CVE-2020-15801, CVE-2017-1000158 (python3.5@3.5.2-2ubuntu0~16.04.13.UBUNTU)

  CVE-2018-20839, CVE-2018-15688, 2 more... (systemd@229-4ubuntu21.31.UBUNTU)

  EXTRA-HIGH (7)

  -----

  CVE-2019-3462 (apt@1.2.35.UBUNTU)

  CVE-2016-7543 (bash@4.3-14ubuntu1.4.UBUNTU)

  CVE-2020-6096 (libc-bin@2.23-0ubuntu11.3.UBUNTU)

  CVE-2020-6096 (libc-dev-bin@2.23-0ubuntu11.3.UBUNTU)

  CVE-2019-11922 (libzstd1@1.3.1+dfsg-1~ubuntu0.16.04.1.UBUNTU)

  CVE-2017-17522 (python3.5-minimal@3.5.2-2ubuntu0~16.04.13.UBUNTU)

  CVE-2017-17522 (python3.5@3.5.2-2ubuntu0~16.04.13.UBUNTU)

  HIGH (18)

  -----

  CVE-2018-6557 (base-files@9.4ubuntu4.13.UBUNTU)

  CVE-2019-18276, CVE-2017-5932, CVE-2016-0634 (bash@4.3-14ubuntu1.4.UBUNTU)

  CVE-2021-3549, CVE-2021-20294, 73 more... (binutils@2.26.1-1ubuntu1~16.04.8.UBUNTU)

  CVE-2015-8865, CVE-2014-9653 (file@5.25-2ubuntu1.4.UBUNTU)

  CVE-2021-3345, CVE-2019-14855, 2 more... (gnupg@1.4.20-1ubuntu3.3.UBUNTU)

  CVE-2018-5733, CVE-2018-5732, CVE-2017-3144 (isc-dhcp-client@4.3.3-5ubuntu12.10.UBUNTU)

  CVE-2021-3326, CVE-2019-9192, 4 more... (libc-bin@2.23-0ubuntu11.3.UBUNTU)

  CVE-2021-3326, CVE-2019-9192, 4 more... (libc-dev-bin@2.23-0ubuntu11.3.UBUNTU)

  CVE-2016-6305 (openssl@1.0.2g-1ubuntu4.19.UBUNTU)

  CVE-2018-6952, CVE-2018-6951, CVE-2018-20969 (patch@2.7.5-1ubuntu0.16.04.2.UBUNTU)

  CVE-2016-2381 (perl@5.22.1-9ubuntu0.9.UBUNTU)

  CVE-2018-1125, CVE-2018-1124, 2 more... (procps@3.3.10-4ubuntu2.5.UBUNTU)

  CVE-2019-20916 (python3-pip@8.1.1-2ubuntu0.6.UBUNTU)

  CVE-2020-26116, CVE-2019-16056, 3 more... (python3.5-minimal@3.5.2-2ubuntu0~16.04.13.UBUNTU)

  CVE-2020-26116, CVE-2019-16056, 3 more... (python3.5@3.5.2-2ubuntu0~16.04.13.UBUNTU)

  CVE-2020-1712, CVE-2019-3844, 8 more... (systemd@229-4ubuntu21.31.UBUNTU)

  CVE-2016-6321 (tar@1.28-2.1ubuntu0.2.UBUNTU)

  CVE-2018-7738 (util-linux@2.27.1-6ubuntu3.10.UBUNTU)

  MEDIUM (18)

  -----

  CVE-2018-0501, CVE-2016-1252 (apt@1.2.35.UBUNTU)

  CVE-2016-9401 (bash@4.3-14ubuntu1.4.UBUNTU)

  CVE-2021-3487, CVE-2021-20284, 80 more... (binutils@2.26.1-1ubuntu1~16.04.8.UBUNTU)

  CVE-2017-18018 (coreutils@8.25-2ubuntu3~16.04.UBUNTU)

  CVE-2017-1000249, CVE-2014-9621, CVE-2014-9620 (file@5.25-2ubuntu1.4.UBUNTU)

  CVE-2011-2207 (gnupg@1.4.20-1ubuntu3.3.UBUNTU)

  CVE-2019-20795 (iproute2@4.3.0-1ubuntu3.16.04.5.UBUNTU)

  CVE-2020-27618, CVE-2019-7309, 7 more... (libc-bin@2.23-0ubuntu11.3.UBUNTU)

  CVE-2020-27618, CVE-2019-7309, 7 more... (libc-dev-bin@2.23-0ubuntu11.3.UBUNTU)

  CVE-2021-24032, CVE-2021-24031 (libzstd1@1.3.1+dfsg-1~ubuntu0.16.04.1.UBUNTU)

  CVE-2018-0739, CVE-2016-6308, CVE-2016-6307 (openssl@1.0.2g-1ubuntu4.19.UBUNTU)

  CVE-2019-20633, CVE-2016-10713 (patch@2.7.5-1ubuntu0.16.04.2.UBUNTU)

  CVE-2021-3426, CVE-2020-8492, 4 more... (python3.5-minimal@3.5.2-2ubuntu0~16.04.13.UBUNTU)

  CVE-2021-3426, CVE-2020-8492, 4 more... (python3.5@3.5.2-2ubuntu0~16.04.13.UBUNTU)

  CVE-2020-13776, CVE-2020-13529, 3 more... (systemd@229-4ubuntu21.31.UBUNTU)

  CVE-2021-20193 (tar@1.28-2.1ubuntu0.2.UBUNTU)

  CVE-2016-5011 (util-linux@2.27.1-6ubuntu3.10.UBUNTU)

  CVE-2021-28363 requirements.txt (urllib3@1.26.0)

  LOW (4)

  -----

  USN-3156-0002 (apt@1.2.35.UBUNTU)

  CVE-2020-35448 (binutils@2.26.1-1ubuntu1~16.04.8.UBUNTU)

  CVE-2019-1552 (openssl@1.0.2g-1ubuntu4.19.UBUNTU)

  USN-4120-0002, CVE-2019-20386, 2 more... (systemd@229-4ubuntu21.31.UBUNTU)

Included in the list of vulnerabilities identified by MergeBase is the vulnerable version of urllib3 we installed.

To ensure we are comparing like for like, we should also run the MergeBase scan on the updated image after applying the Ubuntu updates as we did with Docker scan. We can reuse the same MergeBase command line after updating the relevant parameters.

java -jar mergebase.jar –mode=profile –name=updated_ubuntu_image updated_ubuntu_image:latest

Interestingly, the results for the updated Ubuntu image are identical before and after running the updates. 

We can deduct the following outcomes from this exercise:

  1. Docker Scan and MergeBase find different vulnerabilities on the same containers.
  2. MergeBase provides far more detailed results when it comes to the actual software components installed on a container. The text output from the command line tool and the report it generates even details the relevant CVEs. 
  3. The Docker scan results change after running system updates while Mergebase remains the same. This difference indicates that Docker scan focuses more on the operating system while MergeBase concentrates on its specialty, Software Composition Analysis.

Container Scanning Limitations

Our rudimentary experiment shows that default container scanning solutions do not find application-layer vulnerabilities. Consequently, even though these tools provide a critical service that helps you find security issues in your containerized application, they do not offer a complete solution. For example, if we build a Python app and use the vulnerable urllib3 library, our containerized app is not secure. In that instance, a container scan will not show any vulnerabilities, but an attacker could create a rogue certificate authority and compromise your containerized service.

However, this simple illustration is only one example. If we consider that researchers found 18,325 vulnerabilities in 2020 and 7,545 in the first five months of 2021, protecting your containerized application requires multiple layers of security. If you only rely on container scanning solutions, you are not getting the visibility you need for application-layer vulnerabilities, as our urllib3 example demonstrates. What you need is a layered defense-in-depth security approach. 

Defense in Depth for Containerized Applications

While containerized applications offer several benefits such as application consistency, scalability, and cost-effectiveness, managing all the moving parts that provide the platform running your app can be challenging. Since hosts, images, and containers make up a standard Docker architecture, a vulnerability in any of these three critical components could lead to a security incident. 

For example, should a threat actor manage to compromise an image on Docker Hub, it could lead to a devastating supply chain attack. A vulnerability in your Docker host, whether you use a cloud platform, Windows, or Linux server, could also lead to a compromise of your container. Finally, there is the container itself. As we have illustrated with our simple example, standard container scanning apps do not find application-layer vulnerabilities. 

Implementing defense-in-depth security for your containerized application requires a holistic approach. First, you need to secure your platform from external threats by implementing the relevant network segmentation, firewalls, and similar technologies that prevent unauthorized access. Then you need to continuously harden your hosts, images, and containers by leveraging Docker container scanning and implementing patches and upgrades. 

The final element you need to secure in your defense-in-depth strategy is your application layer. Since firewalls, and vulnerability scanners that focus on hosts, images, and containers, do not identify any application-related security threats, you need a solution to identify and mitigate this risk. As our example illustrated, Software Composition Analysis (SCA) tools like MergeBase, provide visibility into the real risk of enterprise applications. Since most, if not all, modern applications leverage external libraries and packages, identifying vulnerabilities in these elements is vital in securing your application. If we revisit our urllib3 example, scanning the containerized application with an SCA tool like MergeBase found the vulnerability and 107 others the Docker scan failed to identify.

Container Security Tools Comparison for Vulnerability Scans

Recently, we took on a new challenge: compare 5 popular container security tools, including our solution. We wanted to see how the products stack up against each other. How did they do? Read on to find out!

TL; DR:

Containers have been causing waves in IT and dev circles since 2013 when Docker’s container technology was launched. They have revolutionized deployment adding both speed and stability and have become critical for most IT operations, so securing them is a priority for all of us. How well do various tools do that? See the table below:

ToolStep 1 (Squid)Step 2 (Patched)Step 3 (Add App)Result
MergeBase312ALL
Aqua000NONE
Snyk2002
Docker Hub1001
Quay000NONE

But before we get into the details, it’s worthwhile to quickly revisit the importance of application container security in the modern-day development landscape.

The Importance of Container Security

Containers enable developers to run applications quickly and reliably when moved from one computing environment to another. But despite their many advantages – including increased application isolation – containers also amplify security risks. Increasing adoption in production environments makes them attractive to malicious actors. Since traditional network security solutions cannot always protect against lateral attacks, a lot of effort goes into developing application container security solutions.

Container security refers to the tools (e.g. Docker container security solutions) and policies implemented to protect container integrity and reliability, mitigate risk, and minimize vulnerabilities.

Container Security Tools Compared

To protect containers from attacks, many security tools are available. Usually, they audit the Common Vulnerabilities and Exposures (CVE) set by the National Vulnerability Database (NVD), or the benchmarks set by the Center for Internet Security (CIS).
Most containerized applications and their underlying infrastructure are distributed widely and highly dynamic. In this scenario, manual vulnerability scanning can be time-consuming and resource-intensive. To reduce operational overhead, many tools offer automation. Some focus on specific aspects of the cloud-native ecosystem, e.g. runtime security.
For our analysis, we picked 5 popular automated container scanners:

  • Aqua
  • Snyk
  • Docker Hub
  • Quay
  • MergeBase

Methodology

Before starting our analysis, we set up three images. The images are a logical progression where start with a vulnerable version of squid, then patch it and then add a vulnerable proprietary library, a proxy for applications you might produce and deploy in Docker images

container scanning expectations
  1. Seeded with a vulnerable version of Squid, a caching and forwarding HTTP web proxy
  2. Patch Squid to latest safe version
  3. Download a proprietary jar file that is vulnerable. Your own applications would typically fall in this category and it is challenging for most container scanning tools to analyze these.

We expected that each application would find vulnerabilities in all these steps.

However, this is not quite what happened!

Before we reveal the results of our tool comparison, here’s a sequence of steps that shows the Docker files used to build the images. Also, for readers planning to replicate our experiment, bear in mind that vulnerability scanning is sensitive to the date of the scan. We completed this experiment in early April 2021. New vulnerabilities may have been found and published since then, and security scanning tools themselves may have also changed.

Procedure to Build Images with Docker Files

If you need the build scripts, please ask us. We believe in transparency and are happy to provide them.

Results of Container Scanner Tool Comparison & Analysis

1. Aqua

For teams wondering how to secure Docker containers, Aqua claims to provide “enterprise-grade security for Docker environments” from development to production. Its tool scans images for vulnerabilities, malware, configuration issues, etc. for continuous image assurance. Its vulnerabilities database is aggregated from multiple, constantly-updated data streams to increase detection accuracy and provide better protection.

Aqua container scanning did not find any vulnerabilities

Despite these claims, the tool didn’t quite make the cut in our test. In fact, Aqua found no vulnerabilities at all, raising doubts about its effectiveness.

2. Snyk

Snyk helps teams automatically find, prioritize and fix vulnerabilities in containers throughout the container lifecycle. It can detect vulnerable dependencies during coding, prevent new vulnerabilities from passing through the build process, and test the production environment for newly-disclosed vulnerabilities.

Snyk says that it has fixed over 5 million container vulnerabilities. But during our tests, Snyk found two vulnerabilities in Step 1:

  • CVE-2020-25097 (Squid)
  • CVE-2021-30139 (apk-tools)

Snyk did not find any vulnerabilities from Steps 2 and 3.

3. Docker Hub

Docker hub container scanning did find only one vulnerability

When a Docker image is pushed to Docker Hub, it automatically scans it for vulnerabilities. Teams can review the security state of images, and fix identified issues for more secure deployments. The vulnerability report displays vulnerabilities, and sorts them according to severity. It also displays information about the:

  • Package containing the vulnerability
  • Version in which it was introduced
  • Whether the vulnerability is fixed in a later version

In our analysis, we found that this Docker container security scanner is not effective at finding all vulnerabilities. During testing, it only found one vulnerability from Step 1.

4. Quay

Quay container scanning did not find any vulnerabilities

Quay automatically scans containers to provide a real-time view of known vulnerabilities. The scan report displays vulnerabilities by severity level: Low, Medium and High. It also specifies whether patches are available.

But in our vulnerability test, Quay found no vulnerabilities. For all 3 steps, the report displayed a “passed” status for the security scan.

And now, we come to the final tool in our analysis: our own MergeBase tool.

5. MergeBase

In our analysis, only MergeBase found all vulnerabilities, including those the other tools missed:

MergeBase container scanning finds all vulnerabilities
  • CVE-2021-28116 (Squid) for which no patch is available
  • CVE-2016-5725 in the application, a directory traversal vulnerability in JCraft JSch before 0.1.54 on Windows, when the mode is ChannelSftp (source: CVE Mitre)

In summary, MergeBase found:

  • 3 vulnerabilities in Step 1
  • 1 vulnerability in Step 2
  • 2 vulnerabilities in Step 3

Comparison Conclusion

In containerized environments, the deployment pipeline is often standardized across different dev teams. Container scanning can help find vulnerabilities and take proactive action to fix security gaps. Securing containers and building security into the CI/CD their pipeline can help reduce the size of the attack surface.

However, different container scanning solutions yield inconsistent results on the same environment. Worse, many solutions fall short of their claims to help strengthen end-to-end container security.

In our analysis of 5 application container security tools, we found that our tool MergeBase was the only one that could find all vulnerabilities in our testing environment. Thus, compared to other tools, MergeBase provides complete DevSecOps coverage and reliable container security.

Want to know more about MergeBase? Take a look here!

Enhance software supply chain security says White House

Summary

The White House exec order to improve the software supply chain security
White House executive cyber security order

Software supply chain security is a common theme in recent attacks such as on the Colonial Pipeline and SolarWinds. In response, President Biden released an executive order to improve the nation’s cyber security. The order is a testimony of the importance of the digital ecosystem today to our society, economy and way of life. Cyber security is critical in protecting it and the President’s clear message is that we need to do more.

The government want to improve its own cyber security practices and related agencies. It also proposes to remove barriers for information sharing, and enhancing software supply chain security. The software supply chain security is the only specific attack vector that is highlighted.

These attacks cause the most damage and at the same time businesses and governments are ill prepared. So what is a supply chain attack and how can it be mitigated?

What is a Software Supply Chain Attack?

A supply chain attack leverages the access of an external partner or provider to gain unauthorized entry to a system or network. It takes advantage of the inherent trust a target has in its suppliers, using it to infiltrate and launch the cyber-attack. Its use of stealth and its indirect ‘trusted’ approach make a supply chain attack an effective weapon in any threat actor’s arsenal.

Every organization and individual relies on third-party software in some way or another. When we install software, hardware, or use code from a trusted source, it is natural to assume that it hides no malicious intent. In addition to this inherent trust, a supply chain attack also uses the human element to bypass any perimeter security. As administrative users and software developers install software, hardware, or reuse third-party code, they do so on the internal network, bypassing any security controls that prevent external threats.

Supply chain attacks that target technology infrastructure come in many variations. Threat actors can infiltrate a software provider and embed malicious code that infects end users when they install or access the product. Another effective supply chain attack technique is infecting software code repositories that software developers leverage to create systems. Finally, threat actors can also infiltrate and infect the embedded software that operates the hardware on networking equipment, servers, and end-user devices.

What is a software supply chain?

Modern software development processes rely on code reuse to build systems rapidly and cost-effectively. By leveraging existing code, developers can quickly assemble a system with its needed components instead of coding the entire solution from a blank canvas. Typically, programmers either reuse internally developed software code or leverage third-party libraries and frameworks. These components and their dependencies form part of the software supply chain. In other words, a software supply chain is a list of elements that goes into or affects the code from development to production.

Almost every software application or service we use today leverages a software supply chain. For example, Netflix and Uber use Node.js, an open-source, server-side JavaScript platform that is well suited for scalable applications. Another example is WordPress, a content management system used to run nearly 40% of the world’s websites. The list goes on, but it suffices to say that organizations leverage software supply chains everywhere. Besides leveraging the frameworks and platforms mentioned, software developers also use code libraries to build their solutions. Services like GitHub and StackOverflow are valuable resources where developers can find libraries, code snippets, and advice to help them create solutions.

However, a software supply chain does not only pertain to software development. It can also refer to instances where organizations install and run third-party applications in their technology environment. For example, every organization leverages third-party software for email. It would be both inefficient and expensive to develop an in-house solution for this utility. The same goes for system monitoring, file sharing, security, and other commodities in a technology environment. All these third-party applications and the external code it uses in its custom-developed applications form part of an organization’s software supply chain.

The anatomy of a supply chain attack

A supply chain attack infects the third-party technologies organizations use. It then leverages this unauthorized access to infiltrate and attack their primary targets. Typically, supply chain attacks start when threat actors exploit a vulnerability to gain access to a supplier’s systems. Once they have gained entry, they embed malicious code into the supplier’s software or hardware with a particular payload. The threat actor then waits until the target organization or user runs the supplier’s infected software or installs its infected hardware. As this infiltration technique circumvents any perimeter security, its indirect attack methodology is highly effective. It is also successful in gaining access to secure environments as these attacks typically target less secure elements in the supply chain.

Supply chain attacks are not a new type of threat, but recent cases have raised their prominence in the public domain. If we look at past instances, the Target data breach where malware infected their Point of Sale systems occurred in 2013. In that instance, the attackers compromised the organization’s third-party refrigerator vendor to infect Target’s POS environment with malware that stole credit card details. Another significant example is the famous Stuxnet malware that nation-states used to sabotage Iran’s nuclear centrifuges in 2010. In this example, the attackers used the digital certificates of Realtek Semiconductor to make their malware look legitimate to system administrators and evade anti-virus.

More recently, in the SolarWinds supply chain attack, threat actors deployed malware during a routine update that emanated from SolarWinds’ servers. Every organization that ran the update was subsequently compromised, including technology companies and secure government agencies. As a result of this attack, the United States sanctioned Russia, believing that the Kremlin played a role in this mass infiltration. Other recent supply chain attacks include the narrowly averted PHP backdoor and the Code Dev incident.

These supply chain attack examples show that this technique has successfully infected many organizations around the world. What is of particular concern is that these supply chain attacks also succeeded in highly secure environments. The examples also show the extensive ramifications of a successful attack. One undetected infection can affect thousands of users and organizations.

Software supply chain security, the open-source risk

Many organizations use open-source software in some way, shape, or form. With open-source code present in 90% of modern applications, this vital element in the software development ecosystem is vulnerable to a supply chain attack. The recent PHP case mentioned earlier is a prime example. Modern software applications reuse open-source libraries, frameworks, and code snippets. Threat actors target these components as they are typically less secure.

The 2020 Sonatype State of the Software Supply Chain Report stated next-generation attacks increased by 430% in the preceding 12 months. Unlike commercial software, open-source relies on the community to ensure its security. However, it is up to the organizations that use the software to conduct regular analysis, security audits, and penetration tests.

Technology supply chain risk

The technology supply chain includes hardware and software. Although the focus of this article has been on software supply chain attacks, organizations cannot ignore the hardware risk. Numerous examples of mobile devices arriving with embedded malware and compromised networking equipment used to breach secure networks highlight this threat.

These instances illustrate that business and technology leaders need to consider their entire technology ecosystem when assessing their supply chain risk. As threat actors have shown they can infiltrate hardware vendors, global software corporations, and open-source code repositories, organizations need a comprehensive security strategy. A supply chain attack could come from multiple vectors, and enterprises need to ensure they cover all their bases.

Software supply chain security 

Mitigating the risk of a supply chain attack requires a defense-in-depth approach. Organizations need to conduct thorough security assessments and implement multiple measures to minimize this risk. For example, many regulatory security frameworks such as PCI DSS and the NIST Cybersecurity Framework mention supply chain risk. These compliance standards state that organizations should routinely assess third parties to ensure they comply with any contractual obligations.

As part of the contractual obligations organizations enforce on their suppliers, security testing must form a vital part of any technology deliverable. By placing the responsibility on the vendor to ensure their product is safe, organizations can enforce terms should the vendor fail to meet their obligations. In addition to requiring vendors to test, organizations should also implement internal security testing and monitoring. This layered defensive approach can help them identify any security issues the vendors may have missed.

However, when leveraging open-source software, enforcing contractual terms is not an option. As many open-source technologies come with set licensing terms, it compounds the problem even further. Organizations also need to consider the license and infringement risk, restricting how the company can use the software while protecting itself from a supply chain attack. In these instances, leveraging the services of a Software Composition Analysis (SCA) tool like MergeBase mitigates this open-source risk. As the onus is on the organization to test and validate the open-source components used in an application, an SCA tool like MergeBase adds the required defensive layer.

According to this Gartner Report, the information security of a supply chain must focus on data and IT infrastructure, products, and operations. If we consider the various security technologies in place at enterprises today, organizations implement a myriad of defensive technologies and processes. Firewalls, intrusion detection and prevention solutions, segmented networking, and vulnerability scanners are just some of the solutions that protect their IT landscape. However, these solutions typically safeguard against external threats. Organizations need to ensure the configuration of these platforms also scan and detect any internal anomalies which may indicate a successful supply chain attack.

Enterprises can also consider air gapping systems to mitigate the supply chain risk. Applications and networks not connected to the Internet have a much lower risk of compromise. However, in many cases, this approach is not feasible. They are also not foolproof. The Stuxnet example mentioned earlier was a successful attack against an air-gapped system.

Securing the software supply chain

Supply chain attacks target less secure elements in complex systems. As modern technology solutions rely on reusable components, threat actors target these elements to circumvent security controls. This type of cyber-attack is not new. However, recent discoveries have highlighted the risk organizations face. Traditionally, organizations have tailored their security solutions to mitigate external threats. With the increase in supply chain attacks, it is clear that threat actors target the supply chain to circumvent these controls.

The supply chain attack risk covers every element of an organization’s IT landscape. Attackers have succeeded in infiltrating the supply chain of hardware and software elements. With software development components being a key area of risk, organizations need to implement controls that ensure the security of their application ecosystem.

The MergeBase platform specializes in software supply chain security. It mitigates the risk of a software supply chain attack from development to production. It highlights risks and empowers developers to remedy any security issues during the early stages of the software development lifecycle. MergeBase also assesses software components for vulnerabilities during the build process, ensuring organizations do not release insecure code to production. However, once an application is in production, it may not remain secure. Researchers or threat actors discover software vulnerabilities all the time. MergeBase mitigates this risk with its monitoring and alerting capabilities keeping organizations protected against any new vulnerabilities in production.

What is a supply chain attack?

Summary

harbour part of a traditional supply chain

A supply chain attack leverages the access of an external partner or provider to gain unauthorized entry to a system or network. It takes advantage of the inherent trust a target has in its suppliers, using it to infiltrate and launch the cyber-attack. Its use of stealth and its indirect ‘trusted’ approach make a supply chain attack an effective weapon in any threat actor’s arsenal.

Every organization and individual relies on third-party software in some way or another. When we install software, hardware, or use code from a trusted source, it is natural to assume that it hides no malicious intent. In addition to this inherent trust, a supply chain attack also uses the human element to bypass any perimeter security. As administrative users and software developers install software, hardware, or reuse third-party code, they do so on the internal network, bypassing any security controls that prevent external threats.

Supply chain attacks that target technology infrastructure come in many variations. Threat actors can infiltrate a software provider and embed malicious code that infects end users when they install or access the product. Another effective supply chain attack technique is infecting software code repositories that software developers leverage to create systems. Finally, threat actors can also infiltrate and infect the embedded software that operates the hardware on networking equipment, servers, and end-user devices. 

What is a software supply chain?

Modern software development processes rely on code reuse to build systems rapidly and cost-effectively. By leveraging existing code, developers can quickly assemble a system with its needed components instead of coding the entire solution from a blank canvas. Typically, programmers either reuse internally developed software code or leverage third-party libraries and frameworks. These components and their dependencies form part of the software supply chain. In other words, a software supply chain is a list of elements that goes into or affects the code from development to production. 

Almost every software application or service we use today leverages a software supply chain. For example, Netflix and Uber use Node.js, an open-source, server-side JavaScript platform that is well suited for scalable applications. Another example is WordPress, a content management system used to run nearly 40% of the world’s websites. The list goes on, but it suffices to say that organizations leverage software supply chains everywhere. Besides leveraging the frameworks and platforms mentioned, software developers also use code libraries to build their solutions. Services like GitHub and StackOverflow are valuable resources where developers can find libraries, code snippets, and advice to help them create solutions. 

However, a software supply chain does not only pertain to software development. It can also refer to instances where organizations install and run third-party applications in their technology environment. For example, every organization leverages third-party software for email. It would be both inefficient and expensive to develop an in-house solution for this utility. The same goes for system monitoring, file sharing, security, and other commodities in a technology environment. All these third-party applications and the external code it uses in its custom-developed applications form part of an organization’s software supply chain.

The anatomy of a supply chain attack

A supply chain attack infects the third-party technologies organizations use. It then leverages this unauthorized access to infiltrate and attack their primary targets. Typically, supply chain attacks start when threat actors exploit a vulnerability to gain access to a supplier’s systems. Once they have gained entry, they embed malicious code into the supplier’s software or hardware with a particular payload. The threat actor then waits until the target organization or user runs the supplier’s infected software or installs its infected hardware. As this infiltration technique circumvents any perimeter security, its indirect attack methodology is highly effective. It is also successful in gaining access to secure environments as these attacks typically target less secure elements in the supply chain.

Supply chain attacks are not a new type of threat, but recent cases have raised their prominence in the public domain. If we look at past instances, the Target data breach where malware infected their Point of Sale systems occurred in 2013. In that instance, the attackers compromised the organization’s third-party refrigerator vendor to infect Target’s POS environment with malware that stole credit card details. Another significant example is the famous Stuxnet malware that nation-states used to sabotage Iran’s nuclear centrifuges in 2010. In this example, the attackers used the digital certificates of Realtek Semiconductor to make their malware look legitimate to system administrators and evade anti-virus.  

More recently, in the SolarWinds supply chain attack, threat actors deployed malware during a routine update that emanated from SolarWinds’ servers. Every organization that ran the update was subsequently compromised, including technology companies and secure government agencies. As a result of this attack, the United States sanctioned Russia, believing that the Kremlin played a role in this mass infiltration. Other recent supply chain attacks include the narrowly averted PHP backdoor and the Code Dev incident.

These supply chain attack examples show that this technique has successfully infected many organizations around the world. What is of particular concern is that these supply chain attacks also succeeded in highly secure environments. The examples also show the extensive ramifications of a successful attack. One undetected infection can affect thousands of users and organizations.

The open-source risk

Many organizations use open-source software in some way, shape, or form. With open-source code present in 90% of modern applications, this vital element in the software development ecosystem is vulnerable to a supply chain attack. The recent PHP case mentioned earlier is a prime example. Modern software applications reuse open-source libraries, frameworks, and code snippets. Threat actors target these components as they are typically less secure. 

The 2020 Sonatype State of the Software Supply Chain Report stated next-generation attacks increased by 430% in the preceding 12 months. Unlike commercial software, open-source relies on the community to ensure its security. However, it is up to the organizations that use the software to conduct regular analysis, security audits, and penetration tests. 

Technology supply chain risk

The technology supply chain includes hardware and software. Although the focus of this article has been on software supply chain attacks, organizations cannot ignore the hardware risk. Numerous examples of mobile devices arriving with embedded malware and compromised networking equipment used to breach secure networks highlight this threat. 

 These instances illustrate that business and technology leaders need to consider their entire technology ecosystem when assessing their supply chain risk. As threat actors have shown they can infiltrate hardware vendors, global software corporations, and open-source code repositories, organizations need a comprehensive security strategy. A supply chain attack could come from multiple vectors, and enterprises need to ensure they cover all their bases. 

Mitigating supply chain risk

Mitigating the risk of a supply chain attack requires a defense-in-depth approach. Organizations need to conduct thorough security assessments and implement multiple measures to minimize this risk. For example, many regulatory security frameworks such as PCI DSS and the NIST Cybersecurity Framework mention supply chain risk. These compliance standards state that organizations should routinely assess third parties to ensure they comply with any contractual obligations. 

 As part of the contractual obligations organizations enforce on their suppliers, security testing must form a vital part of any technology deliverable. By placing the responsibility on the vendor to ensure their product is safe, organizations can enforce terms should the vendor fail to meet their obligations. In addition to requiring vendors to test, organizations should also implement internal security testing and monitoring. This layered defensive approach can help them identify any security issues the vendors may have missed. 

However, when leveraging open-source software, enforcing contractual terms is not an option. As many open-source technologies come with set licensing terms, it compounds the problem even further. Organizations also need to consider the license and infringement risk, restricting how the company can use the software while protecting itself from a supply chain attack. In these instances, leveraging the services of a Software Composition Analysis (SCA) tool like MergeBase mitigates this open-source risk. As the onus is on the organization to test and validate the open-source components used in an application, an SCA tool like MergeBase adds the required defensive layer.

According to this Gartner Report, the information security of a supply chain must focus on data and IT infrastructure, products, and operations. If we consider the various security technologies in place at enterprises today, organizations implement a myriad of defensive technologies and processes. Firewalls, intrusion detection and prevention solutions, segmented networking, and vulnerability scanners are just some of the solutions that protect their IT landscape. However, these solutions typically safeguard against external threats. Organizations need to ensure the configuration of these platforms also scan and detect any internal anomalies which may indicate a successful supply chain attack.

Enterprises can also consider air gapping systems to mitigate the supply chain risk. Applications and networks not connected to the Internet have a much lower risk of compromise. However, in many cases, this approach is not feasible. They are also not foolproof. The Stuxnet example mentioned earlier was a successful attack against an air-gapped system. 

Securing the software development supply chain

Supply chain attacks target less secure elements in complex systems. As modern technology solutions rely on reusable components, threat actors target these elements to circumvent security controls. This type of cyber-attack is not new. However, recent discoveries have highlighted the risk organizations face. Traditionally, organizations have tailored their security solutions to mitigate external threats. With the increase in supply chain attacks, it is clear that threat actors target the supply chain to circumvent these controls. 

The supply chain attack risk covers every element of an organization’s IT landscape. Attackers have succeeded in infiltrating the supply chain of hardware and software elements. With software development components being a key area of risk, organizations need to implement controls that ensure the security of their application ecosystem.

The MergeBase platform mitigates the risk of a software supply chain attack from development to production. It highlights risks and empowers developers to remedy any security issues during the early stages of the software development lifecycle. MergeBase also assesses software components for vulnerabilities during the build process, ensuring organizations do not release insecure code to production. However, once an application is in production, it may not remain secure. Researchers or threat actors discover software vulnerabilities all the time. MergeBase mitigates this risk with its monitoring and alerting capabilities keeping organizations protected against any new vulnerabilities in production.

Open Source Risk: Plugging the hole

"The leak was worse than first thought" notes a bypasser of a boy stuck head-first into the wall of a digital dyke. Plug you open source holes with a SCA tool

Origin 

Software development based on the sharing and collaborative improvement of software source code goes back to its very origins. 

In the late 1990s, the term “open-source” was coined and received mainstream recognition in publications such as Forbes. The Netscape browser’s source code was made open source and that got a lot of attention.

The original open-source projects were “revolutions” against the “unfair” profits that closed-source software companies were reaping. Microsoft, Oracle, SAP and others, it was argued, were extracting monopoly-like “rents” for software, which the top developers of the time did not believe was world class.

Open Source Growth

Open source software was originally created by developers for developers. It was embraced slowly by more and more projects, organisations and companies and it now forms the foundation for the Internet and most of our digital assets. The code base of a typical modern application consists of 80 to 90% of open source software. Even in something as proprietary as Apple’s iPhone, the operating system consists largely of open source software. 

Currently, there are close to 1 million open source projects globally and this number increases by 79% a year

Open source victorious as last ones standing capitulate

Apple and Google embraced open source more than 20 years ago. The champions of proprietary software, IBM and Microsoft, resisted much longer. 

  “Once open source gets good enough,
competing with it would be insane.”

2006, Larry Elison, the chairman of Oracle in conversation with the Financial Times

Elison was right on the mark. It looks like we reached that point a few years ago. IBM and Microsoft were the last ones standing against open source, but  in the end they capitulated. IBM acquired RedHat  early 2019 for $34B and Microsoft acquired GitHub for $7.5B in 2018.

Open source use a surprise to many executives

Many organizations where leadership does not have a strong engineering or technical background often do not fully realize yet the importance of open source and how dependent they are on it in their digital supply chain. We regularly encounter executives who are very surprised when we analyze their applications and identify many open source libraries. Awareness is the first step in managing open source risk and rewards.

Open Source Risks: Is it really free?

Open source is bringing huge rewards to business. However, with reward comes open source risk. The two main risks are legal related to the licenses  and cyber risk related to vulnerabilities. 

Open source is free but can come with strings attached that do not match with your organization’s business model. Open source software is released under different licensing models. There are over 300 licensing models in use. Most open source software comes with friendly licenses such as the licenses for Apache and BSD. However other licensing models not so much, such as licenses for GNU GPL and GNU Affero. Use of these licenses, even in a minor way, could force an organisation to open source their entire software with devastating impact on the IP value of the organisation.  

Open source software, like all software, can contain vulnerabilities. Open source software, in general, is high quality software and not intrinsically more vulnerable. However, because of its wide usage, it is a very attractive target for cyber adversaries and so, over time, vulnerabilities are uncovered. At the moment, there are more than 150,000 known vulnerabilities. A lot of these vulnerabilities can be exploited to breach organisations and are considered to be the cause of approximately 25% of data breaches. 

One example of a major breach is the Equifax breach which exposed 145 million client records and cost the organisation more than $1.3 B to remediate. The company also lost $5B in stock market value overnight and later received a $700 M fine from the US government. 

The best defence: SCA / OSS

The best defense against open source risk is to use a Software Composition Analysis tool, sometimes also called Open Source Security scanner. These tools quickly analyse your applications or containers and provide insight into license and cyber risk. MergeBase goes a step further and provides solutions to quickly and easily reduce your cyber risk. 

A Critical Look at Cyber Investment

What is the top defensive technology area to invest in right now?

Cyber defense is a global whack-a-mole game with hundreds of billions of dollars being invested in offensive and defensive capabilities. After you invest in one area, another area of risk tends to pop up. What is the top defensive technology area to invest in right now?

Cyber is multifaceted

Cyber defense requires a multifaceted approach. Fragmentation is a natural consequence of the back and forth between cyber attackers and defenders: If we have an effective defence against a particular type of attack, adversaries will try another area, angle, or approach. Over time this means we need many technologies to secure our organisation. Like it or not, cyber defence is a global whack-a-mole game. It is an arms race, with governments and corporations investing hundreds of billions of dollars continuously in building out offensive and defensive capabilities.

We all know that we need a multifaceted approach. This involves people, process and tools. We need to make sure that everyone in the organization is motivated and has the skills and resources to fight cybercrime. Beyond understanding why and how, technology is critically important as cyberspace is tech heavy.

What area do we need to invest in?

Unless you feel at ease with your cyber protection, the question is: What is the key technology area to invest in right now? This question is very difficult for most cyber professionals as most organizations under fund and under resource their cyber operations.

We posed this question to cyber professionals by posting a poll to LinkedIn. To eliminate bias, we conducted the poll twice (second poll), reaching out to two distinct networks of cyber professionals. Feel free to repost the poll and let us know what your results are.

The poll asked what areas to focus on: MFA, perimeter security, known vulnerabilities or education. The results, which were consistent between the two polls, were: known vulnerabilities at 49% , MFA at 29%, and perimeter and education each approximately at 10%.

Known vulnerabilities routinely exploited

The results of the poll make a lot of sense. Of course, all these areas are important and really need more investment. However, the NSA and CISA continue to warn that cyber adversaries routinely exploit known vulnerabilities..

If we look at major breaches, we see plenty of evidence supporting these warnings. Sophisticated attackers use a combination of hacking techniques, as we have seen recently with SolarWinds. Exploiting known application vulnerabilities is a big part of their arsenal and allows adversaries to move laterally and subsequently elevate privileges.

In reality we find that very few organizations are able to execute fully on a vulnerability strategy.

Why can we not eliminate known vulnerabilities?

Why are we not able to routinely eliminate our known application vulnerabilities? The answer is that it is a daunting task given the level of software that most organisations are operating in combination with the level of technical debt that most of these applications suffer from. Some cyber experts call for continuous upgrading of all components. That would eliminate these problems. However, continuous upgrading is difficult for organisations that have a lot of applications. For instance, a typical North American bank has 600 software applications. Large banks tend to have many more. A lot of these applications are older and do not have active development. Therefore, routinely upgrading may not be practical.

Discover More from MergeBase

Core Product

BuildGreen is a powerful solution for identifying the real risk of open source at build time or in existing applications

Learn how BuildGreen can protects your Enterprise

Add RunTime Protection

RunGreen detects and defends against known-vulnerabilities at runtime.

Learn why Runtime Protection Matters

Optional Developer Add-on

CodeGreen is an early-warning defence for your in-house development and integrates directly into code repositories

Quick Start - For Free