Security Alert: 5 Ways to Limit Your Exposure to the New Critical OpenSSL Vulnerability

github icon
tag icon
star icon
fork icon

PBOM vs SBOM: A New Security Standard

What is an SBOM?

The traditional concept of Software Bill of Materials (SBOM) is familiar to development stakeholders just as a Bill of Materials (BOM) is familiar to any manufacturer.

For decades, manufacturers have been using a BOM to document complex manufactured goods down to their smallest components. This allows them to track the origin and status of each component in any given product. As a result, an engine manufacturer knows exactly which engines of the hundreds of thousands produced contain a flawed part. And which cars need to be recalled to rectify that flaw.

Similarly, developers use an SBOM to list the name, version, license, and any vulnerabilities of their open-source components, as well as the components in those components used to develop and build a piece of software. The SBOM is important for quality control and crucial for software supply chain security.

Software supply chain security is top of mind

Software supply chain security, like cybersecurity as a whole, is top of mind for most DevOps teams. Gartner predicts that by 2025, 45% of organizations worldwide will have experienced attacks on their software supply chains. And these attacks are increasingly sophisticated and difficult to detect. In order to counter this threat, software suppliers need to understand exactly what’s included in their code. They need to be able to identify the source of a vulnerability F-A-S-T in order to remediate it before the entire supply chain is threatened.

SBOMs are not enough

The problem is, an SBOM doesn’t actually cover the entire software supply chain. SBOMs are only static lists of mapped open-source software dependencies. These lists simply do not go far enough to provide the end-to-end security and integrity a dev pipeline needs. SBOMs only scan part of the software supply chain. As a result, despite the best efforts of SBOM providers, today’s software supply chains remain a black box. And the most pressing challenge in software supply chain security is how to turn that black box into a source of security and business intelligence.

That’s why we created PBOM (Pipeline Bill of Materials) standard.

What is a PBOM?

Ox Security’s PBOM standard provides a real-time list of software lineage, from the first line of code all the way to release while identifying and preventing threats along the way. PBOM ensures the integrity of every build, verifies that all apps in production are secure, and minimizes the attack surface.

More than just an SBOM-like inventory of components in your production apps, a PBOM is a dynamic list of everything a piece of software has gone through. It starts with the first line of code and continues all the way through to release, identifying any vulnerabilities along the way.

Light-years beyond an SBOM, a PBOM is a signed ledger of each pipeline build. A PBOM tracks the entire software life cycle, including all version lineage, SLSA.dev, SaasBOM, security tool results, build hashes, and more.

What can PBOM do for me?

PBOM maximizes software supply chain security and integrity with an automated process that covers all software, from the first line of code, delivering:

  • Complete pipeline security – PBOM standard automatically tracks all pipeline branches, builds, pull requests, tickets, known issues, and vulnerability management. This enables full visibility into your organization’s security posture.
  • Comprehensive integrity – PBOM ensures that software is built from the correct sources and dependencies and hasn’t been modified during the build process. It verifies no “bad” code is submitted without alert and review. It also verifies no malicious code is pushed via a compromised pipeline.
  • Full traceability – PBOM continuously monitors every pipeline change – from proper documentation of changes to tracing each of your software releases.

PBOM enables dev stakeholders to verify that each version or artifact provided to external customers has been checked properly and that the release is “worthy”. It empowers dev teams to compare artifacts in production to the PBOM ledger to ensure tractability on each release. And it helps dev teams gain visibility into each pipeline in the internal build environment – marking each artifact with a proper security tag.

The Bottom Line

The software industry’s long reliance on SBOMs has left large parts of the software supply chain attack surface in the dark. Now, PBOM offers a new standard for software supply chain security. It provides DevOps teams with full visibility over the software supply chain attack surface. This includes source code, pipeline, artifacts, container images, runtime assets, and applications. It also continuously monitors security changes in the environment. This ensures that the software supply chain does not drift from its original secure state. What’s more, PBOM delivers clear and actionable remediation strategies. This includes a list of prioritized risks and recommendations based on context and company business objectives.

And in a development ecosystem that demands both speed and security, PBOM minimizes the attack surface without impeding developer agility. This prevents software supply chain attacks without slowing down development.

For more information on how PBOMs can help streamline your software supply chain security, contact sales@ox.security today.

Like it? Let’s share!
Subscribe for updates
Related content