Hands-on guide: How to scan and block container images to mitigate SBOM attacks

According to OpenLogic’s Open Source Adoption and Expansion in 2022 Report, the adoption of Open Source Software (OSS) across all sizes of organizations is rising with 40% of respondents stating an increase of OSS software over the previous year and 36% reporting a significant increase in OSS software usage. The increase in OSS adoption can be attributed to a number of factors including access to the latest innovations, reduction in costs and frequent product updates. However, leveraging community contribution introduces the potential for malicious code to be attached. For example, a series of 2022 case studies conducted by the Package Analysis project, part of the Open Source Security Foundation (OpenSSF), details a number of malicious packages from widely used repositories such as PyPi and NPM. Therefore, it is essential to determine the vulnerabilities in any container image before its deployment into the environment. Calico Cloud’s Image Assurance capabilities enables Vulnerability Assessment for any image. We often hear this referred to as Image Scanning.

Looking for vulnerabilities in images

In order to assess the posture of container images the components that make up an image must be broken down. We refer to this inventory as the Software Bill of Materials (SBOM). This is necessary in order for each component’s known vulnerabilities to be obtained in isolation. A single vulnerable component can lead to a compromise.

In this example we list the software inventory for an alpine image with tag 3.10.1 using docker’s inbuilt SBOM command:

❯ docker sbom tigeralabs.azurecr.io/chris-demo/alpine:3.10.1
Syft v0.43.0
 ✔ Pulled image
 ✔ Loaded image
 ✔ Parsed image
 ✔ Cataloged packages      [14 packages]

NAME                    VERSION      TYPE
alpine-baselayout       3.1.2-r0     apk
alpine-keys             2.1-r2       apk
apk-tools               2.10.4-r2    apk
busybox                 1.30.1-r2    apk
ca-certificates-cacert  20190108-r0  apk
libc-utils              0.7.1-r0     apk
libcrypto1.1            1.1.1c-r0    apk
libssl1.1               1.1.1c-r0    apk
libtls-standalone       2.9.1-r0     apk
musl                    1.1.22-r2    apk
musl-utils              1.1.22-r2    apk
scanelf                 1.2.3-r0     apk
ssl_client              1.30.1-r2    apk
zlib                    1.2.11-r1    apk

Calico’s Image Scanner also performs the SBOM breakdown and cross references each component against known vulnerability databases which determine the severity of the vulnerability by its Common Vulnerability Scoring System (CVSS) score out of 10 where 10 marks a critical vulnerability.. By setting Failure and Warning thresholds for CVSS scores we are able to arrive at a vulnerability verdict:

❯ ❯ tigera-scanner scan tigeralabs.azurecr.io/chris-demo/alpine:3.10.1 -f 7.0 -w 3.9
NOTE: using config file found at: /Users/chrisman/.tigera-scanner.yaml.
INFO[0000] Vulnerability database director not set, setting it to the cache default direct /Users/chrisman/Library/Caches.

 scanning tigeralabs.azurecr.io/chris-demo/alpine:3.10.1...
NOTE: Uploading results, this might take a while...
NOTE: Uploaded vulnerability results for repository path / digest tigeralabs.azurecr.io/chris-demo/alpine:3.10.1@sha256:57334c50959f26ce1ee025d08f136c2292c128f84e7b229d1b0da5dac89e9866

Note: Calculating scan results using scan thresholds passed locally. This does not take into account the exception data you may have configured on Calico Cloud.



 Name: tigeralabs.azurecr.io/chris-demo/alpine:3.10.1
 Digest: sha256:57334c50959f26ce1ee025d08f136c2292c128f84e7b229d1b0da5dac89e9866
 Number of dependencies: 14.
 Total vulnerabilities: 76, critical: 10, high: 38, medium: 24, low: 4, N/A: 0

 Scan result:   ✖ FAIL (warn_threshold - 3.9, fail_threshold - 7.0, Using local thresholds)

|  DEPENDENCY  | SEVERITY |     CVE-ID     | CVSS |          DESCRIPTION           |      FIX RESULT      |                                                      REFERENCES                                                       |
| libcrypto1.1 | Critical | CVE-2021-3711  |  9.8 | In order to decrypt SM2        | unknown              | https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3711,                                                         |
|              |          |                |      | encrypted data an application  |                      | http://www.openwall.com/lists/oss-security/2021/08/26/2                                                               |
|              |          |                |      | is expected to call the API    |                      |                                                                                                                       |
|              |          |                |      | function EVP_PKEY_decrypt().   |                      |                                                                                                                       |
|              |          |                |      | Typically an application will  |                      |                                                                                                                       |
|              |          |                |      | call this...                   |                      |                                                                                                                       |
| libcrypto1.1 | Critical | CVE-2022-1292  |  9.8 | The c_rehash script does       | unknown              | https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1292,                                                         |
|              |          |                |      | not properly sanitise shell    |                      | https://cert-portal.siemens.com/productcert/pdf/ssa-953464.pdf                                                        |
|              |          |                |      | metacharacters to prevent      |                      |                                                                                                                       |
|              |          |                |      | command injection. This        |                      |                                                                                                                       |
|              |          |                |      | script is distributed by some  |                      |                                                                                                                       |
|              |          |                |      | operating systems...           |                      |
*remaining output omitted for brevity

76 vulnerabilities were found! As the Fail threshold was set to 7.0 any vulnerabilities with a CVSS score greater than 7.0 would classify the scan result as Fail. Therefore, we know this image requires further attention and we should not let this get deployed into our environment without further attention.

Reviewing scan results

Our scan has returned local output, listing all the discovered vulnerabilities and CVSS scores. This is great for assessing the scan details in real time but let’s build upon what we can do with the results. The scanner is able to upload the results to Calico Cloud where further details can be examined and we can start evaluating the risks.

Fig. 1: Image scanning in Calico

Here we can see the images that have been scanned in the cluster. Notice the SHA digest matches the beginning of the SHA256 digest from our scan. We can be certain this is the same image. When selecting the image a list of all the vulnerabilities with their CVSS scores are displayed.

Clicking on a specific CVE provides further info for the vulnerability:

Fig. 2: Detailed CVE info

Managing the Risks

Identifying critical severities in images before deployment warrants further investigation and subsequent discussions with development teams may be necessary to mitigate the use or implementation of vulnerable libraries, packages etc. However, there may be instances where certain vulnerabilities have limited or no impact and the associated risks are acceptable. An example could be if the vulnerability is in a component that has been mitigated or addressed in some other way. For instance, compensating mechanisms have been implemented, such as access and authorization controls, we may choose to accept the vulnerability.

In other words we want to make exceptions for these vulnerabilities in order for our scan results to change state. We are able to create an exception for any of these vulnerabilities but also define whether we create the exception for a specific image and tag, any image in a repository, or for any image.

Fig. 3: Adding a vulnerability exception

Once all exceptions have been made we can see the Scan result has changed to a Pass verdict and the vulnerabilities excepted are marked by the ⚠ icon. We’ve now made an informed decision to accept known risks with the image. Why is this useful?

Fig. 4: Image scanning results

The scan results can be used to determine whether scanned images can be deployed into our environment. In the next Blog we share how Calico’s Admission Controller is able to validate the deployment of any image based upon it’s Image Scan result and other factors such as the image’s repository and the time elapsed since the last scan.

Also, Calico Cloud provides a Runtime view of the images deployed into each of your clusters. This is important especially as zero day threats are discovered. It’s very possible that images scanned upon deploy time return no or low risk vulnerabilities but upon discovery of new threat suddenly the vulnerability risk increases for these images. Therefore, if images are only scanned upon build and/or deploy time we potentially risk running vulnerable images which threat actors may look to target.


Open Source Software adoption is rapidly increasing which brings many benefits to enterprises and the community. However, this new approach increases the risks from Software Supply Chain attacks in the form of vulnerable images which may be leveraging insecure libraries and packages. It is imperative to perform image scanning during Build, Deploy and Runtime in order to limit exposures to vulnerabilities in the software components that make up these images. It is also important to recognize that not all discovered vulnerabilities may be applicable in a given application stack or environment. Therefore, agile teams need methods to be able to assess each vulnerability and determine whether the risks are relevant. This will speed up the software delivery process whilst providing the right level of protection.

Read our free eBook to learn how to adopt a holistic approach to container and cloud-native application security and observability.

Join our mailing list

Get updates on blog posts, workshops, certification programs, new releases, and more!