Software Supply Chain Security: Zentrale Risiken und wirksame Schutzmaßnahmen

Was ist Software Supply Chain Security?

Software Supply Chain Security umfasst Maßnahmen, die alle Komponenten schützen, mit denen Software erstellt und ausgeliefert wird: den Quellcode, Drittanbieter-Bibliotheken, CI/CD-Pipelines und die Deployment-Infrastruktur. Diese Maßnahmen stellen sicher, dass Code und Systeme sicher und unverändert bleiben, bevor sie in die Produktion gelangen.

Sicherheit hat hohe Priorität, weil moderne Software stark auf ein Geflecht externer dependencies und Werkzeuge angewiesen ist. Diese Komplexität schafft mehr Einfallstore für Angreifer. Sicherheitsvorfälle wie SolarWinds und MOVEit zeigen deutlich, wie ein Angriff auf die Lieferkette tiefen und schädlichen Zugriff ermöglicht.

Angesichts des katastrophalen Potenzials solcher Angriffe fordern Regulierungsbehörden inzwischen strengere Kontrollen. In den USA definieren etwa die Executive Order 14028 und das Secure Software Development Framework (SSDF) des NIST Anforderungen an Zulieferer des Bundes, ihre Software-Lieferketten abzusichern.

Diese wachsenden Sicherheits- und Compliance-Anforderungen erfordern volle Transparenz über die gesamte Software-Lieferkette sowie die Fähigkeit, Risiken früh zu erkennen und zu begrenzen. Beide Fähigkeiten sind für Schutz und Compliance gleichermaßen entscheidend.

Komponenten der Software-Lieferkette, die strikte Sicherheit erfordern

Die moderne Software-Lieferkette besteht aus vielen miteinander verbundenen Teilen. Jedes davon spielt eine entscheidende Rolle bei der Auslieferung sicherer Anwendungen, und jedes bringt eigene Risiken mit sich.

Die folgenden zentralen Komponenten müssen Teams absichern, um ihre Entwicklungs-Pipeline durchgängig zu schützen.

Quellcode und Versionsverwaltung

Der Quellcode bildet die Grundlage jeder Anwendung. Entwickler verwalten ihn in der Regel mit Versionsverwaltungssystemen wie GitHub oder GitLab. Nutzen Angreifer Schwachstellen aus, etwa kompromittierte Personal Access Tokens (PATs), ungeschützte Branches oder fehlende Pflicht zum Code Review, können sie die Anwendungslogik verändern, Hintertüren einbauen oder geschützte Daten abgreifen.

Um die Integrität des Codes zu wahren, erzwingen Teams das Signieren von Commits, setzen Branch-Protection-Regeln ein, verlangen Reviews vor jedem Merge und begrenzen die Reichweite von PATs sowie die Zugriffsrechte streng.

Dependencies und Drittanbieter-Bibliotheken

Um die Entwicklung zu beschleunigen, verlassen sich Teams häufig stark auf Open-Source-Pakete und externe Bibliotheken. Diese Komponenten liefern leistungsfähige Funktionen, bergen aber auch Risiken, vor allem wenn Angreifer die Software-Lieferkette vergiften.

Ein aktuelles Beispiel ist die von Wiz Research aufgedeckte Kampagne Shai-Hulud 2.0. Angreifer luden schädliche Pakete in öffentliche Repositories hoch und warteten darauf, dass ahnungslose Entwickler sie in ihre Builds aufnahmen. Diese mit Hintertüren versehenen Pakete konnten Zugangsdaten abziehen, dauerhaften Zugriff einrichten oder nachgelagerte Systeme kompromittieren. Das zeigt, wie gefährlich ungeprüfte dependencies sein können.

Zur Abwehr solcher Bedrohungen sollte ein Team eine automatisierte Prüfung der dependencies, verbindliche Lockfiles und kontinuierliche Überwachung über alle Paketquellen hinweg einführen.

Pipelines und CI/CD-Werkzeuge

CI/CD-Pipelines treiben die moderne Softwareauslieferung an und automatisieren alles von der Code-Integration bis zum Deployment. Weil sie im Zentrum dieses Prozesses stehen, sind sie ein lohnendes Ziel: Oft verwahren sie secrets, Zugangsdaten und Zugriff auf Produktionsumgebungen.

Werkzeuge wie Jenkins, Travis CI und GitHub Actions vereinfachen Builds, führen bei Fehlkonfiguration aber ebenfalls zu Risiken. Zu den häufigen Schwachstellen zählen nicht fixierte Actions, die sich kapern lassen, das Einschleusen nicht vertrauenswürdiger Skripte, fest im Code hinterlegte oder abgeflossene secrets sowie die unsichere Ablage von Artefakten oder Logs. Nutzen Angreifer diese Lücken aus, betten sie Schadcode ein, umgehen Kontrollen oder springen auf andere Systeme über.

Um die Angriffsfläche zu reduzieren, härten Teams ihre Pipelines mit dem Prinzip der geringsten Berechtigung, erzwingen das Fixieren von Actions und die Prüfung von Checksummen, scannen nach offengelegten secrets und trennen Build-Umgebungen von der Produktion.

Artefakt-Registries und Paketverteilung

Nach dem Build werden Software-Artefakte in Registries wie Docker Hub, npm oder PyPI gespeichert und verteilt. Diese Systeme machen das Deployment effizient, werden dadurch aber auch zu lohnenden Zielen. Vergiften Angreifer ein Paket oder geben sich als vertrauenswürdige Komponente aus, erreicht kompromittierte Software schlagartig Tausende Systeme. Damit nur vertrauenswürdige Artefakte in die Umgebungen gelangen, sind sichere Veröffentlichungspraktiken entscheidend. Zu den wichtigsten Kontrollen gehören das Signieren von Paketen, durchgesetzte Zugriffsrechte, eine gepflegte Herkunftskette, das Scannen auf Schadsoftware und die Prüfung während Build und Deployment.

Deployment- und Update-Mechanismen

Teams stellen moderne Anwendungen über Containerisierung und Orchestrierungsplattformen wie Docker und Kubernetes bereit, die Auslieferung und Skalierung beschleunigen. Ungesichert werden dieselben Mechanismen jedoch zu Angriffsvektoren. Jedes Update bringt neuen Code ein, und wenn Angreifer ein Image, eine Registry oder den Update-Prozess kompromittieren, schleusen sie schädliche Komponenten direkt in die Produktion. Um das zu verhindern, prüfen Teams die Herkunft von Updates, erzwingen das Signieren von Images und scannen Container vor dem Deployment auf Schwachstellen und Manipulation.

Anbieter und Drittanbieter-Dienste

Teams setzen auf externe Anbieter, APIs und Cloud-Dienste, um Anwendungen schneller zu entwickeln und zu betreiben. Jede Drittanbieter-Integration vergrößert jedoch die Angriffsfläche. Wird ein Anbieter kompromittiert oder ist er fehlkonfiguriert, nutzen Angreifer diesen Zugang, um Systeme oder Daten zu kompromittieren. Um dieses Risiko zu steuern, weisen Organisationen klare Zuständigkeiten zu, prüfen Anbieter regelmäßig auf Sicherheitslücken und verankern vertragliche Anforderungen an data protection, Zugriffsrechte und Meldepflichten bei Vorfällen.

Bedrohungen und Risiken für die Software-Lieferkette

Die Software-Lieferkette bildet durch ihre Komplexität, ihren Umfang und ihr Geflecht verbundener Komponenten eine attraktive Angriffsfläche. Sowohl externe Akteure als auch interne Schwächen führen zu ernsten Risiken. Wer diese Bedrohungen versteht, priorisiert Schutzmaßnahmen gezielt und reduziert die Angriffsfläche. Im Folgenden stehen die verschiedenen Bedrohungen und Risiken, die in einer multi-cloud-Umgebung häufig auftreten.

Externe Bedrohungen und Risiken

Externe Bedrohungen zielen auf die öffentlich erreichbaren oder von Dritten bereitgestellten Elemente der Entwicklungs-Pipeline. Dazu gehören vergiftete Updates, schädliche dependencies und man in the middle-Angriffe, die Lücken in der Prüfung oder der Transportsicherheit ausnutzen.

Interne Bedrohungen und Risiken

Interne Bedrohungen entstehen innerhalb der Organisation oder über vertrauenswürdige Systeme. Dazu zählen Insider-Risiken, Fehlkonfigurationen und der Missbrauch von Zugangsdaten. Schon ein einziges kompromittiertes Entwicklerkonto untergräbt die gesamte Pipeline.

Beispiele aus der Praxis für Angriffe auf die Software-Lieferkette

Jeder der folgenden Fälle zeigt, wie Lücken in der Isolation, der Prüfung oder der Konfiguration weitreichende Angriffe ermöglichen.

Hugging Face und Forscher finden ein schädliches KI-Modell

Im Jahr 2024 arbeitete Wiz Research mit Hugging Face zusammen und deckte ein kritisches Sicherheitsrisiko in dessen Inference API auf. Angreifer konnten diese Lücke ausnutzen, um ein schädliches KI-Modell hochzuladen, das remote code execution (RCE) und mandantenübergreifenden Zugriff ermöglichte. Da das KI-Modell nicht in einer isolierten Umgebung lief, konnte ein Angreifer auf private Kundendaten und sensible Modelle anderer Mandanten zugreifen.

Die Forscher von Wiz stellten außerdem eine schwache Mandantentrennung in der zugrunde liegenden Kubernetes-Infrastruktur fest. Diese Lücke ermöglichte privilege escalation und lateral movement in der gesamten Umgebung. Zusätzlich wies der Dienst Spaces Lücken in der Sicherheit seiner container registry auf, über die Angreifer Container und Infrastruktur in großem Umfang hätten manipulieren können.

• Was versagte: eine unzureichende Isolation zwischen Mandanten und die fehlende Validierung von Containern;

• Wie es ausgenutzt wurde: das Hochladen schädlicher Modelle löste remote code execution und mandantenübergreifenden Zugriff aus;

• Was geholfen hätte: strenge Mandantengrenzen, ein robusteres Scannen von Containern und Kontrollen zur Modellvalidierung vor der Ausführung.

Nach diesen Erkenntnissen handelte Hugging Face rasch, verstärkte die Mandantentrennung, erweiterte das vulnerability scanning und härtete die Container-Umgebungen.

Wiz deckt #IngressNightmare auf

Wiz Research deckte eine schwere, nicht authentifizierte remote code execution-Schwachstelle im Ingress-NGINX-Controller für Kubernetes auf, heute bekannt als #IngressNightmare. Das Problem entstand durch unsichere Logik im Webhook des admission controllers, über die Angreifer die Authentifizierung umgingen und Zugriff auf Kubernetes-Cluster erlangten.

Die Schwachstelle betraf rund 43 % der Cloud-Umgebungen und über 6.500 im Internet exponierte Cluster. Angreifer konnten diesen Weg nutzen, um Privilegien auszuweiten und über mehrere namespaces hinweg auf secrets zuzugreifen. Das bedrohte die zentrale Infrastruktur und die Anwendungsebenen.

• Was versagte: eine unsichere Eingabeprüfung im admission controller und uneingeschränkter Zugriff auf die Webhook-Endpunkte;

• Wie es ausgenutzt wurde: Angreifer sendeten präparierte Anfragen, um remote code execution ohne Authentifizierung auszulösen;

• Was geholfen hätte: das Absichern des Webhooks mit Netzwerkrichtlinien, das Einschränken seiner Erreichbarkeit und strenge admission controllers.

Wiz stellte rasch Erkennungsfunktionen bereit, um exponierte Cluster zu identifizieren und in real-time zu alarmieren. Betroffene Organisationen behoben das Problem, indem sie NGINX aktualisierten, den Zugriff auf den Webhook einschränkten und strengere Kubernetes-Netzwerkrichtlinien anwendeten.

Der Shai-Hulud 2.0-Angriff auf die Lieferkette (im Detail)

Der von Wiz Research aufgedeckte Shai-Hulud 2.0-Angriff auf die Lieferkette zählt zu den bislang umfangreichsten Kompromittierungen über npm. Die Bedrohungsakteure versahen fast 700 npm-Pakete mit Trojanern und betrafen damit über 25.000 GitHub-Repositories bei Hunderten von Nutzern.

Diese Pakete zogen während der Preinstall-Phase secrets aus CI/CD-Pipelines und Entwicklerrechnern ab und ermöglichten so groß angelegten Diebstahl von Zugangsdaten sowie dauerhafte Hintertüren. Die Schadsoftware nutzte GitHub-Workflows, um unentdeckt zu bleiben und Daten über mehrere Opfer hinweg offenzulegen; im Visier standen secrets aus AWS-, Azure- und GCP-Umgebungen.

• Was versagte: kompromittierte Zugangsdaten von Maintainern erlaubten es Angreifern, mit Trojanern versehene npm-Pakete samt schädlicher Preinstall-Skripte zu veröffentlichen;

• Wie es ausgenutzt wurde: das Installieren dieser Pakete löste Diebstahl von Zugangsdaten, das Abziehen von secrets und Persistenz über GitHub Actions aus;

• Was geholfen hätte: Lifecycle-Skripte standardmäßig zu blockieren, eng begrenzte Tokens zu erzwingen und Pakete vor der Installation streng zu prüfen.

Diese Kampagne unterstreicht den wachsenden Bedarf an automatisierter Prüfung der dependencies, gehärteten Build-Systemen und Überwachung in real-time, um Software-Pipelines zu schützen.

Best Practices zur Minderung von Risiken in der Lieferkette

Der Schutz der Software-Lieferkette erfordert einen mehrstufigen Ansatz. Von der Entwicklung bis zum Deployment verlangt jede Phase Kontrollen, die die Angriffsfläche reduzieren und eine schnelle Reaktion ermöglichen.

Im Folgenden stehen zwölf zentrale Best Practices, um die Abwehr proaktiv zu stärken und langfristige Widerstandsfähigkeit aufzubauen.

1. Ein software bill of materials mit Sicherheitsaspekten erstellen

Transparenz ist die Grundlage der Software Supply Chain Security. Ein vollständiges, aktuelles software bill of materials (SBOM) gibt detaillierten Einblick in alle Komponenten der Codebasis, einschließlich direkter und transitiver dependencies, Open-Source-Paketen und proprietärer Module.

Für Interoperabilität und Compliance entsteht das SBOM in standardisierten Formaten wie SPDX oder CycloneDX. Diese Formate werden breit unterstützt und lassen sich mit Audit-Werkzeugen, Compliance-Plattformen und Bewertungen durch Dritte verbinden. Das SBOM enthält Metadaten zu jeder Komponente, etwa Version, Herkunft und Lizenz, und wird laufend aktualisiert, sobald sich der Code ändert.

Plattformen wie Wiz automatisieren die Erstellung des SBOM in cloud-native-Umgebungen mit agentless-Scans. Das senkt den manuellen Betriebsaufwand und hält den Bestand zugleich exakt.

Warum das wichtig ist: So bleibt das Sicherheitsteam an sich wandelnden Standards wie der Executive Order 14028 und dem SSDF des NIST ausgerichtet, während sich Entwickler auf die Auslieferung konzentrieren.

2. DevOps und DevSecOps nutzen

Sicherheit lässt sich früh in den Entwicklungsprozess verlagern, indem sie direkt in die Pipeline eingebettet wird. Das bedeutet, sowohl den eigenen Code als auch die dependencies zu scannen, wobei jeder Bereich einen eigenen Ansatz verlangt.

Um den Code auf Logikfehler, unsichere Muster und Fehlkonfigurationen zu prüfen, kommen SAST-Werkzeuge wie SonarQube oder Checkmarx zum Einsatz. Für dependencies prüfen SCA-Werkzeuge Drittanbieter-Pakete und -Bibliotheken auf bekannte Schwachstellen, veraltete Versionen und Lizenzrisiken.

Ein DevSecOps-Modell verbindet beide Ansätze in den CI/CD-Workflows und bringt Sicherheits-, Entwicklungs- und Betriebsteams zusammen. Diese gemeinsame Verantwortung fördert eine frühere Erkennung von Problemen und eine schnellere Behebung, ohne die Auslieferung zu verlangsamen.

Warum das wichtig ist: Wer Probleme früh erkennt, begrenzt das Risiko, reduziert Nacharbeit und verhindert, dass Schwachstellen in die Produktion gelangen. Das spart Zeit, senkt Kosten und schützt die Reputation.

3. Regelmäßige Audits durchführen

Audits decken auf, was die Automatisierung übersieht. Sinnvoll sind planmäßige Bewertungen der Code-dependencies, der Cloud-Konfigurationen und der Infrastruktur. Werkzeuge wie OWASP Dependency-Check und AWS Config helfen dabei, Fehlkonfigurationen und veraltete Bibliotheken zu erkennen. Die folgende Übersicht zeigt, wie.

Warum das wichtig ist: Regelmäßige Audits legen die blinden Flecken offen, die automatisierte Werkzeuge übersehen, und halten die Sicherheitslage mit neuen Bedrohungen, Infrastrukturänderungen und Compliance-Vorgaben Schritt.

4. Multi-Faktor-Authentifizierung einführen und das Prinzip der geringsten Berechtigung durchsetzen

Zugriffskontrollen zählen auf jeder Ebene. Zum Schutz des Zugriffs aktivieren Teams MFA auf allen Entwicklerwerkzeugen und Cloud-Diensten. Zusätzlich setzen sie das Prinzip der geringsten Berechtigung über Repositories und CI/CD-Systeme hinweg durch, damit Nutzer nur genau die Rechte erhalten, die ihre Rolle erfordert.

Warum das wichtig ist: MFA und das Prinzip der geringsten Berechtigung verhindern, dass Angreifer über kompromittierte Konten ihre Zugriffe ausweiten.

5. Software composition analysis durchführen

Werkzeuge für software composition analysis (SCA) scannen Drittanbieter-Bibliotheken auf bekannte Probleme. In die Pipeline integriert, erkennen sie veraltete oder verwundbare Pakete automatisch. Diese Praxis ist in cloud-native-Umgebungen entscheidend, in denen Codebasen stark auf Open-Source-Komponenten setzen.

Warum das wichtig ist: SCA schützt proaktiv vor externen Risiken, die durch dependencies entstehen.

6. Eine Lösung für kontinuierliche Überwachung wählen

Sicherheit endet nicht mit dem Deployment. Kontinuierliche Überwachung ist nötig, um aktive Bedrohungen zu erkennen. Werkzeuge wie AWS CloudWatch, Azure Sentinel oder Wiz verfolgen workloads, Konfigurationen und Aktivitäten in den Cloud-Umgebungen in real-time. Diese Lösungen schaffen Transparenz über Probleme und ermöglichen eine schnelle Erkennung und Reaktion, bevor eine Eskalation eintritt.

Warum das wichtig ist: Was unsichtbar bleibt, lässt sich nicht beheben. Kontinuierliche Überwachung sorgt dafür, dass keine Bedrohung übersehen wird.

7. Code-Signierung und Manipulationserkennung durchsetzen

Die Software-Lieferkette lässt sich absichern, indem jeder Build und jedes Artefakt mit kryptografischen Schlüsseln signiert wird. Zusätzlich prüfen Teams diese Signaturen beim Deployment und erkennen mit Checksummen jede unerwartete Änderung. Diese Schutzmaßnahmen stellen sicher, dass nur vertrauenswürdiger, geprüfter Code in die Produktion gelangt.

Warum das wichtig ist: Diese Vorgaben verhindern unbefugte Änderungen vor dem Deployment und schützen die Umgebung vor manipuliertem oder schädlichem Code.

8. Build-Infrastruktur und CI/CD-Systeme absichern

Die Pipeline ist ein lohnendes Ziel. Teams härten Build-Umgebungen mit strengen Zugriffsrichtlinien, der Verwaltung von secrets und Netzwerksegmentierung. Teams überwachen diese Systeme auf Anomalien, die auf eine Kompromittierung hindeuten.

Warum das wichtig ist: Ein kompromittiertes CI/CD-System öffnet Angreifern einen direkten Weg in die Produktion.

9. Anbieterrisiken steuern

Drittanbieter-Dienste bringen Risiken mit, die sich nicht direkt kontrollieren lassen. Teams bewerten die Sicherheitslage jedes Anbieters, seine Bereitschaft zur incident response und seine bisherige Bilanz. Zusätzlich prüfen und erneuern sie diese Bewertungen regelmäßig, um Compliance und Vertrauen zu erhalten.

Warum das wichtig ist: Die eigene Sicherheit ist nur so stark wie das schwächste Glied in der Lieferkette.

10. Einen Plan für die incident response erstellen

Kompromittierungen der Lieferkette betreffen oft vertrauenswürdige Komponenten, wodurch sie schwerer zu erkennen und langsamer einzudämmen sind. Deshalb enthält ein Plan für die incident response gezielte Playbooks für Bedrohungen der Software-Lieferkette.

Der Plan definiert Verfahren, um manipulierte Artefakte, kompromittierte Registries, schädliche dependencies oder Eingriffe in Build-Systeme zu erkennen. Er beschreibt, wie sich kompromittierte Pakete zurückziehen, Anbieter benachrichtigen, SBOMs aktualisieren und die Build-Integrität über Umgebungen hinweg prüfen lassen. Ebenso wichtig: simulierte Szenarien eines Lieferketten-Vorfalls prüfen die Abstimmung des Teams über Sicherheit, Entwicklung und externe Kontakte hinweg.

Warum das wichtig ist: Anders als klassische Vorfälle breiten sich Angriffe auf die Lieferkette oft unbemerkt in nachgelagerte Systeme aus. Ein zugeschnittener Plan für die incident response ermöglicht ein schnelles Eindämmen der Auswirkungen und stellt Vertrauen wieder her.

11. Netzwerksegmentierung einsetzen

Umgebungen wie Entwicklung, Staging und Produktion lassen sich voneinander isolieren, um Risiken zu senken und die seitliche Ausbreitung von Bedrohungen im Netzwerk zu begrenzen. micro-segmentation und zero trust-Prinzipien steuern den Zugriff fein abgestuft.

Warum das wichtig ist: Eindämmung reduziert den Blast Radius, wenn ein Angreifer oder eine Fehlkonfiguration einen Teil des Systems kompromittiert.

12. Regelmäßige Backups einplanen

Sichern lassen sich nicht nur Daten, sondern auch Software-Artefakte, Konfigurationen und Metadaten. cloud-native-Lösungen wie AWS Backup oder Azure Backup sowie regelmäßig getestete Wiederherstellungsverfahren sichern die Geschäftskontinuität.

Warum das wichtig ist: Eine schnelle Wiederherstellung minimiert Ausfallzeiten und hält den Betrieb bei Vorfällen aufrecht.

So bleibt die Software-Lieferkette geschützt

Der Schutz der Software-Lieferkette ist längst keine Option mehr. Da moderne Anwendungen stark auf Open-Source-Komponenten, Drittanbieter-Dienste und verteilte Infrastruktur setzen, stehen Organisationen kumulierenden Risiken durch externe Angreifer und interne Schwächen gegenüber. Vorausschauende Teams priorisieren daher nicht nur Erkennung und Reaktion, sondern auch Prävention, Governance und Nachweisbarkeit.

Die folgenden Strategien bauen eine widerstandsfähige Abwehr auf.

Etablierte Frameworks nutzen

Klar definierte Branchen-Frameworks bilden die Grundlage einer starken Strategie für die Sicherheit der Lieferkette. Die folgenden Standards strukturieren den Umgang mit der Erkennung, Minderung und Governance von Risiken.

Der Einsatz dieser Frameworks verbessert die Risikolage, vereinfacht Compliance und stärkt das Vertrauen bei Kunden und Stakeholdern. Entscheidend ist, dass sie den Weg zur automatisierten Durchsetzung ebnen, sobald sie mit Werkzeugen wie Wiz kombiniert werden. Wiz hilft Teams, richtliniengesteuerte Kontrollen umzusetzen, die Integrität der Lieferkette zu prüfen und aufkommende Bedrohungen zu überwachen.

An steigende Erwartungen bei Governance und Nachweisbarkeit anpassen

Regierungen und Branchen verschärfen die Aufsicht über Lieferketten mit neuen Vorgaben, Gesetzen und Executive Orders. Diese wachsenden Erwartungen von Regulierungsbehörden und Kunden machen Software-Attestierung, Absicherung durch Dritte und dokumentierte SBOMs zur Grundvoraussetzung, besonders für Unternehmen in regulierten oder öffentlichen Umfeldern.

Aufkommende Standards wie die Mindestanforderungen an ein SBOM (gemäß NTIA und Executive Order 14028) entwickeln sich weiter. Dieser regulatorische Druck bewegt Versicherer und Behörden zunehmend dazu, dokumentierte Nachweise für die folgenden Punkte zu verlangen:

• eine umfassende Abdeckung durch das SBOM;

• sichere Build-Pipelines und manipulationssichere Releases;

• gründliche Bewertungen von Drittanbietern;

• die Nachverfolgung der Hardwareherkunft.

Wiz hilft Teams, SBOMs automatisch zu erstellen, Lücken zu erkennen und Compliance mit Standards wie dem SSDF des NIST und SLSA durchzusetzen, ganz ohne Agenten und ohne die Pipeline zu verlangsamen.

Auf aufkommende Bedrohungen vorbereiten

Während Organisationen um die Einführung generativer KI wetteifern, passen sich Angreifer ebenso schnell an. Bedrohungsakteure nutzen KI bereits, um Angriffe auf die Lieferkette zu beschleunigen, etwa indem sie öffentliche Registries nach offengelegten secrets durchsuchen und überzeugend wirkende schädliche Pakete erstellen. Vorausschauende Sicherheitsprogramme setzen unterdessen auf die folgenden Schritte, um vorne zu bleiben:

• zero trust für Build-Systeme durchsetzen: Jeder Schritt des Build-Prozesses wird überprüft, etwa wer ihn ausgelöst hat, welcher Code sich geändert hat und wo Artefakte liegen. Das erhöht die Sicherheit spürbar;

• Versicherungen für die Lieferkette prüfen: Infrage kommen Deckungsoptionen, die an Nachweise solider Sicherheitshygiene geknüpft sind, etwa aktuelle SBOM-Praktiken, gründliche Anbieterbewertungen und sichere CI/CD-Prozesse;

• Attestierung durch Dritte verlangen: Anbieter liefern dokumentierte Nachweise, dass sie sichere Entwicklungspraktiken befolgen und schnell auf Bedrohungen der Lieferkette reagieren.

Anbietern Fragen auf Basis der NIST-Leitlinien stellen

Bei der Bewertung von Drittanbieter-Software helfen die folgenden Fragen, abgeleitet aus dem SSDF des NIST und den Beschaffungsleitlinien, sicherzustellen, dass Anbieter die eigenen Sicherheitsstandards erfüllen:

• Bestehen aufseiten des Anbieters Verbindungen zu ausländischen Regierungen?

• Kann er eine vollständige Bezugsliste für Hardware- und Softwarekomponenten vorlegen?

• Schützt er sensible Daten vor unbefugtem Zugriff oder Transfer?

• Gibt es einen klaren Prozess für sichere Wartung und Updates?

• Kann er die Minderung von Risiken über den gesamten Produktlebenszyklus belegen?

• Befolgt er anerkannte, sichere Entwicklungs-Frameworks?

Wer starke Frameworks, proaktive Sicherheitskontrollen und die Rechenschaft von Anbietern verbindet, verwandelt die Software-Lieferkette in einen strategischen Vorteil statt in ein lauerndes Risiko. Wiz beschleunigt diesen Weg und liefert die Transparenz, Automatisierung und den Kontext, um jede Ebene der Entwicklungs-Pipeline abzusichern.

Alle Komponenten der Software-Lieferkette mit Wiz absichern

Die CNAPP-Plattform von Wiz sichert die Software-Lieferkette von Code bis Cloud ab und fügt sich nahtlos in CI/CD-, DevSecOps- und Cloud-Umgebungen ein. Mit agentless-Deployment und tiefer Transparenz reduziert die Lösung Risiken, ohne die Entwicklung zu verlangsamen. Die folgende Übersicht zeigt, wie.

Wiz fügt sich nahtlos in bestehende Werkzeuge und Workflows über AWS, Azure, GCP, GitHub, GitLab, Jenkins und weitere Systeme ein. Es vereint Teams um eine gemeinsame, risikogesteuerte Sicht auf Cloud und Software-Lieferkette und hilft, Bedrohungen zu stoppen, bevor sie die Produktion erreichen. Eine Demo zeigt, wie Wiz jede Ebene der Software-Lieferkette absichert, Risiken aufdeckt und die Abwehr über die gesamte multi-cloud-Umgebung stärkt.