TL;DR

• Definition: SCA identifiziert automatisch Open-Source-Komponenten von Drittanbietern in Ihrer Software, um Schwachstellen und Lizenzverstöße zu erkennen.
• Das Risiko: Über 80 % moderner Anwendungen bestehen aus Open-Source-Code; Lieferketten-Angriffe (Supply Chain Attacks) zielen genau auf diese Abhängigkeiten ab.
• Das Gesetz: Der Cyber Resilience Act (CRA) und die NIS2-Richtlinie machen die Erstellung von SBOMs und das Tracking von Schwachstellen in der EU gesetzlich bindend.
• Die Lösung: "Shift-Left" durch die Integration von SCA-Tools in Ihre IDEs, Pull Requests und CI/CD-Pipelines.

Software Composition Analysis (SCA) sichert die 80 % Ihrer Codebasis ab, die Sie gar nicht selbst geschrieben haben. In der modernen Entwicklung schreiben wir Anwendungen selten von Grund auf neu – wir bauen sie aus bestehenden Bausteinen zusammen und verlassen uns massiv auf Open-Source-Bibliotheken.

Die meisten Entwicklerteams glauben immer noch, dass es ausreicht, den eigenen, proprietären Code mit traditionellen Sicherheitstools zu scannen. Die Daten zeigen jedoch ein anderes Bild: Die größte Bedrohung für Ihre Infrastruktur ist kein Tippfehler in Ihrer eigenen Geschäftslogik. Es ist das obskure, nicht mehr gepflegte npm- oder pip-Paket, das tief in Ihrem Abhängigkeitsbaum (Dependency Tree) verborgen liegt.

In diesem Guide klären wir, was genau SCA ist, warum weitreichende europäische Gesetze es mittlerweile unverzichtbar machen und wie Sie es technisch implementieren. Um zu zeigen, wie das in der Praxis aussieht, teile ich zudem einen maßgeschneiderten SBOM-Prozess-Checker, den ich kürzlich als Open Source veröffentlicht habe.

Was ist Software Composition Analysis (SCA)?

Software Composition Analysis (SCA) ist ein automatisierter Prozess, der die Open-Source-Komponenten, Bibliotheken und Abhängigkeiten innerhalb einer Codebasis identifiziert. Es erkennt bekannte Sicherheitslücken, Lizenzprobleme und veraltete Pakete und liefert ein umfassendes Inventar – die sogenannte Software Bill of Materials (SBOM) –, um die Software-Lieferkette abzusichern.

Wir lieben Open-Source-Software, weil sie die Entwicklung enorm beschleunigt. Man baut keinen eigenen Webserver und schreibt keine eigene Kryptographie-Bibliothek; man importiert sie. Doch diese Bequemlichkeit schafft einen massiven blinden Fleck. Wenn Sie eine Bibliothek importieren, importieren Sie auch den Code von hunderten Fremden – und all deren Fehler.

Deshalb muss sich die Sicherheit anpassen. Wenn an einem Freitagnachmittag eine kritische Schwachstelle wie Log4j bekannt wird, haben Sie Stunden, nicht Wochen, um zu reagieren. Ohne SCA sind Engineering-Teams gezwungen, in Panik Dutzende Repositories manuell zu durchsuchen, nur um eine einfache Frage zu beantworten: "Nutzen wir dieses Paket überhaupt?"

SCA beantwortet diese Frage sofort, indem es Ihren Dependency Tree mit globalen Schwachstellen-Datenbanken (wie der CVE-Liste) abgleicht.

Warum wird SCA im modernen SDLC unverzichtbar?

SCA ist entscheidend, weil moderne Anwendungen zusammengebaut und nicht von Grund auf neu geschrieben werden. Da Open-Source-Code den Großteil typischer Unternehmensanwendungen ausmacht, zielen Angreifer heute direkt auf die Lieferkette (Supply Chain). SCA bietet die nötige Transparenz, um Schwachstellen zu patchen, bevor sie in der Produktion ausgenutzt werden.

Jahrelang war Sicherheit ein nachträglicher Gedanke – die letzte Hürde vor dem Release. Doch die Bedrohungslandschaft hat sich komplett von direkten Perimeter-Angriffen hin zur Vergiftung der Lieferkette verlagert. Laut dem Synopsys Open Source Security and Risk Analysis (OSSRA) Report 2025 enthalten 96 % aller Unternehmens-Codebasen Open-Source-Komponenten, und über 80 % davon weisen mindestens eine bekannte Schwachstelle auf.

So hat sich der Fokus der Anwendungssicherheit verschoben:

Genau diese Unterscheidung ist die eigentliche Hürde. Sie können absolut fehlerfreien, sicheren Code schreiben – wenn Sie ihn jedoch zusammen mit einer anfälligen Version von React oder Spring Boot deployen, ist Ihre gesamte Umgebung kompromittiert.

Der rechtliche Hammer: CRA, NIS2 und der Compliance-Druck

Neue europäische Gesetze, insbesondere der Cyber Resilience Act (CRA) und die NIS2-Richtlinie, machen Softwarehersteller rechtlich haftbar für die Sicherheit ihrer Produkte. SCA und die automatisierte Generierung von SBOMs sind nicht länger nur Best Practices; sie sind strenge gesetzliche Voraussetzungen, um in der EU Geschäfte zu machen.

Bis vor kurzem operierte die Softwareindustrie nach einem "Zero-Liability"-Modell. Wenn die Software eines Anbieters aufgrund einer bekannten, ungepatchten Schwachstelle gehackt wurde, trug der Endkunde den Schaden. Diese Ära ist vorbei.

Der Cyber Resilience Act (CRA) der EU verändert die Wirtschaftlichkeit der Softwareentwicklung grundlegend. Er schreibt vor, dass jedes Produkt mit digitalen Elementen, das in der EU verkauft wird, "Secure by Design" sein muss. Konkret müssen Hersteller:

1. Alle Komponenten mithilfe einer SBOM (Softwarestückliste) dokumentieren.
2. Drittanbieter-Komponenten aktiv auf Schwachstellen überwachen.
3. Sicherheitsupdates für einen gesetzlich vorgeschriebenen Zeitraum bereitstellen.

Ebenso zwingt die NIS2-Richtlinie wesentliche und wichtige Einrichtungen, ihre Lieferketten abzusichern. Wenn Sie B2B-Software an ein Krankenhaus, eine Bank oder einen Energieversorger in Europa verkaufen, werden diese Ihre SCA-Prozesse auditieren. Wenn Sie keine korrekte SBOM vorweisen und nicht belegen können, dass Sie Abhängigkeiten scannen, verlieren Sie den Auftrag.

So integrieren Sie SCA in Ihren SDLC (Schritt-für-Schritt)

Die Integration von SCA in Ihren Software Development Life Cycle (SDLC) erfordert automatisierte Prüfungen auf mehreren Ebenen: in der IDE des Entwicklers, in der CI/CD-Pipeline und in der Produktions-Registry. Dieses kontinuierliche Scannen stellt sicher, dass Schwachstellen erkannt und blockiert werden, bevor der Code jemals deployt wird.

Der Fehler, den die meisten Teams machen, ist, SCA nur einmal im Monat als Audit durchzuführen. Bis eine Schwachstelle gefunden wird, ist der Code bereits in Produktion, und die Behebung erfordert einen teuren, ungeplanten Sprint.

Um dies zu beheben, müssen Sie den Prozess nach links verschieben ("Shift-Left") und SCA direkt in den Entwickler-Workflow einbetten:

1. IDE-Integration: Statten Sie Entwickler mit Plugins aus, die anfällige Pakete in dem Moment markieren, in dem sie in eine package.json oder pom.xml eingetippt werden.
2. Pull Request (PR) Checks: Konfigurieren Sie Ihren CI-Server (GitHub Actions, GitLab CI) so, dass jeder PR gescannt wird. Führt ein Entwickler eine kritische CVE ein, schlägt der Build automatisch fehl.
3. Kontinuierliche CI/CD-Generierung: Generieren und signieren Sie mit jedem erfolgreichen Release-Build ein frisches SBOM-Artefakt.
4. Registry & Runtime Scanning: Scannen Sie Ihre Container-Registries (z. B. Docker Hub, AWS ECR) kontinuierlich gegen neue Bedrohungsdaten, da ein gestern noch sicheres Paket morgen bereits eine Zero-Day-Schwachstelle aufweisen kann.

Praxisbeispiel: Eine maßgeschneiderte GitHub Actions Pipeline

Um Ihnen zu zeigen, wie das in der Praxis aussieht, finden Sie hier einen fortgeschrittenen GitHub Actions Workflow. Anstatt sich auf undurchsichtige "Black-Box"-Plugins zu verlassen, installiert diese Pipeline die Tools direkt, baut die Anwendung, generiert eine CycloneDX SBOM und nutzt ein benutzerdefiniertes Bash-Skript, um ein strenges Security-Gate durchzusetzen.

name: SCA Pipeline & SBOM Generation

on:
 pull_request:
   branches: [ "main" ]

jobs:
 security-gate:
   runs-on: ubuntu-latest
   steps:
     - name: Checkout Code
       uses: actions/checkout@v4

     - name: Install Syft
       run: |
         curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
         syft version

     - name: Install Grype
       run: |
         curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin
         grype version

     - name: Build Application
       run: |
         # Die Anwendung wird hier gebaut (z.B. Code kompilieren, Container bauen)
         # docker build -t my-app:latest .
         echo "Anwendung erfolgreich gebaut."
         mkdir -p artifacts

     - name: Generate SBOM
       run: |
         # Generiert eine CycloneDX JSON SBOM aus der Anwendung
         syft dir:. -o cyclonedx-json=artifacts/app.cdx.json

     - name: Scan with Grype
       run: |
         # Scannt die generierte SBOM direkt und gibt JSON aus
         grype "sbom:artifacts/app.cdx.json" -o json --file artifacts/app.grype.json

     - name: Fail gate (Critical or High findings)
       run: |
         set -euo pipefail
         # Parst den Grype Output via jq als Security Gate
         count="$(jq '[.matches[] | select(.vulnerability.severity == "Critical" or .vulnerability.severity == "High")] | length' artifacts/app.grype.json)"
         echo "Kritische/Hohe Funde: ${count}"
         
         if [ "${count}" -gt 0 ]; then
           echo "Security Gate fehlgeschlagen."
           exit 1
         fi
         echo "Pass: Keine kritischen oder hohen Schwachstellen gefunden."

     - name: Upload scan artifacts
       if: always()
       uses: actions/upload-artifact@v4
       with:
         name: security-scan-artifacts
         path: artifacts/


Warum genau diese Pipeline funktioniert:

• Scannen Sie das, was Sie ausliefern: Beachten Sie die Reihenfolge der Operationen. Die Anwendung wird gebaut, bevor die SBOM generiert wird. Indem Sie das finale Build-Artefakt scannen, spiegelt Ihre SBOM genau das wider, was in der Produktion laufen wird. Das eliminiert False Positives.
• Die Syft + Grype Synergie: Anstatt die Codebasis zweimal zu durchlaufen, generieren wir die CycloneDX SBOM mit Syft und übergeben dann genau diese Datei (sbom:artifacts/app.cdx.json) an Grype.
• Volle Kontrolle via jq: Integrierte Scanner-Flags (wie --fail-on) sind oft zu starr. Indem Sie die Scan-Ergebnisse als JSON ausgeben und eine einfache jq-Abfrage als Fail-Gate nutzen, erhalten Sie granulare Kontrolle darüber, was Ihren Build genau abbricht.

Das nächste Level: Die Validierung Ihres Prozesses

Sobald Sie diese grundlegende Pipeline am Laufen haben, SBOMs generieren und Schwachstellen blockieren, besteht die nächste Herausforderung darin sicherzustellen, dass die generierten Dateien auch im Laufe der Zeit strukturell konform bleiben.

Um diese Lücke zu schließen, habe ich ein Tool speziell für die Validierung dieser Outputs entwickelt. Sie finden das Repository hier: github.com/florianlenz96/sbom-process-check.

Ich habe es so konzipiert, dass es als leichtgewichtiges Gatekeeper-Tool in fortgeschrittenen Pipelines fungiert und sicherstellt, dass die Abhängigkeitsdaten audit-ready sind, bevor Sie ein Release freigeben.

Häufig gestellte Fragen (FAQ)

Was ist eine Software Bill of Materials (SBOM)?

Eine SBOM ist ein formales, maschinenlesbares Inventar, das alle Open-Source- und Drittanbieter-Komponenten, Bibliotheken und Abhängigkeiten detailliert auflistet, die zum Erstellen einer Softwareanwendung verwendet wurden. Stellen Sie sich das wie die Zutatenliste auf der Verpackung eines Lebensmittels vor, nur eben für Ihre Software.

Was ist der Unterschied zwischen SAST und SCA?

Static Application Security Testing (SAST) analysiert Ihren proprietären, selbst geschriebenen Quellcode auf Fehler wie SQL-Injection. Software Composition Analysis (SCA) scannt gezielt die Open-Source-Bibliotheken und Abhängigkeiten von Drittanbietern, die Sie importieren. Sie benötigen beides.

Gilt der Cyber Resilience Act (CRA) auch für Open-Source-Entwickler?

Rein nicht-kommerzielle Open-Source-Projekte sind in der Regel vom CRA ausgenommen. Sobald jedoch ein Open-Source-Projekt monetarisiert oder in ein kommerzielles Produkt integriert wird, wird die kommerzielle Entität, die es nutzt, rechtlich für dessen Sicherheit und Compliance verantwortlich.

Nächste Schritte und Implementierung

Die Absicherung Ihrer Software-Lieferkette ist kein theoretisches Konstrukt mehr – sie ist eine technische und rechtliche Notwendigkeit. Der Übergang von "blindem Vertrauen" hin zu einer kontinuierlichen Software Composition Analysis erfordert Arbeit, aber die Kosten, es zu ignorieren, sind weitaus höher.

Fangen Sie klein an. Implementieren Sie noch heute einen grundlegenden Dependency Scanner in Ihrer CI/CD-Pipeline und beginnen Sie mit der Generierung von SBOMs für Ihre wichtigsten Anwendungen unter Zuhilfenahme von Tools wie dem sbom-process-check Repo.

Über den Autor:

Florian Lenz ist freiberuflicher DevSecOps und Cloud Engineer / Architekt. Er ist darauf spezialisiert, sichere, skalierbare Infrastrukturen zu entwerfen und strenge Sicherheitspraktiken (wie SCA und SBOM-Generierung) direkt in moderne Entwicklungs-Workflows einzubetten, um die Einhaltung von Frameworks wie NIS2 und dem CRA zu gewährleisten.

Benötigen Sie Unterstützung bei der Umsetzung?

Die Transformation einer Legacy-Pipeline in einen sicheren, automatisierten und konformen SDLC ist komplex. Wenn Ihr Unternehmen Software Composition Analysis implementieren, CRA/NIS2-konforme SBOMs generieren oder seine Lieferketten absichern muss, können Sie mich für Consulting und die direkte technische Implementierung buchen. Lassen Sie uns Ihre Supply Chain gemeinsam absichern.

‍