SBOM as a Core Element in Sysdig’s CNAPP Strategy for Enhanced Security

By Joseph Yostos - FEBRUARY 8, 2024

SHARE:

Facebook logo LinkedIn logo X (formerly Twitter) logo

In the fast-paced world of application development, the use of open source components offers a quick path to building sophisticated applications. However, this approach introduces critical questions about software composition, licensing, and security.

Before pushing any new application to production or even staging, the security and compliance teams alongside the application owner must address the following:

  • The specific components within their software.
  • The open source libraries in use.
  • Internal dependencies of the application.
  • Scanning for vulnerabilities, including in third-party libraries.

This is where the importance of a Software Bill of Materials (SBOM) becomes clear. An SBOM is not just a standardized list of the image components; it’s a necessity for ensuring that cloud-native applications are secure, compliant, and trustworthy.

Gartner has listed SBOM as one of the core components of Cloud-Native Application Protection Platform (CNAPP) in its latest CNAPP market guide.

In this blog, we will discuss how Sysdig uses the SBOM as a core component for vulnerability management workflow to understand image (container and Host) contents, and making this content available to extract for Compliance and Regulatory audits.

The Evolution of VM Scanning with SBOM Extraction

The concept of SBOM is not new; the open source community recognized the need for creating SBOMs over a decade ago. The Software Package Data Exchange (SPDX) open standard, initiated in 2010, marked an early effort to tackle this issue.

Prior to the adoption of SBOMs, there was a notable gap in understanding code dependencies, which represented a significant challenge for application security teams. Integrating SBOMs into vulnerability management tools has revolutionized this process, allowing for comprehensive scans of both the application and its dependencies, including third-party libraries and frameworks.

Beyond enhancing security, SBOMs offer additional advantages such as significantly reducing the resources required for vulnerability management. 

For a deeper dive into the fundamentals of SBOMs, consider exploring further in the “SBOM 101” article.

Incorporating SBOM into Sysdig’s Vulnerability Management Process

All Sysdig Vulnerability Management Scanning options, both agent-based (CLI Scanner, Cluster, Host, and Registry) and agentless, now include the capability to extract the SBOM from the scanned source or image repository. The SBOM is then sent to the backend with other context and profiling data to accomplish the Vulnerability Detection process. 

All images are extracted into an SBOM format that is compatible with the CycloneDX standard.


BlogImages-Integrating SBOM as Core Element diagram

After the initial scan, when the SBOM is extracted and stored in the SBOM Database, each subsequent scan request prompts the scan engine to retrieve the current SBOM via API. It then scans all listed components within this SBOM before sending the scan results back.

This workflow offers multiple benefits:

  • Resource efficiency: 
    • Significantly reduces the resources used on the customer’s side since vulnerability matching, policy evaluations, and other processes are conducted on the Sysdig backend, minimizing the load on client systems.
    • Once the SBOM is stored, if another image is found with the same SBOM, extraction and downloading of the SBOM will not be needed which saves time and resources.
  • Simplified client logic: A lot of business logic is removed from client components like the vuln matching part, reducing the need to update the client components on the customer side. This also means that client components will already use the most updated logic for vuln matching, policies, risk acceptance, and risk spotlight without needing to update the client component.

Expanding Export Capabilities: Streamlining Compliance Through SBOM API Integration

Sysdig has recently introduced the capability to export SBOMs directly from the Sysdig SBOM Database via an API, utilizing the widely recognized CycloneDX format. This advancement is particularly crucial for meeting compliance requirements and facilitating regulatory audits.

CycloneDX is a standardized format that has been adopted by various repositories and platforms for the seamless exchange and integration of SBOM data. By enabling SBOMs to be exported in this format, Sysdig significantly eases the integration with other supply chain security tools, thereby enhancing collaboration and compliance across the board.

To extract an SBOM for a specific image, you can use the following simple API query:

curl --request GET \

 --url 'https://secure.sysdig.com/secure/vulnerability/v1beta1/sboms?assetId=sha256:c276a3cc04187ca2e291256688a44a9b5db207762d14f21091b470f9c53794e2&assetType=container-image' | jqCode language: Perl (perl)

In this query:

  • assetId’ refers to the unique identifier of the asset for which the SBOM is being retrieved.
  • assetType’ specifies the type of asset, which can be either “container-image” or “host.”
  • bomIdentifier’ is used to specify the ID of a single SBOM.

When querying an SBOM via the API, you have the option to provide either the ‘bomIdentifier’ alone or both ‘assetId’ and ‘assetType’ to retrieve the desired SBOM.

SBOM Details and Layer Analysis

Within every extracted SBOM, several distinct layers and types of components are identified, each contributing to the overall structure and functionality of the software. Here’s a breakdown of the layers and components you may find in an SBOM:

Operating system layer:

The SBOM specifies an “operating-system” component, which in the following example is Debian version “12.2.” This forms the foundational layer of the software, indicating the base environment on which other components are built and interact.

{

      "bom-ref": "1c32decb-cdcf-43a8-b0f5-ad78f376ff9e",

      "type": "operating-system",

      "name": "debian",

      "version": "12.2"

    },Code language: Perl (perl)

   Library components:

Each library represents a different software package included in the system. These libraries include essential tools and utilities that the application relies on. Each library is detailed with its specific version and package URL (purl), providing a clear picture of the software dependencies.

{

      "bom-ref": "209522c2-79e8-48ec-a95f-ca1ec69243cf",

      "type": "library",

      "name": "adduser",

      "version": "3.134",

      "purl": "pkg:deb/debian/[email protected]?distro=debian-12.2&upstream=adduser&upstream-version=3.134",

    },Code language: Perl (perl)

   Layer information at package level:

The SBOM provides detailed layer information for each package. Properties such as “sysdig:layer:digest” and “sysdig:layer:index” are included for each component, indicating the unique identifier (digest) of the layer in which the component resides and its position (index) within the layer stack. This information is crucial for understanding how the application is constructed and for pinpointing where in the build process each component is introduced.

"properties": [

        {

          "name": "sysdig:layer:digest",

          "value": "sha256:cb4596cc145400fb1f2aa56d41516b39a366ecdee7bf3f9191116444aacd8c90"

        },

        {

          "name": "sysdig:layer:index",

          "value": "0"

        },Code language: Perl (perl)

   Installation paths:

Each component’s entry in the SBOM includes an “installPath,” showing where the package is located within the system. For example, the “installPath” for many listed components is “var/lib/dpkg/status,” which is a common location for package metadata in Debian-based systems. This detail helps in identifying where the software components are stored and how they are organized within the file system.

{

 "name": "sysdig:package:installPath",

 "value": "var/lib/dpkg/status"

}Code language: JSON / JSON with Comments (json)

Conclusion

In conclusion, Sysdig’s integration of SBOMs into its CNAPP strategy represents a significant leap in securing cloud-native applications. By adopting the CycloneDX standard for SBOMs, Sysdig not only enhances vulnerability management but also streamlines compliance processes. The ability to export SBOMs directly enhances collaboration and ensures a transparent, secure software supply chain. This strategic move underscores Sysdig’s commitment to advancing cloud-native security in an ever-evolving digital landscape.

Subscribe and get the latest updates