From SBOM to PBOM: Defending Against Supply Chain Attacks

In this article: SBOM | PBOM | Vulnerabilities | Measures | Checklist

In the past, attackers searched for vulnerabilities in finished code. Today, they target the factory where it is produced. The SolarWinds attack (link in German) The SolarWinds attack (link in German) shook the foundations of IT security: Professionals now focus on the processes that transform code into trusted software, not just the end product.

The threat landscape ranges from psychological manipulation of key software developers to the invisible sabotage of automated production lines (pipelines). Traditional scanning tools and perimeter defenses fall short here, as they only assess the outcome, not the path that led to it.

The new reality is clear: The integrity of modern software is determined within the pipeline – not just in the source code.

SBOM as an established standard – and its limitations

The Software Bill of Materials (SBOM) has become an indispensable foundation for transparency in the software supply chain. It acts as a detailed inventory of all included components, libraries, and dependencies. As such, it is a key enabler for vulnerability scanning, license management, and compliance with regulatory requirements such as the EU Cyber Resilience Act.

In practice, however, the SBOM is often misunderstood as a purely static document – a kind of digital “table of contents” created at the end of the process. And this is precisely where a critical gap emerges: While the SBOM describes the final product, it provides no insight into how that product was actually built.

The analogy: Material list vs. construction log

To understand the blind spot of the SBOM, a comparison from the construction industry is helpful:

• The SBOM is the material list: It precisely documents which concrete, steel beams, and windows were used in the building. Based on this list, we can verify whether substandard materials were used (equivalent to scanning for known vulnerabilities).
• What’s missing is the construction log: The list does not tell us whether the steel beams were properly welded or whether an unauthorized third party tampered with the structure overnight while the cement was still wet.

The "blind spots” of the SBOM

When relying solely on a list of components, critical manipulation risks remain undetected:

• Build environment integrity: Was the server used to compile the software secure – or already compromised?
• Tool transparency: Which scripts and auxiliary tools were executed in the background? Were they authorized?
• Proof of integrity: Is there verifiable evidence that the process from code creation to the final package followed the intended, untampered path?

Transparency at the component level alone is no longer sufficient. To establish real trust, the focus must shift from individual components to the entire software creation process.

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.

Crime scene: Software pipeline – why the chain of trust breaks

The rise of the build pipeline as a primary attack target is not a theoretical prediction – it is a harsh reality. While the SolarWinds attack (2020) demonstrated how attackers could inject malicious code into legitimate updates by compromising a build server, more recent incidents have further refined these methods.

Real-world cases highlight this evolution of attacks:

• XZ Utils (2024): In this case, the human element was targeted. After years of social engineering, the attackers gained the trust of a key maintainer. Their goal was to manipulate the build process so that they could silently embed a backdoor into the final product.
• Codecov (2021): This incident illustrated the leverage of pipeline tools. A compromised script within the CI/CD environment enabled attackers to extract sensitive credentials (secrets) from thousands of customer pipelines.

The critical vulnerabilities of the modern software factory

Today’s attackers deliberately exploit the complexity of automated processes. Typical entry points include:

• Compromised build runners: If the digital workbench (the server where the build runs) is not isolated or has been tampered with, the entire process loses its trustworthiness.
• Shadow pipelines: Manipulations of the pipeline configuration allow attackers to inject their own build steps unnoticed, bypassing official code reviews.
• Long-lived secrets: Static passwords or tokens stored in pipeline variables for months are an open invitation to data theft.
• Blind spots in dependencies: Without strict control of external sources, malicious packages can be silently introduced into the build process.

These attacks do not aim to exploit an existing vulnerability in the finished product. They start much earlier: by manipulating the chain of trust at its source. This allows attackers to bypass all downstream security controls before the final product even exists. Whoever controls the “factory” no longer needs to plan a break-in at the “customer.”

The software pipeline as a fortress: Key measures

Securing the software supply chain is an ongoing strategy, not a one-time project. In order to defend against the aforementioned attacks, 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 something, you need to understand it. This phase is about shedding light on 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: 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