SBOM und Software Supply Chain Security — Schutz der Lieferkette

SolarWinds, Log4Shell, xz Utils — Supply-Chain-Angriffe sind zu einer der schwerwiegendsten Bedrohungen geworden. Wie kann man sich verteidigen? SBOM (Software Bill of Materials) und das SLSA-Framework sind die Antwort, die jedes Unternehmen im Jahr 2026 braucht.

Warum Supply Chain Security kritisch ist¶

Moderne Software besteht zu 80–90 % aus Open-Source-Abhängigkeiten. Die durchschnittliche Enterprise-Anwendung hat Hunderte von direkten und Tausende von transitiven Abhängigkeiten. Jede einzelne ist ein potenzieller Einstiegspunkt für einen Angreifer.

Supply-Chain-Angriffe sind besonders tückisch, weil sie traditionelle Sicherheitsmaßnahmen umgehen. Eine kompromittierte Bibliothek passiert Code Reviews, passiert Tests, passiert Scanner — weil die Malware Teil einer „vertrauenswürdigen” Abhängigkeit ist.

Der EU Cyber Resilience Act (CRA), der 2027 in Kraft tritt, verlangt SBOM für alle Softwareprodukte, die auf dem europäischen Markt verkauft werden. Die Vorbereitung muss jetzt beginnen.

Was ist SBOM und warum brauchen Sie es¶

SBOM (Software Bill of Materials) ist eine vollständige Liste aller Komponenten, aus denen Ihre Software besteht — Bibliotheken, Frameworks, Tools, Versionen, Lizenzen. Stellen Sie es sich als Zutatenliste auf der Lebensmittelverpackung vor.

SBOM ermöglicht:

• Schnelle Reaktion auf CVEs: Wenn eine neue Schwachstelle auftaucht (wie Log4Shell), wissen Sie sofort, welche Anwendungen betroffen sind.
• Lizenz-Compliance: Automatische Erkennung von Lizenzkonflikten (GPL in einem kommerziellen Produkt).
• Vendor Risk Management: Transparenz über die Abhängigkeiten Ihrer Zulieferer.
• Regulatorische Compliance: NIS2, CRA, DORA — alle erfordern Kenntnis der Software-Zusammensetzung.

SBOM-Formate — SPDX vs CycloneDX¶

Zwei dominierende Formate im Jahr 2026:

• SPDX (Software Package Data Exchange): ISO/IEC 5962:2021-Standard. Stark in der Lizenz-Compliance. Unterstützt JSON, XML, YAML, RDF. Bevorzugt von NTIA und Bundesbehörden in den USA.
• CycloneDX: OWASP-Standard. Fokus auf Security — unterstützt VEX (Vulnerability Exploitability eXchange), Services, ML Model BOM. Leichtgewichtiges JSON/XML. Bevorzugt in der DevSecOps-Community.

Unsere Empfehlung: CycloneDX für security-orientierte Organisationen, SPDX für regulatorische Compliance und Lizenzmanagement. Tools können zwischen den Formaten konvertieren.

SBOM-Generierung in der CI/CD-Pipeline¶

SBOM muss bei jedem Build automatisch generiert werden. Manuelle Pflege ist unrealistisch. Bewährte Tools:

• Syft (Anchore): Generiert SBOM aus Container-Images, Dateisystemen, Archiven. Unterstützt sowohl SPDX als auch CycloneDX. Open-Source.
• Trivy (Aqua Security): Scanner + SBOM-Generator in einem. Exzellente Kubernetes-Integration.
• cdxgen: CycloneDX-Generator mit Unterstützung für 30+ Sprachen und Frameworks. Erkennt auch Erreichbarkeit — ob der anfällige Code tatsächlich aufgerufen wird.
• GitHub/GitLab nativ: Beide Plattformen bieten Dependency Graphs und SBOM-Export. Ein guter Startpunkt für kleinere Projekte.

Integration in die Pipeline sieht typischerweise so aus: Build -> SBOM-Generierung -> Schwachstellen-Scan -> SBOM-Signierung -> SBOM-Speicherung -> Deployment.

SLSA-Framework — Build-Integrität¶

SBOM sagt Ihnen „woraus Software besteht”. SLSA (Supply-chain Levels for Software Artifacts) sagt Ihnen „wie Software gebaut wurde” — und ob Sie dem Prozess vertrauen können.

SLSA definiert vier Stufen:

• Level 1: Dokumentation des Build-Prozesses — wer, wann, wie. Provenance-Metadaten.
• Level 2: Automatisierter Build + signierte Provenance. Gehosteter Build-Service (GitHub Actions, GitLab CI).
• Level 3: Gehärtete Build-Plattform — isolierte Builds, manipulationssichere Provenance. Reproduzierbare Builds.
• Level 4: Vier-Augen-Prinzip, hermetischer Build, volle Auditierbarkeit. Enterprise-Standard für kritische Software.

Die meisten tschechischen Unternehmen sind auf Level 0–1. Das Ziel für 2026 sollte mindestens Level 2 sein — automatisiertes CI/CD mit signierter Provenance.

Dependency Management Best Practices¶

SBOM und SLSA sind wichtig, aber Prävention ist besser als Erkennung:

• Lock Files überall: package-lock.json, Pipfile.lock, go.sum — exakte Versionen pinnen. Keine Floating Ranges in der Produktion.
• Privater Registry-Proxy: Artifactory oder Nexus als Proxy für npm, PyPI, Maven Central. Cached, scannt und blockiert problematische Pakete.
• Automatisierte Dependency-Updates: Dependabot oder Renovate mit automatischen PRs. Aber: Review vor dem Merge, niemals Auto-Merge für Major-Versionen.
• Scorecard-Check: OpenSSF Scorecard bewertet die Sicherheitspraktiken von Open-Source-Projekten. In den PR-Review integrieren — weist auf Abhängigkeiten mit schlechter Security-Hygiene hin.
• Sigstore / cosign: Signieren Sie eigene Artefakte (Container-Images, Binaries). Verifizieren Sie Signaturen beim Deployment.

VEX — Kontext für Schwachstellen¶

SBOM + Schwachstellen-Scan generiert Hunderte von Befunden. Die meisten sind False Positives oder nicht zutreffende Schwachstellen. VEX (Vulnerability Exploitability eXchange) fügt Kontext hinzu:

• Not Affected: Die anfällige Funktion wird in unserem Code nicht aufgerufen
• Affected: Wir sind betroffen, haben aber eine Mitigation
• Fixed: In der angegebenen Version behoben
• Under Investigation: Wir untersuchen

VEX reduziert die Alert-Müdigkeit drastisch und hilft Security-Teams, sich auf tatsächliche Bedrohungen zu konzentrieren.

Praktischer Fahrplan für Unternehmen¶

Einführung von Supply Chain Security Schritt für Schritt:

• Monate 1–2: Aktuellen Zustand auditieren. Abhängigkeiten inventarisieren. Lock Files einführen. Trivy/Syft in CI/CD deployen.
• Monate 3–4: SBOM-Generierung für alle Produktionsanwendungen. Zentrale SBOM-Speicherung (Dependency-Track). Schwachstellen-Alerting.
• Monate 5–6: SLSA Level 2 — signierte Provenance, automatisierte Builds. Privater Registry-Proxy. Scorecard-Integration.
• Fortlaufend: VEX-Prozess für Schwachstellen-Triage. Regelmäßige Lieferanten-Audits. Vorbereitung auf CRA-Compliance.

Supply Chain Security ist Teamarbeit¶

Der Schutz der Software Supply Chain ist nicht nur Sache des Security-Teams. Er erfordert Zusammenarbeit zwischen Entwicklern (Dependency Management), DevOps (CI/CD Hardening), Security (Vulnerability Management) und Management (Risk Governance).

Unser Tipp: Beginnen Sie damit, ein SBOM für eine kritische Anwendung zu generieren. Sie werden sehen, wie viele Abhängigkeiten Sie nicht einmal kannten. Das ist die beste Motivation zum Handeln.