The eXtended Software Bill of Materials (XBOM): A Game Changer for Application and Supply Chain Security

Since the Executive Order on Improving the Nation’s Cybersecurity was released two years ago, SBOMs have become synonymous with mapping your application attack surface to understand risk.

Unfortunately, traditional SBOMs provide little more than ticking a compliance check box.

First, most only provide a list of open source dependencies, which is just a sliver of technologies used to assemble modern applications. Other BOMs like IBOM (infrastructure bill of materials) and PBOM (pipeline bill of materials) have cropped up to provide visibility and attestation for different frameworks. Second, modern applications and software supply chains create interconnected attack surfaces and require a new approach for risk visibility, prioritization, and remediation.

Apiiro was built to provide that kind of coverage and context from the very start, and we want to encourage every organization to expect the same. We’re excited to officially align to eXtended Software Bill of Materials (XBOM) as our approach to provide a unified inventory across all the various components, controls, data, tools, and processes that modern applications and supply chains are made up of, their connections and associated risks, and how they change over time.

Understanding XBOM: The Next Level of SBOM

While traditional SBOMs provide visibility into a subset of software components like OSS dependencies, they barely scratch the surface of many technologies used to assemble modern applications. Community projects such as CycloneDX and SLSA recognize these gaps, and even the previously referenced executive order includes mention of both internal and third-party software components, going above and beyond what the market has generally accepted as SBOM:

“(vi) maintaining accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes, and performing audits and enforcement of these controls on a recurring basis;”

XBOM expands upon traditional Software Bill of Materials (SBOMs) by providing a vastly greater breadth of components covered and depth of insights across those components.

Breadth of XBOM Components

Unlike most SBOMs that only provide an inventory of your open source dependencies, an XBOM provides a graph-based inventory of every single application component and their relationships across the development lifecycles and the systems used to deliver software, including all of the following technologies and frameworks:

Application Components

• Entry Points:
  • APIs
  • Serverless
  • Protobuf Services
• Open Source
  • Dependencies
  • Licenses
• Confidential Information
  • Secrets
  • Sensitive data (PII, PCI, PHI)
• Data Management
  • Data Models
  • Data Access Objects
  • Protobuf Messages
  • GraphQL Objects
• Code Structure
  • Repositories
  • Code Modules
  • Technologies
• Kubernetes
  • Services
  • Deployments
• Infrastructure
  • Terraform
  • Dockerfile

Application Risk Types

• • OSS security risk assessment and SCA findings
  • SAST findings
  • Weaknesses in entry points
  • Exposed secrets in code
  • License compliance issues
  • Data model flaws
  • SCA and CI/CD Access control weaknesses
  • Infrastructure misconfigurations
  • Design flaws
  • Weak branch protection rules
  • Risky material changes
  • Missing security tool coverage
  • And more

Depth of XBOM Insights

To get true visibility across your application and software supply chain attack surface, you need to understand the context in which each component exists. XBOM goes beyond basic metadata, adding context and risk insights on top of each and every identified component, including:

• Metadata and insights such as code owner and provenance which are useful for tracking and validating the origin of components and risks.
• Connections between components (e.g., APIs, dependencies, data models, etc.) such as parent-child or sibling relationships and associated risks based on those relationships (i.e., toxic combinations or siloed components and risks) to help organizations understand the potential impact of a vulnerability.
• Runtime context of code components that have been deployed to determine internet exposure and potential impact of a risk.
• Material changes and how risks were identified and reported—whether from an SCA or SAST tool or a more manual process such as a penetration test.

Benefits of Adopting XBOM

The eXtended Software Bill of Materials (XBOM) approach takes traditional SBOM to new heights. It is the answer for organizations looking to better understand and assess risk within their complex, modern application attack surfaces.

By providing a complete view of all application components and their relationships across code, data, artifacts, CI/CD, and runtime environments, XBOMs are exponentially more comprehensive than SBOMs. XBOMs also provide real-time visibility and provide deeper context on the provenance and code owners of components, empowering organizations to make more informed decisions about patching, updating, and securing their applications and software supply chain faster.

Embracing XBOM is a significant step towards strengthening your application security posture and ensuring the safe and reliable operation of your software-dependent systems in our increasingly interconnected world.

What’s Next?

Apiiro’s graph-based, real-time XBOM allows you to understand your application architecture and attack surface and assess risk accurately and effectively. And with our recent product addition, the Apiiro Risk Graph™ Explorer, you can also query anything about your application and software supply chain components, their connections and risks, and essential insights and traits and export those findings.

To learn more about what to expect from XBOM, download our complete XBOM Checklist or schedule an Apiiro demo to see XBOM in action.