From SBOMs to PBOMs: Tracking Vulnerability SLAs Across the Entire Pipeline

From SBOMs to PBOMs: Tracking Vulnerability SLAs Across the Entire Pipeline

The landscape of software supply chain security has undergone a real shift heading into 2026. For years, DevSecOps teams treated the Software Bill of Materials (SBOM) as the gold standard for vulnerability management — a structured, machine-readable inventory of the open-source libraries and third-party dependencies packaged inside an application. But as attackers have moved up the stack, their targets have moved with them. Increasingly, the most damaging supply chain attacks don't touch application source code at all. They compromise the mechanisms that assemble and ship the software in the first place — the CI/CD pipeline itself.

That shift is what's driving industry adoption of the Pipeline Bill of Materials (PBOM), a concept originated by the software supply chain security vendor OX Security and since picked up across the ASPM (Application Security Posture Management) market. Where an SBOM answers "what is in this software?", a PBOM is built to answer a harder set of questions: how was this software built, by whom, on what infrastructure, and can that build process actually be trusted? For teams running automated CI/CD, securing the application code is no longer the whole job — they have to secure the factory that produces it. This article looks at why PBOMs are gaining traction, walks through several real 2026 incidents that make the case, and covers how DevSecOps teams can use platforms like InstaSLA to group and enforce patch deadlines across build infrastructure rather than drowning in one-off tickets.

---

Why SBOMs Are Necessary but Insufficient

SBOM mandates gave security teams a genuinely useful baseline for compliance and vulnerability response: with a machine-readable inventory in hand (typically in CycloneDX or SPDX format), a team can find out in minutes whether a newly disclosed CVE touches their environment, instead of manually crawling builds and containers. That value is real. But taken alone, an SBOM has three structural blind spots that have become harder to ignore in 2026.

1. The static snapshot problem. A traditional SBOM is generated at a point in time — usually at build or release. Software delivery isn't a point in time, though; it's a continuous system of pipelines, registries, caches, and runners that changes constantly. Any security signal derived from a static snapshot starts decaying the moment it's generated.
2. Blind spots in the build process. An SBOM can confirm your application depends on a patched version of a library. It cannot tell you whether a malicious actor tampered with the build itself — injected a step, ran an unauthorized script, or swapped an artifact after the scan ran. Several of 2026's highest-profile incidents happened at exactly this layer, not in a vulnerable dependency.
3. The infrastructure gap. A lot of supply chain risk today lives in the automation around the code — in build runners, packaging steps, and deployment jobs — rather than in the code review process itself. An organization can have disciplined code review and still inherit serious exposure from an outdated runner image or an over-permissioned deployment workflow.

In short: an SBOM tells you what's inside your software. It doesn't tell you how that software got built, or whether the process that built it can be trusted.

---

The Silent Threat: CI/CD Pipeline Vulnerabilities Are No Longer Theoretical

Treating build infrastructure as inherently trustworthy has become one of the more dangerous assumptions in DevSecOps. A handful of incidents from just the past several months of 2026 make the case better than any hypothetical could:

• TanStack (May 11, 2026). Attackers breached the TanStack open-source project's GitHub repository and npm publishing pipeline, exploiting weaknesses in its GitHub Actions workflows to push 84 malicious versions across 42 @tanstack npm packages. The compromise self-propagated by harvesting credentials from infected CI and developer environments, reaching secondary victims including Mistral AI, UiPath, and more than 160 additional npm and PyPI packages. The threat group behind it, tracked as TeamPCP, has since been linked to a string of related campaigns.
• MEGALODON_CI (May 18, 2026). In a single six-hour window, attackers pushed more than 5,700 malicious GitHub Actions workflow commits across over 5,500 repositories using throwaway CI-bot accounts with forged identities. Some of the injected workflows contained a dormant workflow_dispatch backdoor designed to activate later, on any future pipeline run triggered through the GitHub API — effectively planting a sleeper army inside CI configuration rather than in a dependency. CISA issued an advisory naming the campaign.
• AsyncAPI (July 14, 2026). This one is worth sitting with, because it undercuts a comforting assumption a lot of teams make about provenance. Attackers didn't steal an npm publishing token. They gained push access to a branch in two AsyncAPI repositories and let the project's own legitimate GitHub Actions release workflow do the publishing for them, using npm's OIDC trusted-publisher integration. The resulting packages carried valid, cryptographically correct provenance attestations — because the attestations only prove that the authorized workflow produced the artifact, not that the commits which triggered that workflow were legitimate. A misconfigured pull_request_target trigger was the initial entry point, per Microsoft's writeup of the incident.
• ChainDrop / "Mini Shai-Hulud" (August 2026). A self-propagating, credential-stealing worm variant hit more than 400 npm packages across unrelated publishers, executing automatically through an npm preinstall lifecycle hook before package installation even completed — firing inside the build runner and bypassing static scanners that only run later in the pipeline.
• Bitwarden CLI (April 22, 2026). Even security-focused vendors aren't exempt: the @bitwarden/cli package was poisoned for a roughly 93-minute window via an injected step in Bitwarden's own CI pipeline, with the same actor publicly claiming responsibility.

A few patterns run through all of these: attackers targeting pull_request_target misconfigurations ("pwn requests"), lifecycle/install-time scripts that fire before a scanner ever sees the code, and — critically — the harvesting of the non-human identities (tokens, OIDC credentials, signing keys) that pipelines depend on to publish and deploy. Once a runner or a bot token is compromised, those credentials often grant lateral movement across cloud environments well beyond the original repository.

GitHub itself has responded with several structural changes through 2026 aimed at this exact attack surface: safer defaults for pull_request_target in actions/checkout that block fork PRs from running with elevated permissions unless a maintainer opts in, new controls to restrict who can trigger a workflow and how, and staged npm publishing that requires a second authorization step before a new package version goes live — decoupling CI/CD publishing credentials from the ability to actually ship to the registry. These are useful mitigations, but the AsyncAPI case shows they don't fully close the gap: a compromised push credential upstream of a legitimate, trusted workflow can still produce artifacts that pass every automated integrity check.

That's the real argument for PBOMs. Scanning the output artifact was never going to be enough on its own; the pipeline that produced it has to be watched continuously.

---

Decoding the Pipeline Bill of Materials (PBOM)

The PBOM concept, originated by OX Security, extends the transparency of an SBOM to the entire assembly process. It's defined as a continuously updated, signed ledger of the components, services, tooling, and transformations involved in delivering software from source to release. In practice, that includes:

1. Runner identity and build arguments — which runner executed the build, what environment variables were present, and what arguments were actually passed.
2. Pipeline definitions — the state of CI/CD configuration files, so a maliciously altered workflow can be detected against its last verified version.
3. Artifact transformations — how an artifact changed during release: minification, bundling, re-signing, container layering.
4. Version lineage — a full trail from first commit to production, spanning branches, pull requests, and SLSA-relevant provenance data.

A PBOM doesn't replace an SBOM; it contains the SBOM as one component of a much larger, verifiable build record. And critically, in light of incidents like AsyncAPI, a PBOM's value comes specifically from continuous monitoring of pipeline behavior and identity — not from a one-time provenance attestation. A signed SLSA attestation tells you a trusted workflow produced an artifact; it can't by itself tell you whether the inputs to that workflow were tampered with. Closing that gap is exactly the behavioral, always-on layer PBOMs are meant to add.

The broader industry has converged around related efforts worth knowing: OX Security also co-created the Open Software Supply Chain Attack Reference (OSC&R) alongside security teams from Google, Microsoft, and GitLab — a MITRE ATT&CK-style taxonomy specifically for supply chain attack techniques, giving teams a shared vocabulary for the tactics behind incidents like the ones above. Without this level of visibility — pipeline-aware, not just artifact-aware — incident response tends to stall, because defenders can't easily tell whether a compromise originated in a dependency, a vulnerable runner image, or an unauthorized deployment job.

---

Managing Pipeline SLAs with InstaSLA

Adopting PBOMs generates a real increase in security signal. Teams suddenly see alerts not just for outdated application libraries, but for outdated runner images, misconfigured pipeline permissions, and unpinned or deprecated actions. Sonatype's research has repeatedly found that a large share of dependencies — commonly cited around 80% — go unpatched for more than a year even when fixes are available; extend that same neglect pattern to pipeline infrastructure and the backlog becomes unmanageable without an industrialized approach to SLAs.

Consider a zero-day in a base image used for GitHub Actions runners — the kind of image that might be reused across hundreds of repositories. Filing hundreds of individual tickets creates paralyzing alert fatigue and guarantees slow, inconsistent remediation. This is where intelligent grouping and SLA enforcement, via a platform like InstaSLA, changes the outcome.

1. Grouping infrastructure vulnerabilities by root cause

Rather than surfacing repository-level alerts one at a time, InstaSLA can ingest PBOM data and group findings by shared infrastructure root cause. If dozens or hundreds of pipelines fail PBOM verification because they all rely on the same outdated ubuntu-latest runner image carrying a critical CVE, the system rolls those into a single, high-priority Fix Campaign — "update the base runner image across all affected CI workflows" — instead of generating a wall of duplicate tickets.

2. Contextual SLA assignment

Vulnerabilities in build infrastructure warrant different urgency than application code. Teams using InstaSLA can define SLA policies specific to pipeline risk, for example:

• Critical pipeline flaw (e.g., an exposed signing key or token inside a runner): immediate halt, roughly a 12-hour SLA.
• High severity (e.g., an outdated runner base image with a known CVE): a 48-hour SLA.
• Medium severity (e.g., unpinned action versions — the exact pattern behind several of the incidents above): a 14-day SLA.

Mapping SLAs directly to PBOM findings gives security teams clear, non-negotiable deadlines for keeping the software factory itself in good hygiene, rather than treating pipeline debt as a lower tier of risk by default.

3. Enforcing SLA breaches at the build level

The real leverage of pairing PBOMs with SLA tracking is automated enforcement. If an engineering team misses the agreed SLA on a vulnerable runner image, the pipeline itself can block further production deployments until it's resolved. InstaSLA provides the centralized tracking and audit trail needed to justify that kind of block — so teams can't quietly route around infrastructure risk the way they might ignore a low-priority Dependabot alert.

---

Conclusion

Software supply chain security in 2026 has genuinely expanded from "secure the artifact" to "secure the factory." SBOMs remain a necessary foundation for dependency tracking, but as the TanStack, MEGALODON_CI, AsyncAPI, and ChainDrop incidents all show in different ways, they're blind to threats that target the CI/CD pipeline directly — including, in AsyncAPI's case, threats that still produce cryptographically valid provenance.

The Pipeline Bill of Materials gives teams the continuous, signed record needed to actually trust the software delivery process, rather than trusting it by default. By tracking runner identity, pipeline definitions, and artifact transformations, PBOMs — paired with frameworks like OSC&R for classifying the attacker techniques involved — bring visibility to parts of the build environment that traditional scanning never reached. But visibility alone doesn't remediate anything. Pairing PBOM intelligence with disciplined SLA management through a platform like InstaSLA — to group duplicate pipeline alerts, assign realistic deadlines, and enforce them — is what turns that visibility into an actual reduction in risk. A vulnerability in a GitHub Actions runner deserves the same urgency as one in your source code, because in 2026, attackers are already treating it that way.Supply Chain "Chain Reactions": Stopping Multi-Stage Intrusions at the Dependency Layer