Friends of OpenJDK Today

Kicking the Tires of Docker Scout

February 08, 2024

Author(s)

  • Avatar photo
    Nicolas Frankel

    Nicolas is a developer advocate with 15+ years experience consulting for many different customers, in a wide range of contexts (such as telecoms, banking, insurances, large retail and public sector). ... Learn more

I never moved away from Docker Desktop.

For some time, after you use it to build an image, it prints a message:

What's Next?
  View a summary of image vulnerabilities and recommendations → docker scout quickview

I decided to give it a try. I'll use the root commit of my OpenTelemetry tracing demo. Let's execute the proposed command:

docker scout quickview otel-catalog:1.0

Here's the result:

    ✓ Image stored for indexing
    ✓ Indexed 272 packages
  Target               │  otel-catalog:1.0        │    0C     2H    15M    23L
    digest             │  7adfce68062e            │
  Base image           │  eclipse-temurin:21-jre  │    0C     0H    15M    23L
  Refreshed base image │  eclipse-temurin:21-jre  │    0C     0H    15M    23L
                       │                          │
What's Next?
  View vulnerabilities → docker scout cves otel-catalog:1.0
  View base image update recommendations → docker scout recommendations otel-catalog:1.0
  Include policy results in your quickview by supplying an organization → docker scout quickview otel-catalog:1.0 --org <organization>

Docker gives out exciting bits of information:

  • The base image contains 15 middle-severity vulnerabilities and 23 low-severity ones
  • The final image has an additional two high-level severity
  • Ergo, our code introduced them!

Following Scout's suggestion, we can drill down the CVEs:

docker scout cves otel-catalog:1.0

This is the result:

    ✓ SBOM of image already cached, 272 packages indexed
    ✗ Detected 18 vulnerable packages with a total of 39 vulnerabilities
## Overview
                    │       Analyzed Image
────────────────────┼──────────────────────────────
  Target            │  otel-catalog:1.0
    digest          │  7adfce68062e
    platform        │ linux/arm64
    vulnerabilities │    0C     2H    15M    23L
    size            │ 160 MB
    packages        │ 272
## Packages and Vulnerabilities
   0C     1H     0M     0L  org.yaml/snakeyaml 1.33
pkg:maven/org.yaml/[email protected]
    ✗ HIGH CVE-2022-1471 [Improper Input Validation]
      https://scout.docker.com/v/CVE-2022-1471
      Affected range : <=1.33
      Fixed version  : 2.0
      CVSS Score     : 8.3
      CVSS Vector    : CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L
   0C     1H     0M     0L  io.netty/netty-handler 4.1.100.Final
pkg:maven/io.netty/[email protected]
    ✗ HIGH CVE-2023-4586 [OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities]
      https://scout.docker.com/v/CVE-2023-4586
      Affected range : >=4.1.0
                     : <5.0.0
      Fixed version  : not fixed
      CVSS Score     : 7.4
      CVSS Vector    : CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

The original output is much longer, but I stopped at the exciting bit: the two high-severity CVEs, First, we see the one coming from Netty still needs to be fixed - tough luck. However, Snake YAML fixed its CVE from version 2.0 onward.

I'm not using Snake YAML directly; it's a Spring dependency brought by Spring. Because of this, no guarantee exists that a major version upgrade will be compatible. But we can surely try. Let's bump the dependency to the latest version:

<dependency>
    <groupId>org.yaml</groupId>
    <artifactId>snakeyaml</artifactId>
    <version>2.2</version>
</dependency>

We can build the image again and check that it still works. Fortunately, it does. We can execute the process again:

docker scout quickview otel-catalog:1.0

Lo and behold, the high-severity CVE is no more!

  ✓ Image stored for indexing
  ✓ Indexed 273 packages
Target     │  local://otel-catalog:1.0-1  │    0C     1H    15M    23L
  digest   │  9ddc31cdd304                │
Base image │  eclipse-temurin:21-jre      │    0C     0H    15M    23L

Conclusion

In this short post, we tried Docker Scout, the Docker image vulnerability detection tool. Thanks to it, we removed one high-level CVE we introduced in the code.

To go further:


Originally published at A Java Geek on January 14th, 2024

Sponsored Content

Declutter Your Code: Your Undead Code Is A Time Vampire

The average Java application contains somewhere between 10 to 50% dead code. In this webinar we'll discuss ways of monitoring JVMs across different environments to identify what runs or doesn't run in each, identify what you can get rid of, and how to work better on these larger applications.

Sign Up Here

Topics:

Related Articles

View All

Author(s)

  • Avatar photo
    Nicolas Frankel

    Nicolas is a developer advocate with 15+ years experience consulting for many different customers, in a wide range of contexts (such as telecoms, banking, insurances, large retail and public sector). ... Learn more

Comments (1)

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

Highlight your code snippets using [code lang="language name"] shortcode. Just insert your code between opening and closing tag: [code lang="java"] code [/code]. Or specify another language.

Save my name, email, and website in this browser for the next time I comment.

Java Weekly, Issue 529 | Baeldung

[…] >> Kicking the Tires of Docker Scout [foojay.io] […]

Subscribe to foojay updates:

https://foojay.io/feed/
Copied to the clipboard