Software SupplyChain.
Software Supply Chain schützt den Weg von Quellcode, Abhängigkeiten und Build-Systemen bis zu Artefakten und Deployment. Sie verbindet Herkunft, Integrität, Secrets, Policies und Nachweis über die ausgelieferte Software.
Gezielt
einsetzen.
Herkunft und Integrität von Code, Abhängigkeiten, Builds und Auslieferungsartefakten kontrollieren.
Ein SBOM dokumentiert Komponenten. Es sichert weder Build-Pipelines noch Signaturen, Secrets oder den Zugriff auf Paketquellen ab.
Hersteller und
Werkzeuge.
| Hersteller und Produkt | Einordnung | Geeignet für | Vor Auswahl prüfen |
|---|---|---|---|
| GitHub · Advanced Security | Code, Secrets und Supply Chain | GitHub-Entwicklung | Actions, Provenance und Policy-Umfang |
| GitLab · Ultimate | DevSecOps und Supply Chain Security | GitLab-Plattformen | CI/CD-Architektur und Lizenz |
| Snyk · Snyk Open Source und SCM | Dependency und Code Security | Entwicklerteams und CI/CD | Governance über mehrere Repositories |
| JFrog · JFrog Xray | Artefakt- und Dependency Security | JFrog Artifactory Nutzer | Registry- und Build-Integration |
| Sonatype · Nexus Lifecycle | Software Supply Chain Management | Java- und Enterprise-Entwicklung | Policy, Repository und Entwicklerworkflow |
| Mend · Mend SCA | Open Source und Dependency Security | Grosses Portfolio von Anwendungen | Remediation-Automation prüfen |
| Checkmarx · Checkmarx One | Application Security Platform | SAST, SCA und Supply Chain | Integration in den Build-Prozess |
| Endor Labs · Endor Labs | Reachability und Dependency Lifecycle | Cloud-native Entwicklung | Sprachen und Build-Systeme |
| Anchore · Anchore Enterprise | SBOM und Container Supply Chain | Container- und Kubernetes-Umgebungen | Signaturen und CI Policy |
| Chainguard · Chainguard Enforce | Trusted Open Source und Artefakte | Container Supply Chain | Kompatibilität mit dem eigenen Artefaktfluss |
Herkunft prüfen,
Integrität erzwingen.
- Quellcodeverwaltung absichern: geschützte Hauptzweige, Pflicht-Review durch eine zweite Person und MFA für alle Konten mit Schreibrechten.
- Abhängigkeiten nur über ein internes Paketregister beziehen, Versionen mit Prüfsummen fixieren und neue Pakete vor der ersten Nutzung prüfen.
- Builds in isolierten, kurzlebigen Umgebungen ausführen; Zugangsdaten der Pipeline zeitlich begrenzen und je Projekt trennen.
- Artefakte signieren, Herkunftsnachweise (Provenance) erzeugen und beides vor dem Deployment automatisch prüfen; unsignierte Artefakte werden abgewiesen.
- Anteil produktiver Artefakte mit gültiger Signatur und Herkunftsnachweis
- Anteil Abhängigkeiten, die über das interne Paketregister bezogen werden
- Anzahl Pipelines mit langlebigen oder projektübergreifenden Zugangsdaten
Das Plattform- oder DevOps-Team verantwortet Pipeline, Register und Signaturinfrastruktur. Produktteams verantworten ihre Abhängigkeiten, Security definiert Mindestanforderungen und prüft deren Einhaltung.
ISO/IEC 27001:2022 Annex A 5.21 (IKT-Lieferkette), 8.4 (Zugriff auf Quellcode), 8.25 (sicherer Entwicklungslebenszyklus) und 8.32 (Änderungsmanagement); NIS2 Art. 21 Abs. 2 lit. d und e nennt Sicherheit der Lieferkette sowie sichere Entwicklung und Wartung.
Der Cyber Resilience Act verlangt von Herstellern ab 11.12.2027 unter anderem eine SBOM (Anhang I Teil II Nr. 1); NIST SP 800-218 (SSDF) und das SLSA-Framework beschreiben überprüfbare Anforderungen an Build und Herkunft.
Eine Signatur belegt nicht, dass der Code vertrauenswürdig ist. Sie zeigt nur, dass das Artefakt seit dem Signieren unverändert ist und welcher Schlüssel signiert hat; ist die Pipeline kompromittiert, wird auch manipulierter Code korrekt signiert.
Nachweis statt
Versprechen.
- Build-Systeme, Paketquellen, Artefaktregister und Signaturen im Ablauf abgrenzen.
- Manipulierte Abhängigkeit oder kompromittierten Build als Übung testen.
- Provenance und SBOM mit Release und Verantwortlichkeit verbinden.
SBOM und VEX · Dependency Monitoring · Secrets Management
Produktfunktionen sind Herstellerangaben. Die Eignung zeigt erst ein kontrollierter Test im eigenen Scope.
Security Tool Navigator · Gebiet 12
Im Gebiet Third Party und Supply Chain einordnen.
Diese Werkzeugklasse gehört zum Gebiet Third Party und Supply Chain. Der Gebietshub zeigt, wie die Werkzeugklassen zusammenwirken, wo sie sich abgrenzen und welche Fragen CIO und CISO jeweils klären.