From SBOM to PBOM: Defending Against Supply Chain Attacks

PBOM & attestation: the next stage of evolution

To close the blind spots of the SBOM, an extended security model is coming into focus: the Pipeline Bill of Materials (PBOM).

Rather than being a fixed standard, it is a conceptual model for what is known as build provenance. The goal is to create a complete, tamper-proof record of origin for every software artifact. This is reinforced by cryptographically secured attestations (digital certifications).

Imagine receiving a valuable shipment (your software):

• The SBOM is the inventory list inside the package: “1 gold bar, 10 kg.”
• The PBOM, on the other hand, is the digital logbook of the armored transport vehicle: it records who left the depot and when, which route was taken, which security checks were carried out at checkpoints, and who held the key to the cargo hold at every point in time.

Only when the log (PBOM) proves that the transporter was never left unattended can you be certain that the contents (SBOM) were not tampered with unnoticed.

What a PBOM documents in the digital realm

A PBOM-oriented approach creates a detailed “logbook” of the software creation process. This includes:

• The workbench: Which CI/CD systems (e.g. GitHub Actions, GitLab, Tekton) were used?
• The actors: Which identities and permissions were active during the build process?
• The tools: Which build runners, scripts, and versions were deployed?
• The sources: From which repositories were the raw inputs retrieved?
• The seal: What did the signing and release processes look like?

Initiatives such as SLSA (Supply-chain Levels for Software Artifacts), in-toto, and Sigstore already provide the technical building blocks to generate these proofs in an automated way.

From assumption to proof

The key difference can be summed up in a simple formula: while the SBOM documents what was built, the PBOM proves how, where, and under which conditions it was created.

This shift in perspective marks the transition to "evidence-based security": trust is no longer assumed (implicit trust), but is instead made verifiable through cryptographically secured chains of evidence.

The software pipeline as a fortress: key measures

Securing the software supply chain is not a one-time project, but a strategy of a “hardened factory.” To defend against the attacks described above, build processes must be protected both technically and organizationally.

The “one-time workbench” (isolated environments)

Instead of using a fixed server where different projects are built over months, modern pipelines rely on short-lived (ephemeral) environments.

• The principle: For each individual build process, a brand-new, isolated digital workbench is created and deleted immediately after completion.
• The advantage: Attackers cannot establish persistent access within the system. There are no remnants from previous runs – a consistent zero-trust approach.

The “fingerprint” of the process (reproducibility)

A secure process must be predictable. Reproducible builds ensure that the same source code, under the same conditions, always produces the exact same digital output.

• The advantage: Even a single-bit deviation in the result is a clear warning signal of manipulation during the build process.

Digital seals and proof of origin (signing & provenance)

Every completed software package is assigned a tamper-proof digital seal. This is complemented by provenance, an automatically generated record of the entire build and delivery process.

• Tools: Modern solutions enable these seals to be applied in an automated and scalable way, ensuring that the entire chain of trust remains verifiable at all times.

Moving away from the master key (secretless CI/CD)

Static passwords stored in pipeline settings for months pose a significant risk. A common approach to mitigate this is “secretless CI/CD".

• The solution: Instead of fixed credentials, systems use short-lived identities (e.g. via OIDC). The pipeline authenticates itself digitally to other services and is granted only the exact permissions it needs – and only for a fraction of a second (principle of least privilege).

Digital gatekeepers (policy as code)

Security rules should not reside in manuals, but be embedded directly into the pipeline code (policy as code).

• The effect: If a software package, for example, does not have a valid proof of origin, the “digital gatekeeper” automatically stops the process. Without proper verification, no software is released.

Control of suppliers (dependencies)

No factory is secure if its components come from unverified sources. Key measures include:

• Version pinning: Precisely defining which version of a component is used to prevent unexpected “updates” that may introduce malicious code.
• Verified sources: Components are sourced only from trusted, internal, or certified repositories.

The path to a secure software pipeline: a three-stage model

The concept of PBOM is logical, but implementing it in established IT environments is a challenge. Different priorities often collide: development demands speed, security requires control, and operations need stability.

To break down these silos, a step-by-step approach has proven effective, based on maturity models such as SLSA (Supply-chain Levels for Software Artifacts):

Stage 1: Creating visibility (transparency)

Before you can protect, you need to understand. This phase is about bringing light into the “black box” of software creation.

• Measures: Automated generation of digital ingredient lists (SBOM) with every build and comprehensive logging of pipeline activities.
• The goal: to know what is being built and who initiated which processes and when.

Stage 2: Reinforcing trust (integrity)

This step is about guaranteeing the authenticity of the software. We begin to apply “seals.”

• Measures: Introduction of initial digital signatures for software packages. This typically aligns with early SLSA levels (e.g. proof that the build process was executed via script rather than manually).
• The goal: to ensure that the software has not been altered unnoticed on its way from developer to customer.

Stage 3: Strengthening resilience

At the highest level, the pipeline becomes a well-protected fortress.

• Measures: Transition to secretless CI/CD (eliminating long-lived credentials), generation of comprehensive provenance records, and the use of digital gatekeepers (policy as code) that immediately stop insecure builds.
• The goal: a highly automated system that neutralizes tampering attempts at an early stage and allows only certified software to pass.

Do not try to implement everything at once. Start with visibility (Stage 1) in a pilot project and scale security as processes become stable.

SBOM + PBOM: the duo for end-to-end compliance

True trust only emerges when both sides of the equation are considered. The combination of SBOM and PBOM provides a complete view of the software supply chain:

• SBOM (the list of ingredients): creates transparency about the components used.
• PBOM (the production log): creates transparency about the underlying processes.

Only this combination enables full traceability (end-to-end visibility). At a time when regulations such as the EU Cyber Resilience Act (CRA) are becoming mandatory, this dual approach is the most effective path forward.

In this context, the PBOM serves as “digital evidence” during audits: it provides clear proof that an organization has fulfilled its due diligence obligations and produced software under controlled, secure conditions.

The goal is clear: we are no longer just building software – we are building a verifiably trustworthy software supply chain.

Build integrity as a new quality benchmark

Securing the software supply chain is rapidly evolving from a niche concern into a core element of modern software development. The decisive turning point is the realization that trust can no longer be derived from source code alone. The integrity of the build pipeline is taking the place once held by the firewall: it has become the new central security anchor.

Software quality must be redefined: it is no longer just about whether code functions correctly or is free of known vulnerabilities, but whether its creation process is fully documented and protected against tampering (build integrity).

The message for organizations is clear: those who fail to secure their pipeline today will not be able to guarantee the integrity of their software tomorrow – and will lose the most valuable asset in the digital world: the trust of their customers.

Practical check-up: is your software pipeline future-proof?

Use these five criteria to assess the maturity of your supply chain security:

• Digital seals: Are all production-relevant artifacts consistently digitally signed?
• One-time workbenches: Are only ephemeral (short-lived) build environments used?
• Identity instead of passwords: Have static credentials been replaced by modern methods (OIDC)?
• Chain of evidence: Are provenance records and attestations generated automatically?
• Automated guardrails: Are security policies enforced directly in the pipeline as code (policy as code)?

Further resources on software supply chain security

• Recording: Supply Chain Attacks - A red teamer's perspective
• Recording: Supply Chain Attacks
• Recording: Coping with the invisible threat: with cyber supply chain risk management & cyber security compliance
• Recording: SaaS in the Crosshairs: Attacks on Cloud Apps and Supply Chains
• Recording: Supply Chain Security agile in the tension of CRA & NIS2
• Supply chain attacks: poisoned AI
• Log4J shows: Dangerous Supply chain attacks are becoming increasingly popular with attackers
• Supply Chain Security & Post-Quantum Cryptography
• IT-Regulation