Software supply chain security: How to audit a security bill of material (SBOM)

January 12, 2023

Engineering

A security bill of material (SBOM) is an inventory of the entire building components of a software application. These components include open source libraries, dependencies, commercial components, licenses, patch status, version information, upgrades available, CVEs, etc. Having an SBOM of a codebase or piece of software provides deep visibility into core components that help quickly identify and mitigate the security and licensing risks associated with the software supply chain.

This article will discuss the SBOM, why it is key for supply chain security, how to audit it for software security, and a few recommendations for tools to check out.

Minimum Elements for SBOM

Recently, the National Telecommunications and Information Administration released a standard indicating the minimum elements of SBOM. These minimum elements set up a baseline for SBOM functionality and comprise three broad, interrelated areas.

  • Data Fields: The Data field contains baseline information about each relevant component that is required to be tracked, identified, maintained, and mapped to vulnerability or license databases. This baseline component information includes: Supplier Name, Component Name & Version, Other Unique Identifiers, Dependency Relationship, Author, and Timestamp of SBOM data assembly.
  • Automation Support: Automation is recommended to generate SBOM Data in an acceptable machine-readable format so that it can be transferred, consumed, and scaled across the software ecosystem. The Data formats used to generate and consume SBOMs include SPDX, CycloneDX, and SWID tags.
  • Practices and Processes: To integrate SBOM into secure SDLC, an organization should follow certain practices and processes that focus on the mechanics of request generation and usage. Minimum elements that should be included are: Frequency, Depth, Known Unknowns, Distribution and Delivery, Access Control, and Accommodation of Mistakes.

Data Formats of SBOM

Software Package Data eXchange (SPDX) by Linux Foundation and OWASP Cyclone DX are widely used standard data formats for communicating the component and metadata information associated with software packages.

Software Package Data eXchange

An SPDX document can be associated with a set of software packages, files, or snippets and contains information about the software in the SPDX format. The SPDX Document contains Information about Creation, Package, File, Snippet, Licensing, Annotations, SPDX Elements Relations, and Review. It supports multiple serialization formats like JSON, Yaml, XML, RDF, XLS, and tag: value. An example SPDX in the tag: value format looks like below.

Software Package Data eXchange

OWASP CycloneDX

OWASP CycloneDX is a lightweight SBOM standard designed for use in application security contexts and supply chain component analysis. It provides standards in XML, JSON, and Protocol Buffers. The object model can easily describe complex relationships and consists of metadata, components, services, dependencies, compositions, and vulnerabilities.

Generating SBOM

An SBOM can be generated during the software development and as a part of deployment pipelines for asset inventory management purposes. It is better to build SBOM at a CI/CD stage to perform analysis and ensure supply chain security. Some of the open source tools to generate SBOM include Syft, Tern, Kubernetes BOM tool, Microsoft/sbom-tool, snyk2spdx, and spdx-sbom-generator.

Generating SBOM using Syft

Syft by Anchore can be used to generate in SBOM in multiple data formats including syft-json, cyclonedx-xml, cyclonedx-json, github, spdx-tag-values, table, etc.

$ docker run -it --rm anchore/syft ubuntu:18.10 --scope all-layers --output <table,spdx-tag-values>

Generating SBOM using Tern

Tern can be easily installed using Python pip. scancode-toolkit is a license analysis tool that “detects licenses, copyrights, package manifests and direct dependencies and more both in source code and binary files.”

Installation

$ sudo apt-get install python3-pip python3-dev
$ pip3 install tern scancode-toolkit

Running Tern with scancode

$ tern report -f spdxtagvalue -x scancode -i golang:latest -o spdx.txt
generating SBOM using Tern

Auditing SBOM for Vulnerabilities and Risks

The output SBOM generated contains information about dependencies and licenses in a format of choice. This information can now be mapped with the vulnerability and license databases to get the vulnerabilities and license risks.

Grype

Grype by Anchore is a vulnerability scanner for container images and filesystems. It can be used to scan directories, docker images, files, SBOM, or running containers. It works well with syft to generate and audit the SBOM.

Installation

$ curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin

Scanning Images

The command scans for vulnerabilities that are visible in the container. The –scope is used to include software from all image layers in the vulnerability scan, regardless of its presence in the final image.

$ grype scan ubuntu:latest
$ grype ubuntu:latest --scope all-layers

Scanning Running Containers

We can run grype from a docker container and can scan containers in the same runtime.

docker run --rm --volume /var/run/docker.sock:/var/run/docker.sock \
--name Grype anchore/grype:latest $(ImageName):$(ImageTag)

Scanning SBOMs

Grype supports input of Syft, SPDX, and CycloneDX SBOM formats and runs faster with these input sources. Grype also includes CPEs information in the report.

$ cat ./sbom.json | grype
$ grype --add-cpes-if-none --distro alpine:3.10 sbom:ubuntu-latest.spdx.json

Grype has a built-in vulnerability database and is powered by sources like SecDB, ALAS, OVAL, NVD, GHSAs, etc.

SBOM Audit at CI/CD

Grype and Syft can be easily integrated at CI/CD. Anchore has a GitHub Action available for SBOM generation (sbom-action) and Scanning (scan-action). sbom-action uses syft to generate SBOM. The default path is the workspace directory and the default format is SPDX.

# Generate sbom for Image
uses: anchore/sbom-action@v0
with:
    image: my-registry.com/my/image
    registry-username: mr_awesome
    registry-password: ${{ secrets.REGISTRY_PASSWORD }}

# Generate sbom for File 
- uses: anchore/sbom-action@v0
  with:
    file: ./build/file

# Generate sbom for Directory
- uses: anchore/sbom-action@v0
  with:
    path: ./build/

scan-action is a GitHub Action that uses Grype scanner and returns the vulnerabilities found.

# SBOM Scanning 
- name: Create SBOM
  uses: anchore/sbom-action@v0
  with:
    format: spdx-json
    output-file: "${{ github.event.repository.name }}-sbom.spdx.json"

- name: Scan SBOM
  uses: anchore/scan-action@v3
  with:
    sbom: "${{ github.event.repository.name }}-sbom.spdx.json"

# Container Scanning
- name: Set up Docker Buildx
  uses: docker/setup-buildx-action@v1

- name: Scan image
  uses: anchore/scan-action@v3
  with:
    image: "localbuild/testimage:latest"
    
# Directory Scanning
- name: Scan current project
  uses: anchore/scan-action@v3
  with:
    path: "."

Failing a buildScan-Action will fail a build if any vulnerability is medium or higher. Severity-cutoff can be configured to low, high, medium, or critical.

- name: Scan image
  uses: anchore/scan-action@v3
  with:
    image: "localbuild/testimage:latest"
    fail-build: true
    severity-cutoff: critical

KubeClarity for Kubernetes SBOM

KubeClarity is a full-fledged open-source tool to manage SBOM and vulnerabilities of containers and filesystems. It scans both runtime K8s clusters and CI/CD pipelines for enhanced software supply chain security. Effective vulnerability scanning requires an accurate Software Bill Of Materials (SBOM) detection. KubeClarity caters to SBOM Audit challenges by providing multiple scanners, vulnerability databases, input sources support, remediation, and beautiful dashboards. Kubeclarity also supports importing SBOM and vulnerability scan reports.

Installation

First, add the Helm repo:

$ helm repo add kubeclarity https://openclarity.github.io/kubeclarity

Next, deploy KubeClarity with Helm’s default values:

$ helm install --values values.yaml --create-namespace kubeclarity kubeclarity/kubeclarity -n kubeclarity

Finally, forward a port from localhost:9999 to the KubeClarity UI:

$ kubectl port-forward -n kubeclarity svc/kubeclarity-kubeclarity 9999:8080
KubeClarity for Kubernetes SBOM

SBOM generation and scanning

Kubeclarity-cli can be used at various stages of CI/CD pipelines. For example:

ANALYZER_LIST="syft" kubeclarity-cli analyze ubuntu:latest -o ubuntu.sbom

The above command could also be used to scan instead:

SCANNERS_LIST="grype" kubeclarity-cli scan ubuntu.sbom --input-type sbom

Recommendations for software supply chain security

In recent years, there has been a significant rise in software supply chain attacks. After the Log4j vulnerability, organizations have a heightened sense of awareness toward supply chain security. These are the few recommendations to be taken care of while implementing your supply chain security program.

Generating and Updating SBOM

Keep an updated list of applications, software components, packages, libraries, and licenses. We can use tools like syft and Kubeclarity to manage SBOM at scale.

Auditing and Scanning SBOM

Always scan the SBOM to get the vulnerabilities and license risks. Grype is one of the most recommended tool to get it done quickly. Regularly blacklist components Blacklists allow companies to avoid components with known issues, orphaned projects, or that have had a history of having many issues whether they be security, performance, or reliability issues.

Monitoring components for vulnerabilities

An SBOM-equipped producer can more easily monitor components for vulnerabilities so the team can more proactively evaluate and remediate risks.

SBOM into your DevSecOps

Always block the deployment flow if there exists a vulnerability with a severity level above the tolerant level. Integrate SBOM generation and scan at CI/CD.

Conclusion

SBOM is very useful in managing the risk of vulnerabilities. Organizations like Google are also working on tools like GUAC to cater to software supply chain security needs. There are many tools available that can help you improve your supply chain and software composition analysis.

Read more about:

security

Raushan is a Lead Engineer at an AgriTech company. He has 8 years of experience in Information Security, Compliance, and Sofware Development. He's also an open source enthusiast and contributes to OWASP OSSAP. In his free time, he likes to work with GoogleVRP.

Read More Engineering Articles