Von der SBOM zur PBOM: Supply Chain Angriffe abwehren

In diesem Artikel: SBOM | PBOM | Schwachstellen | Maßnahmen | Checkliste

Früher suchten Angreifer nach Lücken im fertigen Code – heute attackieren sie die Fabrik, in der er hergestellt wird. Spätestens seit dem SolarWinds-Vorfall ist das Fundament der IT-Sicherheit erschüttert: Profis fokussieren sich nicht mehr nur auf das Endprodukt, sondern auf die Prozesse, die Code in vertrauenswürdige Software verwandeln.

Das Spektrum reicht von psychologischen Tricks gegen zentrale Software-Entwickler bis hin zur unsichtbaren Sabotage automatisierter Fertigungsstraßen (Pipelines). Herkömmliche Scans und Schutzwälle laufen hierbei ins Leere, da sie nur das Ergebnis prüfen, aber nicht den Weg dorthin.

Die neue Realität lautet: Die Integrität moderner Software entscheidet sich heute in der Pipeline und nicht mehr allein im Quellcode. 

SBOM als etablierter Standard und seine Grenzen

Die Software Bill of Materials (SBOM) hat sich als unverzichtbares Fundament für Transparenz in der Software-Lieferkette durchgesetzt. Sie fungiert als detaillierte Bestandsliste aller enthaltenen Komponenten, Bibliotheken und Abhängigkeiten. Damit ist sie das wichtigste Werkzeug für Schwachstellen-Scans, Lizenzmanagement und die Erfüllung gesetzlicher Vorgaben, wie sie beispielsweise der EU Cyber Resilience Act fordert.

In der Praxis wird die SBOM jedoch oft als rein statisches Dokument missverstanden, eine Art digitales „Inhaltsverzeichnis“, das erst am Ende der Kette erstellt wird. Doch genau hier entsteht die gefährliche Lücke: Die SBOM beschreibt zwar das fertige Produkt, sagt aber nichts über dessen Entstehung aus.

Die Analogie: Materialliste vs. Baustellen-Protokoll

Um den blinden Fleck der SBOM zu verstehen, hilft ein Vergleich aus dem Hochbau:

• Die SBOM ist die Materialliste: Sie führt exakt auf, welcher Beton, welche Stahlträger und welche Fenster im Gebäude verbaut wurden. Anhand dieser Liste können wir prüfen, ob minderwertiges Material verwendet wurde (entspricht dem Scan auf bekannte Schwachstellen).
• Was fehlt, ist das Abnahmeprotokoll der Baustelle: Die Liste sagt uns nicht, ob die Stahlträger fachgerecht verschweißt wurden oder ob ein unbefugter Dritter in der Nacht die Statik manipuliert hat, während der Zement noch feucht war.

Die „blinden Flecken“ der SBOM

Wenn wir uns auf die reine Komponentenliste verlassen, übersehen wir kritische Manipulationsmöglichkeiten:

• Integrität der Build-Umgebung: War der Server, auf dem die Software kompiliert wurde, sicher oder bereits infiziert?
• Werkzeug-Transparenz: Welche Skripte und Hilfsprogramme liefen im Hintergrund mit? Wurden sie autorisiert?
• Nachweis der Unverfälschtheit: Gibt es einen Beweis, dass der Prozess zwischen dem Schreiben des Codes und dem fertigen Paket exakt so ablief wie geplant?

Die Transparenz über die einzelnen Komponenten allein reicht heute nicht mehr aus. Um echtes Vertrauen zu schaffen, müssen wir den Blick von den Komponenten auf den gesamten Entstehungsprozess ausweiten. 

PBOM & Attestation: Die nächste Evolutionsstufe

Um die blinden Flecken der SBOM zu schließen, rückt ein erweitertes Sicherheitsmodell in den Fokus: die Pipeline Bill of Materials (PBOM).

Dabei handelt es sich weniger um einen festgelegten Standard als vielmehr um ein konzeptionelles Modell für die sogenannte Build Provenance. Das Ziel: ein lückenloser, manipulationssicherer Herkunftsnachweis für jedes Softwareartefakt. Dieser wird durch kryptografisch abgesicherte Attestations (digitale Beglaubigungen) untermauert.

Stellen Sie sich vor, Sie erhalten eine wertvolle Lieferung (Ihre Software):

• Die SBOM ist die Bestandsliste im Paket: "1 Goldbarren, 10 kg".
• Die PBOM hingegen ist das digitale Fahrtenbuch des gepanzerten Transporters: Es protokolliert, wer das Depot wann verlassen hat, welche Route genommen wurde, welche Sicherheitschecks an den Mautstellen erfolgten und wer zu jedem Zeitpunkt den Schlüssel zum Laderaum besaß.

Erst wenn das Protokoll (PBOM) beweist, dass der Transporter nie unbeaufsichtigt war, können Sie sicher sein, dass der Inhalt (SBOM) nicht unbemerkt ausgetauscht wurde. 

Was eine PBOM im digitalen Raum dokumentiert

Ein PBOM-orientierter Ansatz erstellt ein detailliertes "Logbuch" des Entstehungsprozesses. Dazu gehören:

• Die Werkbank: Welche CI/CD-Systeme (z. B. GitHub Actions, GitLab, Tekton) wurden genutzt?
• Die Akteure: Welche Identitäten und Berechtigungen waren im Build-Prozess aktiv?
• Die Werkzeuge: Welche Build-Runner, Skripte und Versionen kamen zum Einsatz?
• Die Quellen: Aus welchen Repositories wurden die Rohdaten bezogen?
• Der Siegelring: Wie sahen die Signierungs- und Release-Prozesse aus?

Initiativen wie SLSA (Supply-chain Levels for Software Artifacts), in-toto oder Sigstore liefern heute bereits die technischen Bausteine, um diese Nachweise automatisiert zu erzeugen. 

Von der Annahme zum Beweis

Der entscheidende Unterschied lässt sich auf eine einfache Formel bringen: Während die SBOM dokumentiert, was gebaut wurde, belegt die PBOM, wie, wo und unter welchen Bedingungen es entstanden ist.

Dieser Perspektivwechsel markiert den Übergang zur „Evidence-based Security“: Vertrauen wird nicht mehr einfach vorausgesetzt (Implicit Trust), sondern durch digitale Beweisketten technisch nachweisbar gemacht. 

Tatort Software-Pipeline: Warum die Vertrauenskette reißt

Dass die Build-Pipeline zum primären Angriffsziel avanciert ist, ist keine theoretische Prognose, sondern bittere Realität. Während der SolarWinds-Hack (2020) demonstrierte, wie Angreifer durch die Infektion eines Build-Servers Schadcode in legitime Updates einschleusen konnten, haben jüngere Vorfälle die Methoden weiter verfeinert.

Reale Vorfälle verdeutlichen diese Evolution der Angriffe:

• XZ Utils (2024): Hier wurde die menschliche Komponente attackiert. Durch jahrelanges Social Engineering erschlichen sich Angreifer das Vertrauen eines Hauptentwicklers (Maintainer). Ihr Ziel: Den Build-Prozess so zu manipulieren, dass eine Hintertür unbemerkt in das Endprodukt gelangte.
• Codecov (2021): Dieser Fall zeigte die Hebelwirkung von Pipeline-Tools. Ein kompromittiertes Skript innerhalb der CI/CD-Umgebung ermöglichte es Angreifern, sensible Zugangsdaten (Secrets) aus tausenden Kunden-Pipelines abzugreifen.

Die kritischen Schwachstellen der modernen Software-Fabrik

Die Angreifer von heute nutzen gezielt die Komplexität automatisierter Prozesse aus. Zu den typischen Einfallstoren zählen:

• Kompromittierte Build-Runner: Wenn die digitale Werkbank (der Server, auf dem der Build läuft) nicht isoliert oder manipuliert ist, verliert der gesamte Prozess seine Vertrauenswürdigkeit.
• Shadow Pipelines: Manipulationen an der Pipeline-Konfiguration ermöglichen es, unbemerkt eigene Build-Schritte einzuschleusen, die im offiziellen Code-Review nicht auftauchen.
• Langlebige Secrets: Statische Passwörter oder Tokens, die über Monate in Pipeline-Variablen gespeichert werden, sind eine Einladung für Datendiebe.
• Blinde Flecken bei Abhängigkeiten: Ohne strikte Kontrolle externer Quellen können bösartige Pakete unbemerkt in den Build-Prozess „hineingezogen“ werden.

Diese Angriffe zielen nicht darauf ab, eine bereits bestehende Sicherheitslücke im fertigen Produkt auszunutzen. Sie setzen viel früher an: Sie manipulieren die Vertrauenskette an ihrer Quelle. Damit umgehen sie alle späteren Sicherheitskontrollen, noch bevor das fertige Produkt überhaupt existiert. Wer die Kontrolle über die „Fabrik“ hat, braucht keinen Einbruch beim „Kunden“ mehr zu planen. 

Die Software-Pipeline als Festung: Zentrale Maßnahmen  

Die Absicherung der Software-Lieferkette ist kein einmaliges Projekt, sondern eine Strategie der „gehärteten Fabrik“. Um die bereits beschriebenen Angriffe abzuwehren, müssen die Build-Prozesse technisch und organisatorisch geschützt werden. 

Die „Einweg-Werkbank“ (Isolierte Umgebungen)

Anstatt einen festen Server zu nutzen, auf dem über Monate verschiedene Projekte gebaut werden, setzen moderne Pipelines auf kurzlebige (ephemere) Umgebungen.

• Das Prinzip: Für jeden einzelnen Build-Vorgang wird eine fabrikneue, isolierte digitale Werkbank erstellt, die nach getaner Arbeit sofort gelöscht wird.
• Der Vorteil: Angreifer können sich nicht dauerhaft im System einnisten. Es gibt keine Rückstände vom vorherigen Durchlauf, ein konsequenter Zero-Trust-Ansatz. 

Der „Fingerabdruck“ des Prozesses (Reproduzierbarkeit)

Ein sicherer Prozess muss vorhersagbar sein. Reproduzierbare Builds stellen sicher, dass der gleiche Quellcode unter den gleichen Bedingungen immer zum exakt gleichen digitalen Ergebnis führt.

• Der Vorteil: Weicht das Ergebnis auch nur um ein Bit ab, ist das ein Alarmsignal für eine Manipulation während des Herstellungsprozesses. 

Digitale Siegel und Herkunftsnachweise (Signierung & Provenance)

Jedes fertige Software-Paket erhält ein fälschungssicheres digitales Siegel. Ergänzt wird dies durch die Provenance, ein automatisch erstelltes Protokoll des gesamten Entstehungswegs.

• Werkzeuge: Moderne Lösungen ermöglichen es, diese Siegel automatisiert und in großem Stil zu vergeben, sodass die gesamte Vertrauenskette jederzeit überprüfbar bleibt. 

Abschied vom Generalschlüssel (Secretless CI/CD)

Statische Passwörter, die monatelang in den Einstellungen der Pipeline schlummern, sind ein enormes Risiko. Ein gängiger Ansatz ist daher die „Secretless CI/CD“.

• Die Lösung: Anstatt fester Passwörter nutzen Systeme kurzlebige Identitäten (z. B. via OIDC). Die Pipeline weist sich gegenüber anderen Diensten digital aus und erhält nur für Sekundenbruchteile genau die Rechte, die sie gerade benötigt (Least-Privilege-Prinzip).

Digitale Türsteher (Policy as Code)

Sicherheitsregeln sollten nicht in Handbüchern stehen, sondern direkt im Code der Pipeline festgeschrieben sein (Policy as Code).

• Der Effekt: Wenn ein Software-Paket beispielsweise kein gültiges Herkunftssiegel besitzt, stoppt der „digitale Türsteher“ den Prozess automatisch. Ohne korrekte Nachweise gelangt keine Software zur Veröffentlichung. 

Kontrolle der Zulieferer (Abhängigkeiten)

Keine Fabrik ist sicher, wenn die Bauteile aus ungeprüften Quellen stammen. Zur Absicherung gehören:

• Festschreiben von Versionen (Version Pinning): Es wird exakt definiert, welche Version eines Bauteils genutzt wird, um unerwartete „Updates“ mit Schadcode zu verhindern.
• Verifizierte Quellen: Bausteine werden nur aus vertrauenswürdigen, internen oder zertifizierten Archiven bezogen.

Der Weg zur sicheren Software-Pipeline: Ein Drei-Stufen-Modell

Die Theorie der PBOM klingt logisch, doch die Umsetzung in gewachsenen IT-Landschaften ist eine Herausforderung. Oft prallen hier unterschiedliche Welten aufeinander: Die Entwicklung will Geschwindigkeit, die Security will Kontrolle und der Betrieb braucht Stabilität.

Um diese Silos aufzubrechen, hat sich ein schrittweises Vorgehen bewährt, das sich an Reifegradmodellen wie SLSA (Supply-chain Levels for Software Artifacts) orientiert: 

Stufe 1: Sichtbarkeit schaffen (Transparenz)

Bevor man schützt, muss man verstehen. In dieser Phase geht es darum, Licht in die „Blackbox“ der Software-Entstehung zu bringen.

• Maßnahmen: Automatische Erzeugung von digitalen Zutatenlisten (SBOM) bei jedem Build und lückenloses Logging der Pipeline-Aktivitäten.
• Das Ziel: Wissen, was verbaut wird und wer wann welche Prozesse gestartet hat. 

Stufe 2: Vertrauen untermauern (Integrität)

Bei diesem Schritt geht es darum, die Echtheit der Software zu garantieren. Wir fangen an, Siegel" zu vergeben.

• Maßnahmen: Einführung der ersten digitalen Signaturen für Software-Pakete. Man orientiert sich hier an den ersten SLSA-Leveln (z. B. Nachweis, dass der Build-Prozess durch ein Skript und nicht manuell erfolgte).
• Das Ziel: Sicherstellen, dass die Software auf dem Weg vom Entwickler zum Kunden nicht unbemerkt verändert wurde.

Stufe 3: Widerstandsfähigkeit festigen (Resilienz)

In der Königsdisziplin wird die Pipeline zu einer gut geschützten Festung.

• Maßnahmen: Umstellung auf Secretless CI/CD (keine dauerhaften Passwörter mehr), Erzeugung vollständiger Herkunftsnachweise (Provenance) und der Einsatz von digitalen Türstehern (Policy as Code), die unsichere Builds sofort stoppen.
• Das Ziel: Ein hochautomatisches System, das Manipulationsversuche im Keim erstickt und nur zertifizierte Software durchlässt.

Versuchen Sie nicht, alles gleichzeitig umzusetzen. Starten Sie mit der Sichtbarkeit (Stufe 1) in einem Pilotprojekt und skalieren Sie die Sicherheit, sobald die Prozesse stabil laufen. 

SBOM + PBOM: Das Duett für lückenlose Compliance

Echtes Vertrauen entsteht erst, wenn wir beide Seiten der Medaille betrachten. Das Zusammenspiel von SBOM und PBOM liefert das vollständige Bild der Software-Lieferkette:

• SBOM (Die Inhaltsangabe): Schafft Transparenz über die verbauten Komponenten.
• PBOM (Das Fertigungsprotokoll): Schafft Transparenz über die zugrunde liegenden Prozesse.

Erst diese Kombination ermöglicht eine lückenlose Nachvollziehbarkeit (End-to-End-Visibility). In einer Zeit, in der Regulierungen wie der EU Cyber Resilience Act (CRA) zur Pflicht werden, ist dieser duale Ansatz der beste Weg.

Die PBOM dient dabei als „digitaler Beweis“ bei Audits: Sie belegt schwarz auf weiß, dass ein Unternehmen seine Sorgfaltspflichten erfüllt und die Software unter kontrollierten, sicheren Bedingungen produziert hat.

Das Ziel ist klar: Wir bauen nicht mehr nur Software, sondern eine nachweislich vertrauenswürdige Software-Lieferkette. 

Build Integrity als neues Qualitätsmerkmal

Die Absicherung der Software-Lieferkette entwickelt sich zunehmend vom Spezialthema zum zentralen Bestandteil moderner Softwareentwicklung. Der entscheidende Wendepunkt ist die Erkenntnis, dass wir Vertrauen nicht mehr allein aus dem Quellcode ableiten können. Die Integrität der Build-Pipeline rückt an die Stelle, an der früher die Firewall stand: Sie ist der neue, zentrale Sicherheitsanker.

Softwarequalität sollte neu definiert werden: Es geht nicht mehr nur darum, ob der Code funktioniert oder frei von bekannten Lücken ist, sondern ob sein Entstehungsprozess zweifelsfrei dokumentiert und gegen Manipulation geschützt wurde (Build Integrity).

Die Botschaft für Unternehmen ist unmissverständlich: Wer heute seine Pipeline nicht absichert, wird morgen die Integrität seiner Software nicht mehr garantieren können und verliert damit das wichtigste Gut in der digitalen Welt: das Vertrauen seiner Kunden.

Praxis-Check-up: Ist Ihre Software-Pipeline zukunftssicher? 

Verwenden Sie diese fünf Kriterien, um den Reifegrad Ihrer Supply Chain Security zu bewerten:

• Digitale Siegel: Werden alle produktionsrelevanten Artefakte konsequent digital signiert?
• Einweg-Werkbänke: Kommen ausschließlich ephemere (kurzlebige) Build-Umgebungen zum Einsatz?
• Identität statt Passwort: Wurden statische Credentials durch moderne Verfahren (OIDC) ersetzt?
• Beweiskette: Werden Herkunftsnachweise (Provenance) und Beglaubigungen automatisiert erzeugt?
• Automatisierte Leitplanken: Werden Sicherheitsrichtlinien als Code (Policy as Code) direkt in der Pipeline erzwungen? 

Weiterführende Ressourcen zum Thema Software Supply Chain Security 

• Aufzeichnung: Supply Chain Attacks - A red teamer's perspective
• Aufzeichnung: Die unsichtbare Bedrohung meistern: Mit Cyber Supply Chain Risk Management & Cyber Security Compliance
• Aufzeichnung: SaaS im Fadenkreuz: Angriffe auf Cloud-Apps und Lieferketten
• Aufzeichnung: Supply Chain Security agil meistern im Spannungsfeld von CRA und NIS2
• Supply Chain Attacks: vergiftete KI
• Log4J zeigt: Gefährliche Supply-Chain-Angriffe werden bei Angreifern immer beliebter
• it-sa Expo&Congress 2025: Sicherheit in Bewegung – von vernetzten Lieferketten bis zu quantensicheren Algorithmen
• Themenseite: IT-Regulierung