Author: Dan Nurmi

Anchore Enterprise Now Supports SBOM Import From ‘docker sbom’

Posted on by Dan Nurmi

Recently, Docker and Anchore worked together to deliver a new operation within Docker Desktop for generating a container image software bill of materials (SBOM) using native Docker tools. The core functionality for generating an SBOM comes from Anchore’s open-source Syft project, which can be accessed as a command line tool or used as a library for other tools to integrate with (as is the case with our collaboration with Docker).

Anchore provides a number of open-source and commercially available software tools for managing SBOMs and providing security/compliance insights and enforcement capabilities against those generated SBOMs. Our general approach to securing modern software development systems embraces the user’s automation and development flexibility objectives, handling large and dynamic software production flows. To facilitate this, the Anchore Enterprise platform effectively conforms to a pattern where:

  1. Existing software development infrastructure is instrumented with light-weight tooling that is pointed at a software element (source code checkout, container image, etc.) to generate an SBOM, and then
  2. The tooling imports that SBOM into a deployment of Anchore Enterprise which stores the SBOM for further processing, at which point the full capabilities of Anchore Enterprise can be applied to the software SBOM.

The Anchore Enterprise client that implements the SBOM generation and import steps is named ‘anchorectl’, a lightweight CLI tool that is included with the Anchore Enterprise platform.

As part of our ongoing commitment to support integration with Docker’s native tooling and approach to SBOM generation, we’ve recently released a new version of anchorectl, available to all Anchore Enterprise users, with added support for importing an SBOM directly from new ‘docker sbom’ command. With this capability, users who have access to an existing Anchore Enterprise deployment and prefer to use native ‘docker’ commands in their development environments can easily connect the two systems in a typically UNIX-like fashion. The following example shows an abstract ‘checkout, build container image, import image sbom to Anchore Enterprise’ using this new interface.

# git clone <somerepo>

# docker build -t <someimage> -f <somerepo>/Dockerfile <somerepo>/

# docker sbom --format syft-json <someimage> | anchorectl sbom upload -

With this simple process invoked either manually or scripted as part of an automated build, users can be assured that new container image SBOMs are being imported to their Anchore Enterprise deployment, so that the full capabilities of Anchore Enterprise – vulnerability scanning (on demand, historical), compliance checks using Anchore’s fully policy subsystem, SBOM drift detection, global reporting and notifications, and many others – can be applied.

Conclusion

As we continue to explore new areas for building SBOM generation and consumption capabilities in collaboration with the Docker community, we remain committed to ensuring that all of Anchore’s products, open-source tools and partnership collaboration efforts are interoperable. As we move forward, we’re looking forward to moving SBOM generation capabilities even closer to the ‘build’ process, continuing support for open standards atop the existing native, SPDX, CycloneDX and other formats, and providing integrations with a wide variety of development environments.

Anchore and Docker Release ‘docker sbom’ to Create Comprehensive SBOMs Based on Syft

Posted on by Dan Nurmi

Today Anchore and Docker released the first feature in what we anticipate will be an ongoing initiative to bring the value of the software bill of materials (SBOM) to all container-oriented build and publication systems. Now included in the latest Docker Desktop version is an operation called ‘docker sbom’ that is available via the ‘docker’ command. This new operation, which is built on top of Anchore’s open source Syft project, enables Docker users to quickly generate detailed SBOM documents against container images using the native Docker CLI.

SBOMs are quickly becoming foundational data sources for a variety of DevSecOps use cases ranging from basic software development hygiene all the way to unlocking more complex security and compliance capabilities such as tamper and drift detection, zero-day response support, and post-security-event forensic analysis. While security scanning tools need to identify software components, they often don’t make an SBOM accessible to users or include the level of detail needed to support a variety of use cases. With this open source collaboration between Anchore and Docker, we are giving users the ability to create and store an SBOM independently from running any higher-level function like vulnerability scanning or license detection.

By enabling SBOM creation to be an independent operation, it can be decoupled from the multitude of individual use cases that rely on SBOM data. This approach gives users the ability to generate an SBOM once and then use it for a variety of use cases. We believe that the availability of SBOM data is foundational when developing processes and technologies to improve software supply chain security. With ‘docker sbom’, we’re excited to engage with the Docker and Anchore communities together on the topic of SBOM creation, usage, and future directions.

How the ‘docker sbom’ command works

The new ‘docker sbom’ command is simple to use and leverages the power of Syft to provide rich content and data formats. In the following quick example, we show how the ‘docker sbom’ command can be used to generate a comprehensive SBOM document in a user-chosen format and then used as input for other tools that are capable of consuming an SBOM to provide higher-level functions such as vulnerability scanning.

As the discussion on the best way to create and consume SBOM data continues to evolve, we’re committed to supporting industry standard formats like SPDX, CycloneDX, Syft-JSON, and others in order to promote the idea of creating and storing SBOMs in forms that interoperate with evolving security and DevOps infrastructure tools.

Here, we show using the ‘docker sbom’ command against a test image that combines regular distro-provided packages (Alpine in this case) with multiple vulnerable versions of Log4j that are packaged in a variety of different forms ranging from simple top-level jars to many-levels-deep jars within compressed Java archives:

% docker sbom dnurmi/testrepo:jarjar

Syft v0.42.2

 ✔ Loaded image
 ✔ Parsed image
 ✔ Cataloged packages      [217 packages]

NAME                         VERSION                        TYPE

alpine-baselayout            3.2.0-r18                      apk
alpine-keys                  2.4-r1                         apk
…
…
log4j-core                   2.12.1                         java-archive
log4j-core                   2.11.0                         java-archive
log4j-core                   2.11.1                         java-archive
log4j-core                   2.13.2                         java-archive
log4j-core                   2.12.0                         java-archive
…

While the default output is in human-readable form for quick review, the command supports a growing set of output formats that can be used more directly for integration into other systems and tools that can analyze SBOMs:

% docker sbom --help


Usage:  docker sbom [OPTIONS] COMMAND

…
      --format string         report output format, options=[syft-json cyclonedx-xml cyclonedx-json github-json spdx-tag-value spdx-json table text]

                              (default "table")
…

To demonstrate this flow, let’s look at a simple use case where ‘docker sbom’ is used to produce its data as SPDX JSON, which is then consumed by another tool. We’ll use Grype, Anchore’s open source vulnerability scanner, to produce a vulnerability report without needing to contact any remote scanning services:

% docker sbom --format spdx-json docker.io/dnurmi/testrepo:jarjar | grype

Syft v0.42.2

 ✔ Loaded image
 ✔ Parsed image
 ✔ Cataloged packages      [217 packages]

NAME                 INSTALLED     FIXED-IN      VULNERABILITY        SEVERITY

…
log4j-core           2.12.1                      CVE-2021-45046       Critical
log4j-core           2.11.0                      CVE-2021-45105       Medium
log4j-core           2.13.2        2.16.0        GHSA-7rjr-3q55-vv33  Critical
log4j-core           2.12.1        2.12.4        GHSA-8489-44mv-ggj8  Medium
log4j-core           2.13.0                      CVE-2020-9488        Low
log4j-core           2.12.1        2.12.3        GHSA-p6xc-xr62-6r2g  High
log4j-core           2.12.0        2.12.3        GHSA-p6xc-xr62-6r2g  High
log4j-core           2.12.0                      CVE-2021-44832       Medium
…

What’s next for Anchore and Docker collaboration

The process above demonstrates a vulnerability scan as just one example use case where SBOMs can prove valuable. At Anchore, we’ve built our open source projects and our commercial Anchore Enterprise solution using SBOMs as the foundation for enabling best practices for software development, security, and compliance. We’re committed to continuing this work by making available both open source projects and commercial Anchore Enterprise products that are built to create, ingest, store, analyze, and output SBOM data across all stages in the development cycle.

With Docker, we’re looking forward to further collaboration to deliver deeper integration between Syft’s SBOM generating technology and the Docker build and store processes. We are working toward a near future where every container image stored in a registry has an associated SBOM that can be inspected and consumed for further processing. And beyond that, we’re looking to explore ideas that couple build directives with SBOM content to drive concepts like reproducible builds and build time security rule enforcement. We’re excited to continue the discussion and to have you join us in this effort!

How to Find and Fix Log4j with Open Source and Enterprise Tools from Anchore

Posted on by Dan Nurmi

Updated 01/07/22. As new information about the Log4j vulnerability becomes available, we will update this blog with the latest information.

As the Log4j zero-day vulnerability continues to have widespread effects across nearly every industry and sector, it’s becoming increasingly evident that there is still a long remediation road ahead. With new vulnerabilities associated with Log4j continuing to emerge, it is imperative to find and remediate this Log4j vulnerability across all your applications to ensure the security of your software supply chains.

This blog provides step-by-step instructions for finding and fixing the Log4Shell vulnerability found in Log4j using Anchore open source solutions (Syft and Grype) and commercial solution (Anchore Enterprise).

Summary of the Known Log4j Vulnerabilities

Log4Shell was originally published on Dec 10, 2021 as a zero-day vulnerability found in Apache Log4j 2, a widely used Java library. The vulnerability enables a remote attacker to take control of a device on the internet if the device is running certain versions of Log4j 2. After the original vulnerability was reported and fixed, there have been subsequent vulnerabilities identified which have resulted in new patched versions. We will update this table for any further Log4j vulnerabilities or versions

Vulnerability IDs Affected Package and Version  Patched Version  Date Published References
CVE-2021-44228,
GHSA-jfh8-c2jp-5v3q		 log4j-core 2.14 and earlier 2.15.0 (Java 8) 10 Dec 2021 NVD, GHSA
CVE-2021-45046,
GHSA-7rjr-3q55-vv33		 log4j-core 2.15 and earlier 2.16.0 (Java 8)
2.12.2 (Java 7)		 14 Dec 2021 NVD, GHSA
CVE-2021-45105,
GHSA-p6xc-xr62-6r2g		 log4j-core 2.16 and earlier 2.17.0 (Java 8)
2.12.3 (Java 7)
2.3.1 (Java 6)		 18 Dec 2021 NVD, GHSA
CVE-2021-44832,
GHSA-8489-44mv-ggj8		 Log4j-core 2.17.0 and earlier 2.17.1 (Java 8)
2.12.4 (Java 7)
2.3.2 (Java 6)		 28 Dec 2021 NVD, GHSA

Steps to Find Log4j Using Anchore Open Source Tools

Anchore provides two lightweight, command-line open source tools. Syft scans filesystems or container images to produce a comprehensive software bill of materials (SBOM). Grype identifies known vulnerabilities by scanning an SBOM generated by Syft or by scanning filesystems or container images directly.

In the context of Log4j, Syft-generated SBOMs enable you to find out if Log4j is present in a source code repository, a filesystem, or a container image. Grype can then be used to perform a vulnerability scan on that SBOM to determine if the detected versions of any given software package match any of the known Log4j vulnerabilities.

As the Log4j incident continues to evolve, both Syft and Grype are useful in identifying which Log4j versions you are running and determining the presence of any new Log4j vulnerabilities as they are announced.

The following examples provide step-by-step instructions for using Syft and Grype to locate and remediate Log4j.

Syft

Watch a video demonstration

Download Syft.

Example 1: Run syft to generate an SBOM and filter the results to identify any vulnerable versions of Log4j.

Command Example:

# syft dir://tmp/jarsinjars/ | grep log4j

Command Example:

# syft docker.io/dnurmi/testrepo:jarjar | grep log4j

Example 2: Run syft with the JSON output option to get more detailed information on the locations of the Log4j dependencies in your source code repositories and/or container images.

The example below shows the top-level ‘fireline.hpi’ package which contains a Log4j jar deeply embedded as shown by the ‘VirtualPath’ element of the JSON record.

Command Example:

# syft -o json docker.io/dnurmi/testrepo:jarjar

Example 3: Run syft and create a JSON file so you can save it as an SBOM artifact.

Command Example:

# syft -o json docker.io/dnurmi/testrepo:jarjar > log4j-sbom.json

Grype

Download Grype.

Example 4: Run grype on an SBOM produced by Syft and filter to find components that contain Log4j vulnerability IDs.

The example below filters for the ID GHSA-jfh8-c2jp-5v3q but you can also filter for any of the new CVEs affecting Log4j (see above for a list of vulnerability identifiers).

Command Example:

# grype docker.io/dnurmi/testrepo:jarjar | grep GHSA-jfh8-c2jp-5v3q

Steps to Find and Fix Log4j Using Anchore Enterprise

Watch a video demonstration.

Anchore Enterprise scans and performs a deep inspection of container images to identify the presence of Log4j and related vulnerabilities. However Anchore Enterprise also maintains a repository of SBOMs across applications and teams, so that users can query their entire SBOM catalog to search for any scanned images that include Log4j.

Anchore Enterprise users can leverage policy-based reporting and alert services to create automatic notifications when existing or new scans identify vulnerable versions of Log4j. The customizable policy engine can provide a “stop” signal your build systems and Anchore’s out-of-the-box policies also contain a rule blocking critical vulnerabilities such as those registered against Log4j from being deployed into production.

Using the Anchore Enterprise Runtime Inventory system, users can also quickly search for and detect instances of vulnerable Log4j software that is present in containers running in your Kubernetes deployments.

All Anchore Enterprise vulnerability detection features continuously update using the latest vulnerability data from a variety of public sources, and send notifications as the Log4j incident evolves, to keep teams abreast of newly discovered vulnerabilities and fix versions pertaining to Log4j software.

Instructions below are provided for the Anchore Enterprise command-line interface (CLI) and the user interface.

Scanning with Anchore CLI to Find Log4j

Watch a video demonstration. 
The Anchore CLI provides a command-line interface on top of the Anchore Enterprise REST API. The Anchore CLI is published as a Python package that can be installed from the Python PyPI package repository on any platform supporting PyPI. Anchore CLI users can manage and inspect images, policies, subscriptions, and registries.

Example 1: Run anchore-cli to scan container images, produce an SBOM, and use it to identify any vulnerable versions of Log4j, along with the location of any detected, installed Log4j packages.

Command Example:

# anchore-cli image content docker.io/dnurmi/testrep:jarjar java | grep log4j

Example 2: Run anchore-cli to search a specific container image for vulnerabilities matching vulnerability IDs.

The example below filters for CVE-2021-44228 but you can also filter for any of the new CVEs affecting Log4j (see above for a list of CVE identifiers).

Command Example:

# anchore-cli image vuln docker.io/dnurmi/testrepo:jarjar all | grep CVE-2021-44228

Example 3: Run

anchore-cli

to query all of the analyzed image SBOMs in your catalog for instances of vulnerable software matching particular vulnerability IDs.

The example below filters for ID GHSA-jfh8-c2jp-5v3q but you can also filter for any of the new CVEs affecting Log4j (see above for a list of CVE identifiers).

Command Example:

# anchore-cli query images-by-vulnerability --vulnerability-id GHSA-jfh8-c2jp-5v3q

Policy Enforcement and Reporting Using Anchore Enterprise

Example 1: In the Anchore Enterprise user interface navigate to View Reports -> Quick Report -> Images By Vulnerability to perform a query to retrieve all images with vulnerable software matching particular vulnerability IDs, such as CVE-2021-44228.

Example 2:  In Anchore Enterprise, navigate to Image Analysis > Select Image > Vulnerabilities Tab. Select View Images Affected on the left hand side of the screen. This will generate a report of all other images that share the specified CVE.

Example 3:  Ensure that the active policy has a rule that specifies a STOP action on any vulnerability marked with a severity level of Critical.

Finding Log4j in Running Containers Using Anchore Enterprise

Example 4: Use Anchore Enterprise’s Runtime Inventory to detect any container that is running in your Kubernetes cluster and includes a vulnerable version of Log4j. You will first need to install KAI (an agent that runs in your Kubernetes cluster) which can be downloaded here.

Once KAI is installed, select the Kubernetes tab in Anchore Enterprise and select Vulnerabilities.

Next query for the known vulnerability identifiers for Log4j such as CVE-2021-44228 or others listed above.

Any currently running images with the Log4j vulnerability will populate in the table below when you execute the query. From there, you can drill down on any impacted image, by selecting the Vulnerabilities tab within the impacted runtime image, and View Images Affected to identify other images that share the Log4j vulnerability.

Remediation Workflows Using Anchore Enterprise

Example: If Log4j is detected in any of your applications, you must begin the fix process. Anchore Enterprise users can trigger notifications and remediation workflows based on rules set through the policy engine. Tickets can be automatically created in Jira or GitHub, sent as emails, or posted to Slack or Microsoft Teams channels. These notifications provide not only the details of the Log4j version discovered or the policy rules that were violated but also include explicit instructions on what versions should be used to resolve the issue.

Contact Us

Anchore is continuing to monitor the Log4j incident as it evolves. If you need assistance or want to learn more about how Anchore can help, please contact us.