Software-Supply-Chain-Sicherheit
Was ist Software-Supply-Chain-Sicherheit?
Software-Supply-Chain-SicherheitDisziplin zum Schutz jedes Glieds der Software-Produktion - Quellcode, Abhängigkeiten, Build, Signatur, Distribution und Deployment - gegen Manipulation, bösartigen Code und Integritätsverlust.
Software-Supply-Chain-Sicherheit behandelt Code als aus vielen Quellen zusammengesetztes Produkt statt als von Grund auf geschrieben. Sie umfasst Repository-Schutz, Entwickleridentitäten, sicheres CI/CD, kuratierte Abhängigkeiten, Erzeugung von SBOM und CBOM, Signatur und Verifikation (Sigstore, Cosign, in-toto), Provenance nach SLSA, Schwachstellen- und Secrets-Management sowie Policy-Durchsetzung beim Deployment. Die Disziplin entstand als Reaktion auf Vorfälle wie SolarWinds, Codecov, Log4Shell, XZ Utils und Dependency-Confusion-Kampagnen. Maßgebliche Frameworks sind SLSA, NIST SSDF (SP 800-218), CISA Secure by Design, die US-Executive Order 14028 und der EU Cyber Resilience Act - alle laufen auf signierte, verifizierbare und transparente Pipelines hinaus.
● Beispiele
- 01
End-to-End-signierte Pipeline mit SLSA-L3-Provenance und Cosign-verifizierten Deployments.
- 02
Kuratiertes internes Paket-Proxy mit SBOM-getriebener Schwachstellenreaktion.
● Häufige Fragen
Was ist Software-Supply-Chain-Sicherheit?
Disziplin zum Schutz jedes Glieds der Software-Produktion - Quellcode, Abhängigkeiten, Build, Signatur, Distribution und Deployment - gegen Manipulation, bösartigen Code und Integritätsverlust. Es gehört zur Kategorie Anwendungssicherheit der Cybersicherheit.
Was bedeutet Software-Supply-Chain-Sicherheit?
Disziplin zum Schutz jedes Glieds der Software-Produktion - Quellcode, Abhängigkeiten, Build, Signatur, Distribution und Deployment - gegen Manipulation, bösartigen Code und Integritätsverlust.
Wie funktioniert Software-Supply-Chain-Sicherheit?
Software-Supply-Chain-Sicherheit behandelt Code als aus vielen Quellen zusammengesetztes Produkt statt als von Grund auf geschrieben. Sie umfasst Repository-Schutz, Entwickleridentitäten, sicheres CI/CD, kuratierte Abhängigkeiten, Erzeugung von SBOM und CBOM, Signatur und Verifikation (Sigstore, Cosign, in-toto), Provenance nach SLSA, Schwachstellen- und Secrets-Management sowie Policy-Durchsetzung beim Deployment. Die Disziplin entstand als Reaktion auf Vorfälle wie SolarWinds, Codecov, Log4Shell, XZ Utils und Dependency-Confusion-Kampagnen. Maßgebliche Frameworks sind SLSA, NIST SSDF (SP 800-218), CISA Secure by Design, die US-Executive Order 14028 und der EU Cyber Resilience Act - alle laufen auf signierte, verifizierbare und transparente Pipelines hinaus.
Wie schützt man sich gegen Software-Supply-Chain-Sicherheit?
Schutzmaßnahmen gegen Software-Supply-Chain-Sicherheit kombinieren typischerweise technische Kontrollen und operative Praktiken, wie in der Definition oben beschrieben.
Welche anderen Bezeichnungen gibt es für Software-Supply-Chain-Sicherheit?
Übliche alternative Bezeichnungen: Software-Lieferkettensicherheit.
● Verwandte Begriffe
- attacks№ 1116
Supply-Chain-Angriff
Angriff, der einen vertrauenswürdigen Software-, Hardware- oder Dienstleister kompromittiert, um dessen nachgelagerte Kunden zu erreichen.
- appsec№ 1053
SLSA Framework
Supply-chain Levels for Software Artifacts: ein vom OpenSSF veröffentlichter stufenweiser Anforderungskatalog, der Erstellung, Signatur und Verifikation von Software gegen Lieferketten-Manipulation zunehmend härtet.
- appsec№ 1068
Software Bill of Materials (SBOM)
Formales, maschinenlesbares Verzeichnis der Komponenten, Bibliotheken und Abhängigkeiten einer Software einschließlich ihrer Versionen und Beziehungen.
- appsec№ 1044
Sigstore
Open-Source-Projekt der Linux Foundation, das Signatur, Verifikation und Schutz von Software-Artefakten mittels kurzlebiger Schlüssel, OIDC-Identitäten und Transparenz-Log einfach macht.
- appsec№ 166
CI/CD-Sicherheit
Kontrollen, die Continuous-Integration- und Continuous-Delivery-Pipelines vor Kompromittierung, Code-Injektion, Secret-Leakage und unautorisierten Deployments schützen.
- appsec№ 870
Provenance-Attestation
Signierte, maschinell verifizierbare Aussage darüber, wie ein Software-Artefakt entstanden ist - Quelle, Build-System, Parameter und Abhängigkeiten - damit Konsumenten dem Ursprung vertrauen können.
● Siehe auch
- № 245Cryptographic Bill of Materials (CBOM)
- № 226Cosign
- № 522in-toto
- № 304Dependency-Confusion-Angriff
- № 305Dependency Pinning
- № 784Paketsignatur
- № 921Reproduzierbare Builds
- № 444GitOps-Sicherheit