SLSA Framework
Was ist SLSA Framework?
SLSA FrameworkSupply-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.
SLSA (gesprochen "Salsa") ist ein vom OpenSSF gehostetes Community-Framework, das Erzeuger und Konsumenten beim Nachdenken über die Integrität von Build-Pipelines unterstützt. Es definiert Build-Levels (aktuell L1-L3+), Anforderungen an Quelle und Abhängigkeiten und signierte Provenance, die beschreibt, was wie und aus welchen Eingaben gebaut wurde. Höhere Levels verlangen reproduzierbare Builds, hermetische Umgebungen, isolierte und kurzlebige Build-Plattformen sowie verifizierbare Provenance. SLSA ergänzt SBOMs (Komponentenlisten) und Frameworks wie NIST SSDF und CISA Secure by Design. Üblicherweise wird es mit Werkzeugen wie GitHub Actions Reusable Workflows, Tekton Chains, Sigstore Cosign und in-toto-Attestationen umgesetzt. SLSA wird zur Grundanforderung in regulierter und föderaler Beschaffung.
● Beispiele
- 01
Erreichen von SLSA Build Level 3 mittels GitHub Reusable Workflows und signierter Provenance.
- 02
Verifikation der SLSA-Provenance zur Deploy-Zeit als Teil der Admission Controls in Kubernetes.
● Häufige Fragen
Was ist 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. Es gehört zur Kategorie Anwendungssicherheit der Cybersicherheit.
Was bedeutet 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.
Wie funktioniert SLSA Framework?
SLSA (gesprochen "Salsa") ist ein vom OpenSSF gehostetes Community-Framework, das Erzeuger und Konsumenten beim Nachdenken über die Integrität von Build-Pipelines unterstützt. Es definiert Build-Levels (aktuell L1-L3+), Anforderungen an Quelle und Abhängigkeiten und signierte Provenance, die beschreibt, was wie und aus welchen Eingaben gebaut wurde. Höhere Levels verlangen reproduzierbare Builds, hermetische Umgebungen, isolierte und kurzlebige Build-Plattformen sowie verifizierbare Provenance. SLSA ergänzt SBOMs (Komponentenlisten) und Frameworks wie NIST SSDF und CISA Secure by Design. Üblicherweise wird es mit Werkzeugen wie GitHub Actions Reusable Workflows, Tekton Chains, Sigstore Cosign und in-toto-Attestationen umgesetzt. SLSA wird zur Grundanforderung in regulierter und föderaler Beschaffung.
Wie schützt man sich gegen SLSA Framework?
Schutzmaßnahmen gegen SLSA Framework kombinieren typischerweise technische Kontrollen und operative Praktiken, wie in der Definition oben beschrieben.
Welche anderen Bezeichnungen gibt es für SLSA Framework?
Übliche alternative Bezeichnungen: SLSA.
● Verwandte Begriffe
- appsec№ 1069
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.
- 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.
- appsec№ 522
in-toto
Offenes Framework, das jeden Schritt einer Software-Lieferkette kryptografisch attestiert, damit Konsumenten überprüfen können, dass das Artefakt genau wie vom Projektverantwortlichen vorgesehen erzeugt und behandelt wurde.
- 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№ 226
Cosign
Open-Source-CLI des Sigstore-Projekts zum Signieren, Verifizieren und Attestieren von OCI-Artefakten und anderer Software, wahlweise mit Schlüssel oder keyless.
- appsec№ 921
Reproduzierbare Builds
Build-Praktiken, die sicherstellen, dass das Übersetzen desselben Quellcodes mit denselben Anweisungen ein bitgleiches Artefakt erzeugt - unabhängig davon, wann und wo gebaut wird.
● Siehe auch
- № 1068Software Bill of Materials (SBOM)
- № 784Paketsignatur
- № 166CI/CD-Sicherheit