github icon
tag icon
star icon
fork icon

The Anatomy of a PBOM

What does a PBOM consist of, exactly?

As we discussed in a previous post, Ox Security’s patented PBOM (Pipeline Bill of Materials) technology provides a real-time list of software lineage, from the first line of code all the way to release. This helps DevOps/DevSecOps ensure the integrity of every build, verify that all apps in production are secure, and essentially eliminates the attack surface.

But what does a PBOM consist of, exactly? In this post, we’ll take a deep dive into the anatomy of a PBOM, and how each element impacts your overall security mix.

PBOM – Covering the Entire Software Lifecycle

Although it shares similar nomenclature, a PBOM offers a depth of knowledge far beyond the scope of an SBOM.

A PBOM is a dynamically-updated list of everything ever done to a given piece of software – from the first line of code and to release. It’s a signed ledger of each pipeline build – tracking the complete software lifecycle, version lineage,, SaasBOM, security history, build hashes, and more. This enables dev teams to drill down into the entire build flow, including:

  • Repository
  • CI/CD
  • Artifacts
  • Cloud Deployment

Drill Down: Anatomy of a PBOM

What does a PBOM look like, under the hood? Once generated on your software, the PBOM dashboard will show you:

  • CI/CD Integrity – A PBOM scans and displays all software artifacts, binaries, packages, files, containers, and components – locally, in the cloud, or in your ready-to-run artifact (where compiled artifacts are stored before upload to the cloud). This helps DevOps ensure that each component actually came from the CI/CD build pipeline, and wasn’t inserted by someone else (which is what happened in the SolarWinds, Codecov and other attacks involving injected artifacts).
  • Open Source Security – Vulnerabilities in open source subcomponents, which frequently result from unknowingly using outdated versions, can result in serious security issues. In fact, the infamous Equifax breach was the result of exactly this issue. A PBOM reveals dependencies in open source components and ensures there are no vulnerabilities in each of them.
  • SBOM+ – A PBOM includes a traditional, static SBOM. But we add to the mix a thorough review of libraries, seeking potential threats that may not result from vulnerabilities. These threats include risks like inclusion of a dangerous license, out-of-date libraries that may be unsafe, poorly-maintained libraries, rarely-used libraries, deprecated libraries, and more.
  • Security Tool Scan – A PBOM helps show the full list of security tools in place in your dev ecosystem – static code analysis, SEA open source security, secrets scan, and more. We ensure not only that these tools are deployed, but also that they are the correct tool to cover your project.
  • Dev Process Review – The PBOM includes a scan of your dev process, looking for commit anomalies, commits without reviews, and commits from committers who aren’t part of a given project, yet commit anyway.
  • Secrets Scan – The PBOM scans for hard-coded keys or passwords – which would enable anyone with access to the code to access your resources. This is exactly what caused the Codecov incident – the code in question included a password to CDN.
  • Code Security – Ox conducts a static code analysis, looking for vulnerabilities in the code itself.
  • Infrastructure as code – Checks for best practices in IAC code configuration.
  • Container scan – Looks closely at the container binary and checks whether it includes vulnerable components.
  • Cloud security – Parses your cloud configuration against best practices and flags potential misconfigurations that could result in security issues.

How PBOM Protects Your Software Supply Chain

PBOM technology was created to secure the software supply chain, from code to deployment and beyond. It empowers dev stakeholders to gain visibility into each pipeline in the internal build environment – marking each artifact and verifying that every version provided to customers is safe. It does this by delivering:

  • Pipeline security – automatically tracks all pipeline branches, builds, pull requests, tickets, known issues and vulnerabilities 
  • Build integrity – ensures that software is built from only safe sources and dependencies, wasn’t modified during the build process, and that no malicious code is pushed through a compromised pipeline
  • Traceability – monitors every pipeline change non-stop, including documenting all changes, updating BOM consumption, and tracing each release

The Bottom Line

Moving to a PBOM model is accepting that development is a multi-leg journey, not just a one-way trip. PBOM answers three mission-critical ‘what’ questions:

  • What exactly am I protecting? And what is the status of what I’m protecting?
  • What are the tools I have to protect with? And how is the coverage of each tool for the asset it’s supposed to protect?
  • What’s the status of protection? And how does protection stack up in each category?

PBOM offers a new standard for software supply chain security – providing dev stakeholders with an unprecedented level of visibility over the software supply chain attack surface. From source code to pipeline, from artifacts to container images and runtime assets, and everything in-between – PBOM technology continuously monitors the changes that impact security. More importantly, it does so without hobbling developer agility – meaning you can ensure the safety of the software supply chain without slowing down development

Like it? Let’s share!

Susbscribe for updates

Related content