Concepts

• 1: Software Bill of Materials
• 1.1: SBOM Output Format
• 2: Vulnerability Scanning
• 3: Plugins

1 - Software Bill of Materials

A software bill of materials (SBOM) is a list of all the components, libraries, and other dependencies that make up a software application, along with information about the versions, licenses, and vulnerabilities associated with each component. They are formal, structured documents detailing the components of a software product and its supply chain relationships.

SBOMs are important because organizations increasingly rely on open source and third-party software components to build and maintain their applications. These components can introduce security vulnerabilities and must be adequately managed and updated. SBOMs help you understand what open source and third-party components are used in your applications, and identify and address any security vulnerabilities.

Under specific scenarios, generating and publishing SBOMs is mandatory for compliance with regulations and industry standards that require organizations to disclose the use of open source and third-party software in their products.

SBOM Standards

There are several related standards, for example, CycloneDX, SPDX, SWID.

SPDX (Software Package Data Exchange) is a standard format for communicating a software package’s components, licenses, and copyrights. It is commonly used to document the open source components included in a proprietary software product. SPDX files can be easily read and understood by humans and machines, making it easy to track and manage open source components in a software project. SPDX format is supported by Linux Foundation.

CycloneDX is an open source standard for creating software bill of materials files. It is like SPDX in that it documents the components and licenses associated with a software package, but it is specifically designed for use in software supply chain security. CycloneDX is a more lightweight format compared to SPDX, which is intended to be more detailed. CycloneDX format is supported by OWASP.

SBOM Architecture

A typical SBOM architecture can be laid out as a tree-like dependency graph with the following key elements:

• Component inventory: Information about the components, libraries, and other assets used in the software, including version numbers, licenses, and vulnerabilities.
• Dependency mapping: A map of relationships between different components and libraries, showing how they depend on each other and how changes to one may impact the other.
• License management: It should also include information about the licenses of the components and libraries used to ensure that the software complies with legal and ethical obligations.

SBOM Generators

There are two typical ways to generate SBOM: during the build process, or after the build and deployment using a Software Composition Analysis tool. Trivy and Syft are two noteworthy open source generators among many other generators, including open source and commercial. Both use CycloneDX format. It is also important to note that not all SBOMs can be generated equally. Each generator may pick up a few language libraries better than the others based on its implementation. It might take multiple runs through a few different types of generators to draw comprehensive insights.

OpenClarity content analyzer integrates with the following SBOM generators:

• Syft
• Cyclonedx-gomod
• Trivy

Multiple SBOMs for Accuracy

OpenClarity can run multiple SBOM generators in parallel, and unify their results to generate a more accurate document.

In such cases, OpenClarity compiles a merged SBOM from multiple open source analyzers, and delivers a comprehensive SBOM document report. Although OpenClarity does not generate SBOMs, it integrates with popular generators so that a combined document can provide amplified inputs that can be further analyzed using vulnerability scanners. Leveraging multiple SBOM documents can improve visibility into software dependency posture.

OpenClarity formats the merged SBOM to comply with the input requirements of vulnerability scanners before starting vulnerability scans.

Note: OpenClarity can merge vulnerability scans from various sources like Grype and Trivy to generate a robust vulnerability scan report.

Scan SBOM Documents for Vulnerabilities

You can feed the generated SBOM documents to vulnerability scanners, which analyze the SBOMs and generate a vulnerability report detailing all known and fixed CVEs of the software components listed by SBOM.

1.1 - SBOM Output Format

The openclarity-cli scan command can format the resulting SBOM into different formats to integrate with another system. The supported formats are:

To configure the openclarity-cli to use a format other than the default, the sbom.output_format config parameter can be used with the configuration name from above:

# Create config based on https://github.com/openclarity/openclarity/blob/main/.families.yaml
cat <<EOF > config.yml
sbom:
  enabled: true
  analyzers_list:
    - "syft"
  inputs:
    - input: "/dir-to-scan"
      input_type: "rootfs"
  output_format: "cyclonedx-json"
EOF

# Run scan
openclarity-cli scan --config config.yml

For more information the CLI configuration, see the Example CLI Configuration.

2 - Vulnerability Scanning

Vulnerability scanning identifies weak spots in software code and dependencies. Vulnerability scanners can identify infrastructure, networks, applications, or website vulnerabilities. These tools scan various target systems for security flaws that attackers could exploit.

The scanners use the information contained in the SBOM to identify vulnerabilities and potential security risks within software applications. Vulnerability scanners use SBOM information to:

• Identify vulnerable components: Scanners use the SBOM to identify a software application’s components, then cross-reference this information with known vulnerabilities and security issues to identify vulnerable components within the software.
• Prioritize vulnerabilities: After the vulnerability scanner has identified all vulnerable components within the software application, it uses the SBOM to prioritize the vulnerabilities so you can focus on the most critical vulnerabilities.
• Identify supply chain risks: SBOMs provide visibility into the software supply chain, enabling vulnerability scanners to identify third-party or security risks. As a result, organizations can mitigate supply chain risks and reduce their overall security exposure.
• Track changes and updates: Software vulnerability scanners use SBOM information to determine whether software changes have introduced new vulnerabilities or security risks.

The SBOM is a critical tool for vulnerability scanners, providing the information needed to identify, prioritize, and mitigate security risks within software applications. In addition, scanners also rely on other types of inputs, as listed below.

OpenClarity and Vulnerability Scanning

OpenClarity isn’t a vulnerability scanner but integrates with top opensource vulnerability scanners. It also helps with prioritization and risk management by visualization and filtering. It is often necessary to prioritize CVEs because of the sheer volume of identified CVEs. With OpenClarity’s vulnerability trending dashboard and APIs, you can locate and double-click into a specific CVE in your application or infrastructure.

OpenClarity features a range of flexible and dynamic filters that help map CVEs down to an application->package->Image level. Additionally, it normalizes reports from multiple scanners and calculates missing CVSS (Common Vulnerability Scoring System) scores.

OpenClarity vulnerability scanner integrates with the following scanners:

• Grype
• Dependency-Track
• Trivy

OpenClarity supports both automatic scans to find common vulnerabilities quickly and efficiently, and manual scans to help verify automated scans, and also to help identify more complex and less common vulnerabilities. In addition to conventional scans, OpenClarity also provides multi-scanner integration.

Multi-scanner Architecture

OpenClarity infrastructure enables multiple scanners’ configuration and simultaneous operation. Scanners in OpenClarity are designed to work in parallel.

The following figure shows the multi-scanner architecture for vulnerability scanning: OpenClarity preprocesses the SBOMs so they conform to the specific formatting requirements of the specific scanner. Each scanner may have different types and unique formatting expectations. The scanners analyze the incoming data and generate vulnerability outputs in their native formats.

OpenClarity can merge the vulnerability reports of different scanners, to include severity levels, sources, and available fixes. These reports serve as valuable outputs, allowing you to filter and focus on specific areas of vulnerabilities for further investigation and resolution.

Run Vulnerability Scans

For details on running vulnerability scans with OpenClarity, see the Getting Started.

3 - Plugins

Plugins provide additional scanning capabilities to OpenClarity ecosystem. Project structure:

• runner - Provides necessary logic to manage scanner plugins in OpenClarity.
• sdk - Language-specific libraries, templates, and examples to aid with the implementation of scanner plugins.
• store - Collection of available plugins that can be directly used in OpenClarity.

Requirements

Scanner plugins are distributed as containers and require Docker Engine on the host that runs the actual scanning via OpenClarity CLI to work.

Support

List of supported environments:

1. AWS
2. GCP
3. Azure
4. Docker

List of unsupported environments:

• Kubernetes - We plan on adding plugin support to Kubernetes once we have dealt with all the security considerations.

Note: Plugin support has been tested against OpenClarity installation artifacts for the given environments.

Usage

You can start using plugins via Plugins Store. For example, you can pass the .families.yaml scan config file defined below to the OpenClarity CLI scan command. This configuration uses KICS scanner to scan /tmp dir for IaC security misconfigurations.

# --- .families.yaml
plugins:
  enabled: true
  scanners_list:
    - "kics"
  inputs: 
    - input: "/tmp"
      input_type: "rootfs"
  scanners_config:
    kics:
      image_name: "ghcr.io/openclarity/openclarity-plugin-kics:latest"
      config: "{}"

SDKs

You can use one of available SDKs in your language of choice to quickly develop scanner plugins for OpenClarity.

List of supported languages:

• Golang
• Python