SCA – Software Composition Analysis

„Weil 90% deines Codes nicht von dir stammt – und das ist das Problem."

Sinn & Zweck

Du hast 5.000 Zeilen Code geschrieben. Glückwunsch! Deine Anwendung hat aber 500.000 Zeilen. Woher kommen die anderen 495.000? Von npm, Maven, PyPI und NuGet – aus Paketen, die irgendein Fremder vor Jahren geschrieben hat und seitdem nicht mehr angerührt hat.

SCA analysiert diese Third-Party-Dependencies und stellt unbequeme Fragen:

Welche Pakete nutzt du eigentlich?
Haben die bekannte Schwachstellen?
Unter welcher Lizenz stehen sie?
Wann wurden sie zuletzt aktualisiert? (Spoiler: Manchmal nie)

Techniken

Dependency Tree Analysis

SCA baut den kompletten Abhängigkeitsbaum:

your-app@1.0.0
├── express@4.18.2
│   ├── body-parser@1.20.0
│   │   └── raw-body@2.5.1
│   └── cookie-parser@1.4.6
└── lodash@4.17.21
    └── (keine deps, aber 3 CVEs)

CVE-Matching

Abgleich mit Vulnerability-Datenbanken:

NVD (National Vulnerability Database) – Der offizielle US-Katalog
GitHub Advisory Database – Community-kuratiert
Snyk Vulnerability DB – Commercial, oft schneller
OSV (Open Source Vulnerabilities) – Google's Beitrag

Lizenz-Scanning

MIT: ✓ (do whatever you want)
Apache-2.0: ✓ (aber mention it)
GPL-3.0: ⚠️ (dein Code wird auch GPL)
AGPL-3.0: 🚨 (SaaS-Killer)
WTFPL: ✓ (wirklich, das existiert)

Reachability Analysis

Fortgeschrittene Tools prüfen: "Ist die vulnerable Funktion überhaupt in deinem Code-Pfad?"

Methoden & Implementierung

Gängige Tools

Tool	Preis	Stärken	Schwächen
Snyk	Free/Pro	Schnell, gut integriert	Lock-in, manchmal False Positives
Dependabot	Free (GitHub)	Automatische PRs	Nur GitHub, kein Reporting
OWASP Dependency-Check	Free	Solide, Open Source	Langsam, viele False Positives
WhiteSource/Mend	Enterprise	Umfassend	Teuer, komplex
Sonatype Nexus IQ	Enterprise	Tiefe Analyse	Noch teurer
Trivy	Free	Container-fokussiert	Weniger Features
npm audit	Free	Eingebaut	Nur npm, oft veraltet

Pipeline-Integration

# GitHub Actions mit Snyk
- name: Run Snyk to check for vulnerabilities
  uses: snyk/actions/node@master
  with:
    args: --severity-threshold=high
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

# OWASP Dependency-Check CLI
dependency-check --project "MyApp" \
                 --scan ./package-lock.json \
                 --out ./reports

Manifeste, die SCA versteht

Ökosystem	Dateien
Node.js	package.json, package-lock.json, yarn.lock
Python	requirements.txt, Pipfile.lock, poetry.lock
Java	pom.xml, build.gradle
.NET	packages.config, *.csproj
Ruby	Gemfile, Gemfile.lock
Go	go.mod, go.sum
Rust	Cargo.toml, Cargo.lock

Risiken & Grenzen

Alert Fatigue

Snyk found 847 vulnerabilities in your project:
- 23 Critical
- 89 High  
- 312 Medium
- 423 Low

"Ich patche sie alle... nach meinem Urlaub... nächstes Jahr vielleicht."

Transitive Dependencies sind Wildcards

Du kontrollierst deine direkten Dependencies. Aber was ist mit deren Dependencies? Und deren Dependencies?

your-app → library-a → library-b → library-c (vulnerable!)

Update-Hölle

"Das Update von library-x auf Version 2.0 bricht library-y, die noch Version 1.x braucht."

Willkommen in der Dependency Hell.

False Positives durch Kontext-Ignoranz

Vulnerability in image-processing-lib? Dein Tool schlägt Alarm – obwohl du nur PDFs generierst und die betroffene Funktion nie aufrufst.

Nicht alles ist in Datenbanken

Neue Vulnerabilities (0-days)
Interne/private Pakete
Unmaintained Packages ohne CVE

Lizenz-Grauzone

Manche Pakete haben keine Lizenz. Manche haben mehrere. Manche haben Lizenzen, die niemand versteht. Juristen lieben das.

Vorteile

Transparenz über Supply Chain

Du weißt endlich, was in deiner Software steckt. Das allein ist Gold wert – für Audits, Compliance und das gute Gewissen.

Automatisierte Updates

Mit Dependabot & Co:

New Pull Request: Bump lodash from 4.17.19 to 4.17.21
- Fixes CVE-2021-23337: Prototype Pollution

Lizenz-Compliance

Bevor der GPL-Troll anklopft, weißt du Bescheid:

Welche Lizenzen nutzt du?
Sind sie kompatibel?
Musst du Source Code veröffentlichen?

Priorisierung durch CVSS

CVE-2021-44228 (Log4Shell): CVSS 10.0 – FIX NOW
CVE-2020-12345: CVSS 3.2 – Kann warten

SBOM-Generierung

Software Bill of Materials – wird zunehmend gesetzlich gefordert:

US Executive Order 14028
EU Cyber Resilience Act
BSI-Empfehlungen

Best Practices

Lock-Files committen – Ohne Lock-File ist jeder Build ein Abenteuer
Breaking Changes planen – Regelmäßige Dependency-Updates einplanen, nicht aufstauen
Allow-Lists definieren – Welche Lizenzen sind akzeptabel?
Policies definieren:
- Critical/High CVE → Build blockieren
- Medium → Warning
- Low → Info
Reachability-Analyse nutzen – Wenn das Tool es kann, priorisiere erreichbare Vulnerabilities
Private Registry nutzen – Für kontrollierte, geprüfte Pakete
Regelmäßig prüfen – Dependencies ändern sich nicht, aber CVE-Datenbanken schon

Der Log4Shell-Moment

Dezember 2021. Log4j. CVE-2021-44228. CVSS 10.0.

Millionen von Java-Anwendungen waren betroffen. Wer SCA hatte, wusste in Minuten, wo Log4j steckt. Wer nicht...

CEO: "Sind wir betroffen?"
Entwickler: "Ich... weiß es nicht?"
CEO: "..."

Dieses Event allein hat SCA vom "Nice-to-have" zum "Must-have" befördert.

SBOM – Das Inventar deiner Software

Was ist ein SBOM?

Eine maschinenlesbare Liste aller Komponenten deiner Software.

Formate

SPDX – Linux Foundation Standard
CycloneDX – OWASP Standard
SWID – ISO Standard

Beispiel (CycloneDX)

{
  "bomFormat": "CycloneDX",
  "components": [
    {
      "name": "lodash",
      "version": "4.17.21",
      "purl": "pkg:npm/lodash@4.17.21",
      "licenses": [{ "id": "MIT" }]
    }
  ]
}

Fazit

SCA ist keine Option mehr – es ist Pflicht. In einer Welt, in der 90% deines Codes von Fremden stammt und eine einzelne Vulnerability (hallo, Log4Shell) die halbe Welt lahmlegt, musst du wissen, was in deiner Software steckt.

Der gruseligste Satz in der Softwareentwicklung: "Keine Ahnung, wir haben das npm-Paket vor 5 Jahren mal installiert."

Weiterführende Ressourcen: