Compliance-Lexikon · Technik
Software Composition Analysis
[ˈsɒftweə ˌkɒmpəˈzɪʃn əˈnælɪsɪs] · auch: SCA, Dependency-Analyse, Open-Source-Analyse
Software Composition Analysis (SCA) bezeichnet die automatisierte Analyse der Software-Abhaengigkeiten einer Anwendung – Open-Source-Bibliotheken, Frameworks und Drittanbieter-Komponenten – auf bekannte Schwachstellen (CVEs) und Lizenzprobleme als Teil des DevSecOps-Prozesses.
Warum Software Composition Analysis ein Kern-Technikbegriff der IT-Compliance ist
Software Composition Analysis ist eine technische Sicherheitsmassnahme, die in allen wesentlichen Compliance-Frameworks als Anforderung oder Best Practice gelistet ist. ISO 27001, NIS-2 und DORA setzen Software Composition Analysis voraus – nicht als optionales Extra, sondern als Grundbestandteil eines wirksamen Sicherheitsprogramms. Im Audit wird geprüft, ob die Massnahme implementiert ist, ob sie wirksam konfiguriert ist und ob die Wirksamkeit nachgewiesen werden kann.
Wo Software Composition Analysis gefordert wird
| Framework | Referenz | Anforderung |
|---|---|---|
| CRA | Art. 13 | Cyber Resilience Act: Software-Bill-of-Materials und Schwachstellenmanagement fuer Softwareprodukte. |
| NIST SP 800-218 | vollständig | Secure Software Development Framework: SCA als Pflichtbestandteil. |
| ISO 27001:2022 | A.8.8 | Schwachstellenmanagement: SCA als Methodik fuer Software-Abhängigkeiten. |
| NIS-2 / BSIG | § 30 Abs. 2g | Lieferkettensicherheit: SCA als Instrument zur Absicherung der Software-Lieferkette. |
| OWASP | SBOM / Dependency-Check | OWASP Dependency-Check als weit verbreitetes Open-Source-SCA-Tool. |
BAM-Objektreferenz
Häufige Audit-Fehler
- Massnahme implementiert, aber Konfiguration nicht dokumentiert
- Wirksamkeit nicht regelmässig geprueft – Drift von der Baseline unbemerkt
- Abdeckung unvollständig – nicht alle relevanten Systeme einbezogen
- Kein Nachweis der Massnahmenwirksamkeit für den Auditor
Policy as Code: Technische Massnahmen als pruefbare Artefakte
Der Leitgedanke dieser Kategorie ist Policy as Code: Sicherheitsanforderungen werden nicht nur als Richtlinien dokumentiert, sondern als technische Konfigurationen implementiert, die automatisch pruefbar sind. Für Software Composition Analysis bedeutet das: Die Konfiguration ist versioniert, die Wirksamkeit wird kontinuierlich gemessen und die Ergebnisse werden als Evidence archiviert. Das macht den Abstand zwischen Richtlinie und Wirklichkeit sichtbar – und schliesst ihn systematisch.
Abdeckung und Ausnahmen
Vollständige Abdeckung aller relevanten Systeme ist der kritische Punkt: Eine Massnahme, die 95 Prozent der Systeme schutzt, hinterlasst fünf Prozent als Einstiegspunkte. Ausnahmen (Legacy-Systeme, OT, Testsysteme) muessen explizit dokumentiert und mit Kompensationsmassnahmen oder risikoakzeptierten Restrisiken versehen sein. Undokumentierte Ausnahmen sind im Audit stets ein Befund.
Nächste Ebene
Software Composition Analysis in der Praxis: Konfiguration, Abdeckung und Evidence
Was Auditoren bei Software Composition Analysis konkret pruefen und welche Evidence benoetigt wird.