What does a PBOM consist of, exactly?
As we discussed in a previous post, Ox Security’s PBOM (Pipeline Bill of Materials) standard 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 eliminate 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.
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. This includes the first line of code all the way through to release. It’s a signed ledger of each pipeline build – tracking the complete software lifecycle, version lineage, SLSA.dev, SaasBOM, security history, build hashes, and more. As a result, dev teams can 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. This can be done locally, in the cloud, or in your ready-to-run artifact (where compiled artifacts are stored before uploaded to the cloud). As a result, DevOps can ensure that each component actually came from the CI/CD build pipeline, and wasn’t inserted by someone else. This is exactly 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 the 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. This includes static code analysis, SEA open source security, secrets scan, and more. OX ensures not only that these tools are deployed, but also that they are the correct tool to cover your project.
Dev Process Review
A 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
A 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
OX checks for best practices in IAC code configuration.
Container Scan
OX Looks closely at the container binary and checks whether it includes vulnerable components.
Cloud Security
OX parses your cloud configuration against best practices and flags potential misconfigurations that could result in security issues.
How PBOM Protects Your Software Supply Chain
The PBOM standard was created to secure the software supply chain, from code to deployment and beyond. As a result, dev stakeholders 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?
The 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. PBOM technology continuously monitors the changes that impact security from source code to pipeline, from artifacts to container images and runtime assets, and everything in-between. More importantly, it does so without impacting developer agility – meaning you can ensure the safety of the software supply chain without slowing down development
