Software Supply Chain Security: Warum SolarWinds jeden betreffen kann

SolarWinds (2020), Log4Shell (2021), XZ Utils (2024) - Supply-Chain-Angriffe haben bewiesen, dass selbst der beste Perimeter-Schutz versagt, wenn die Bedrohung aus vertrauenswürdiger Software kommt. Wer SolarWinds Orion installiert hatte, vertraute seinem Update - und installierte dabei einen russischen Geheimdienst-Backdoor.

Wie Supply-Chain-Angriffe funktionieren

1. Kompromittierter Software-Hersteller (SolarWinds, 2020)

Ablauf:

1. Angreifer (APT29/Cozy Bear) kompromittiert SolarWinds Build-System
2. Schädlicher Code in legitimes Update (Orion 2020.2) injiziert
3. 18.000 Unternehmen installieren das Update vertrauensvoll
4. Backdoor “SUNBURST”: 2 Wochen inaktiv → dann C2-Verbindung
5. Betroffene: US-Regierung, Microsoft, FireEye, Fortune 500

Warum so gefährlich:

• Kein Phishing, kein Exploit nötig
• Software hat legitime Signatur
• Firewall erlaubt Update-Traffic
• EDR erkennt signierte Software nicht als Malware

2. Open-Source-Package-Kompromittierung

event-stream (npm, 2018):

• Beliebtes NPM-Paket (2M Downloads/Woche)
• Entwickler übergab Paket an neuen Maintainer
• Neuer Maintainer injizierte Krypto-Wallet-Diebstahl-Code
• Aktiv für 6 Wochen bevor entdeckt

colors.js (npm, 2022):

• Entwickler sabotiert eigenes Paket (in Protest gegen Unternehmen)
• Bewusst kaputt gemacht, Endlos-Schleifen
• 22.000 Pakete abhängig davon!

3. Dependency Confusion Attack

Ablauf:

1. Unternehmen nutzt intern: mycompany-auth (private npm registry)
2. Angreifer findet internen Namen (Fehlerlog, git-history, etc.)
3. Angreifer veröffentlicht “mycompany-auth” in öffentlicher npm-Registry mit höherer Versionsnummer (2.0.0 statt intern 1.5.0)
4. npm/pip bevorzugt standardmäßig öffentliche Registry!
5. Build-System installiert Angreifer-Paket statt internes
6. Alle Entwickler und CI/CD-Pipeline betroffen

Echte Fälle 2021 (Alex Birsan):

• PayPal, Apple, Shopify, Tesla, Uber betroffen
• Bug Bounty: bis 30.000 USD pro Fund
• Jetzt Standard-Sicherheitsproblem

4. Typosquatting

• Angreifer registriert “requests” als “requets” (Tippfehler)
• “colourama” statt “colorama” (PyPI, 2017 - Krypto-Diebstahl!)
• Häufige Tippfehler gezielt ausnutzen
• Kann monatelang unentdeckt bleiben

SBOM - Software Bill of Materials

Was ist SBOM?

• Vollständige Zutatenliste aller Software-Komponenten
• Inkl. transitiver Abhängigkeiten (A benötigt B benötigt C)
• Formate: SPDX (ISO 5962), CycloneDX
• Ermöglicht: schnelle Reaktion auf neue CVEs (“Haben wir log4j?”)

Log4Shell ohne SBOM (Dezember 2021):

• Frage: “Nutzen wir log4j irgendwo?”
• Antwort ohne SBOM: Wochenlange manuelle Suche
• Antwort mit SBOM: grep "log4j" sbom.json → Antwort in Sekunden!

SBOM generieren

Syft (kostenlos, Anchore):

# Container Image:
syft myapp:latest -o cyclonedx-json > sbom.json

# Source Code:
syft dir:./src -o spdx-json > sbom-source.json

# .jar/.war Datei:
syft ./myapp.jar -o cyclonedx-json > sbom-jar.json

Grype (CVE-Scan gegen SBOM):

grype sbom:./sbom.json

Beispiel-Output:

NAME        INSTALLED  FIXED-IN  TYPE  VULNERABILITY   SEVERITY
log4j-core  2.14.1     2.17.1    java  CVE-2021-44228  Critical
spring-core 5.2.0      5.3.27    java  CVE-2023-20860  High

→ Sofortüberblick über alle vulnerablen Abhängigkeiten!

SBOM im CI/CD (GitHub Actions):

- name: Generate SBOM
  uses: anchore/sbom-action@v0
  with:
    image: myapp:latest
    format: cyclonedx-json
    output-file: sbom.json

- name: Scan SBOM for vulnerabilities
  uses: anchore/scan-action@v3
  with:
    sbom: sbom.json
    fail-build: true
    severity-cutoff: critical

SBOM-Pflichten

• US: Executive Order 14028 (2021): SBOM für US-Government-Software
• EU: Cyber Resilience Act (CRA): SBOM für vernetzte Produkte
• NIS2: impliziert Supply-Chain-Transparenz

SLSA - Supply-Chain Levels for Software Artifacts

Das SLSA-Framework (Google, 2021)

• “Salsa”: Supply chain Levels for Software Artifacts
• Sicherheitsrahmen für Build-Pipeline-Integrität
• 4 Levels (1 = minimal, 4 = Maximum)

Die vier SLSA-Level

SLSA Level 1:

• Build-Prozess ist dokumentiert und automatisiert
• Provenance: automatische Herkunfts-Metadaten generiert
• Wer hat gebaut, wann, aus welchem Source-Code?

SLSA Level 2:

• Versionskontrolle für Build-Skripte
• Signierter Provenance-Record
• Zwei-Personen-Review für alle Code-Änderungen

SLSA Level 3:

• Build-Umgebung ist isoliert und ephemer
• Kein Zugriff auf Production-Secrets im Build
• Provenance kryptographisch nicht fälschbar

SLSA Level 4:

• Zwei-Personen-Review obligatorisch
• Hermetischer Build: kein Internet-Zugriff während Build
• Reproduzierbarer Build: gleiches Ergebnis immer

Praktisch für KMU: SLSA Level 1 sofort erreichbar

• CI/CD für alle Deployments (kein manuelles rsync!)
• Jeder Build hat Commit-Hash in Artifact-Name
• Build-Logs aufbewahrt
• GitHub Actions/GitLab CI: automatische Provenance-Generierung

Praktische Schutzmaßnahmen

1. Dependency Confusion verhindern

npm (.npmrc):

@mycompany:registry=https://registry.npmjs.mycompany.com
always-auth=true
# → @mycompany/* Pakete IMMER von privater Registry!

pip (pip.conf):

[install]
extra-index-url = https://pypi.org/simple/
index-url = https://private.pypi.mycompany.com/simple/
# → Interne Pakete aus interner Registry, externe aus pypi.org

Maven (settings.xml):

• Verwende eigenen Mirror (Nexus/Artifactory) als Proxy
• Alle Dependencies gehen durch eigenen Artifact-Server
• Kann malicious packages blocken bevor sie ankommen

2. Dependency-Pinning

package-lock.json / yarn.lock / Pipfile.lock / Cargo.lock IMMER committen!

• Exakte Versionen festgelegt, kein “latest”
• Automatische Updates: Dependabot/Renovate Bot reviewen lassen

3. Package-Signatur-Verifikation

• npm: npm audit signatures (seit npm 9)
• pip: pip-audit + sigstore (Python Packaging Trust)
• Java: Maven Enforcer Plugin

4. Private Artifact-Registry (Nexus/Artifactory)

• Proxy für öffentliche Registries
• Manuell genehmigte Pakete
• Quarantäne für neue Pakete
• Automatischer CVE-Scan jeder Abhängigkeit

5. SBOM-basiertes Monitoring

• Wöchentlicher Grype-Scan gegen aktuelles SBOM
• Alert wenn neue CRITICAL-CVE in Abhängigkeit auftaucht
• Automatisches Ticket-Erstellen bei neuem High/Critical

6. Software-Hersteller bewerten

• Nutzt Hersteller 2FA/MFA für alle Entwickler?
• Signiert Hersteller seine Releases (GPG, Sigstore)?
• Hat Hersteller SBOM verfügbar?
• Gibt es Vulnerability Disclosure Policy?
• BSI-Warnungen zu diesem Hersteller prüfen?

Für KMU ohne Security-Engineer

• Dependabot (GitHub) aktivieren: kostenlos, automatisch
• npm audit / pip audit im CI: 15 Minuten Arbeit
• Container-Images: immer offiziell und aktuell (latest ≠ sicher!)
• Docker Trusted Registry für eigene Images

---

Supply-Chain-Angriffe sind schwer zu verhindern - aber ihre Auswirkungen lassen sich durch schnelle Erkennungs- und Reaktionsfähigkeit minimieren. AWARE7 hilft bei der Implementierung von DevSecOps-Pipelines und SBOM-Prozessen.

DevSecOps-Beratung anfragen | Penetrationstest Web-Applikationen