Die Top-Schwachstellen in der Sicherheit der Software-Lieferkette erklärt
Einleitung: Wann haben Sie zuletzt die Abhängigkeiten und Build-Prozesse Ihrer Software geprüft? Die unschöne Wahrheit ist, dass jede Open-Source-Bibliothek, die Sie npm install, jedes Docker-Image, das Sie ziehen, und jedes Skript in Ihrer CI-Pipeline ein potenzieller Angriffsvektor ist. Die moderne Entwicklung stützt sich stark auf externe Komponenten und Automatisierung, was einer neuen Art von Bedrohungen der Software-Lieferkette Tür und Tor geöffnet hat. Tatsächlich sind Lieferkettenangriffe sprunghaft angestiegen – Sonatype meldet die Entdeckung von über 700.000 bösartigen Open-Source-Paketen seit 2019. Und erst kürzlich führte die Kompromittierung des Kontos eines einzelnen npm-Maintainers dazu, dass 18 weit verbreitete Pakete mit Backdoors versehen wurden mit Malware, wodurch Milliarden wöchentlicher Downloads gefährdet sind. Diese Vorfälle unterstreichen, warum Entwicklungsteams, DevOps-Ingenieure und DevSecOps-Praktizierende sich jetzt mehr denn je um die Sicherheit der Software-Lieferkette kümmern müssen.
Eine „Schwachstelle in der Software-Lieferkette“ bezieht sich auf jede Schwäche in den Prozessen oder Komponenten, die beim Erstellen und Bereitstellen Ihres Codes zum Einsatz kommen – von Drittanbieter-Paketen über Build-Tools bis hin zu CI/CD-Workflows. Angreifer haben erkannt, dass sie unzählige nachgelagerte Anwendungen kompromittieren können, indem sie eine vorgelagerte Komponente vergiften. Der Rest dieses Beitrags schlüsselt neun der kritischsten und am häufigsten übersehenen Sicherheitslücken in der Software-Lieferkette auf. Für jede erklären wir, wie sie funktioniert, wie sie sich in realen Projekten manifestieren kann, welche Risiken sie birgt und wie man sie mindert. Wir werden auch Aikido Security-Hinweise einfügen, um zu veranschaulichen, wie moderne Sicherheitstools (wie Aikidos Abhängigkeitsscanner, Secrets detection, SBOM-Analyse und CI/CD-Scanning) helfen, diese Probleme zu identifizieren oder zu verhindern.
Die Top 9 Schwachstellen in der Software-Lieferkette
1. Bösartige Typosquatting-Pakete
Einer der einfachsten Lieferkettenangriffe ist Typosquatting – bei dem Angreifer bösartige Pakete unter Verwendung von Namen in Registries (npm, PyPI, RubyGems usw.) hochladen die nahezu identisch mit beliebten Bibliotheken sind. Ziel ist es, Entwickelnde (oder deren automatisierte Tools) durch Vertippen oder falsche Identifizierung des Paketnamens dazu zu bringen, den Betrüger zu installieren. Zum Beispiel haben Bedrohungsakteure Pakete wie typescript-eslint auf npm mit Namen wie @typescript_eslinter/eslint, die vor ihrer Entdeckung Tausende von Downloads verzeichneten. Diese gefälschten Pakete enthalten oft versteckte Malware: Sie könnten ein Post-Installationsskript ausführen, das einen Trojaner ablegt oder Daten exfiltriert. In einem Fall installierte ein Typosquat eines Code-Formatierers stillschweigend eine bösartige ausführbare Datei (prettier.bat), die beim Windows-Start persistent war.
So funktioniert's: Angreifer beobachten beliebte Bibliotheken und erstellen ein bösartiges Paket mit einem Namen, der eine häufige Falschschreibung oder Variante ist. Dies kann so subtil sein wie ein fehlender Bindestrich (types-node gegenüber dem legitimen @types/node) oder ein anderer Namespace. Sie veröffentlichen diese Pakete im öffentlichen Repository mit einer verlockenden Versionsnummer oder Beschreibung. Nichtsahnende Entwickelnde könnten den Namen falsch tippen oder in Eile das falsche Paket wählen und dadurch den bösartigen Code einschleusen. Automatisierte Skripte und CI-Systeme sind gleichermaßen anfällig, wenn der Paketname auch nur um ein Zeichen falsch ist.
Risiken: Einmal installiert, läuft das bösartige Paket mit denselben Berechtigungen wie Ihr Anwendungs-Build. Es kann Umgebungsvariablen (Secrets) stehlen, Backdoors installieren oder Second-Stage-Malware herunterladen. In Unternehmensumgebungen kann sich eine einzige vergiftete Abhängigkeit auf viele Anwendungen oder Dienste ausbreiten. Diese Angriffe sind heimtückisch, da Entwickelnde den Fehler oft erst nach dem entstandenen Schaden bemerken. Das Vertrauen, das wir in Paketmanager setzen, kann missbraucht werden, um Code auf Entwickler-Maschinen oder CI-Runnern auszuführen, was potenziell zu gestohlenen Anmeldeinformationen, Datenexfiltration und kompromittierten Servern führen kann.
Gegenmaßnahmen: Um sich gegen Typosquatting zu verteidigen, sollten Entwickelnde Paketnamen doppelt prüfen und Bibliotheken nur von offiziellen oder verifizierten Quellen installieren. Aktivieren Sie 2FA für Paketregister-Konten (um zu verhindern, dass Angreifer ähnliche Scopes oder Profile erstellen). Viele Ökosysteme bieten jetzt Paketsignierung oder -verifizierung an – nutzen Sie diese Funktionen, um die Authentizität sicherzustellen. Die Integration automatisierter Tools ist ebenfalls entscheidend. Zum Beispiel kann ein Abhängigkeitsscanner verdächtige Pakete oder Namen kennzeichnen, die nicht mit bekannten offiziellen Bibliotheken übereinstimmen. Die Verwendung einer „Positivliste“ genehmigter Pakete oder Paket-URL (pURL)-Identifikatoren kann verhindern, etwas zu installieren, das nur richtig aussieht. Schulen Sie Ihr Team, wachsam zu sein, wenn neue Abhängigkeiten hinzugefügt werden.
Aikidos Dependency Scanner kann bekannte bösartige Pakete und Typosquat-Varianten automatisch erkennen, bevor sie in Ihren Build gelangen. Zum Beispiel Aikidos SafeChain Funktion blockiert Pakete, die brandneu oder als bösartig bekannt sind, und verhindert so, dass dieser gefährliche npm install erfolgreich ist. Durch das Scannen der Manifest- und Lockfiles Ihres Projekts hilft Aikido sicherzustellen, dass react-router tatsächlich der echte React Router ist – kein Malware-Betrüger. Diese Art von proaktivem Scannen und Richtlinien (z.B. die Anforderung, dass Pakete ein bestimmtes Alter oder eine bestimmte Popularität haben müssen) kann Typosquatting-Angriffe frühzeitig stoppen, und Ihre Lieferkette sauber halten.
2. Dependency Confusion (Verwechslungen zwischen internen und öffentlichen Paketen)
Dependency Confusion, auch bekannt als Namespace Confusion Attack, ist ein cleverer Exploit gegen Organisationen, die eine Mischung aus privaten (internen) und öffentlichen Paketen verwenden. Er nutzt aus, wie Paketmanager Namen auflösen: Wenn ein interner Paketname versehentlich mit einem Paket im öffentlichen Register übereinstimmt, kann ein Angreifer ein öffentliches Paket mit demselben Namen und einer höheren Version veröffentlichen, um den Resolver zu „verwirren“. Das Ergebnis? Ihr Build-System könnte den Code des Angreifers aus dem öffentlichen Register ziehen, anstatt Ihr beabsichtigtes internes Paket. Dieser Angriffsvektor wurde 2021 vom Sicherheitsforscher Alex Birsan berühmt demonstriert, als er Dutzende großer Technologieunternehmen (Apple, Microsoft, Tesla usw.) kompromittierte, indem er bösartige Pakete hochlud, die den internen Projektnamen dieser Unternehmen entsprachen.
Wie es sich manifestiert: Angenommen, Ihr Unternehmen hat ein internes npm-Paket namens @acme/widget-core in Version 1.3.0, das auf einer privaten Registry gehostet wird. Die package.json Ihres Projekts fordert an @acme/widget-core. Wenn ein Angreifer @acme/widget-core Version 9.9.9 auf npm (öffentlich) veröffentlicht und Ihr Build nicht an die private Quelle gebunden ist, könnte der Paketmanager die Version 9.9.9 von der öffentlichen Registry abrufen (in der Annahme, es sei eine neuere Version). Das bösartige Paket könnte ein Postinstall-Skript enthalten, das automatisch bei der Installation ausgeführt wird, wodurch Remote Code Execution in Ihrer Build-Umgebung erreicht wird. In CI/CD-Pipelines ist dies besonders gefährlich: Der Code läuft auf Build-Agenten, die Zugriff auf sensible Umgebungsvariablen, Quellcode und Deployment-Schlüssel haben könnten.
Risiken: Dependency Confusion kann zu einer sofortigen Kompromittierung der Build- oder Entwicklungsumgebung führen. Die bösartige Payload könnte Secrets (API-Schlüssel, Tokens, Anmeldeinformationen) exfiltrieren oder Backdoors in die erstellte Anwendung injizieren, ohne dass sich Code in Ihrem Repo ändert. Sie umgeht effektiv traditionelle Code-Reviews oder Schwachstellen-Scans Ihres Repos, da der schädliche Code in einer Abhängigkeit liegt, die Sie unwissentlich gezogen haben. Die Auswirkungen können schwerwiegend sein: Angreifer könnten eine laterale Bewegung in Unternehmensnetzwerke erlangen (wenn Build-Server kompromittiert sind) oder bösartige Logik in an Kunden gelieferte Software einschleusen. Es ist eine weit verbreitete Angriffsfläche, da interne Paketnamen-Kollisionen sehr häufig vorkommen können.
Gegenmaßnahmen: Die Verhinderung von Dependency Confusion erfordert eine Kombination aus technischen Kontrollen und Hygiene. Scopieren Sie immer Ihre privaten Pakete explizit und konfigurieren Sie Ihre Paketmanager so, dass sie private Registries für bestimmte Namespaces bevorzugen. Paketmanager-Einstellungen wie npm’s @acme:registry in .npmrc oder pips Index-Einstellungen sollten verwendet werden, um Abhängigkeiten an die beabsichtigte Quelle zu binden. Verwenden Sie striktes Version Pinning und Lockfiles, damit Ihr Build, selbst wenn eine höhere Version anderswo erscheint, diese nicht automatisch übernimmt. Überwachen Sie öffentliche Paket-Registries auf versehentlich geleakte interne Paketnamen (Angreifer erraten diese oft über Erwähnungen in öffentlichen Repos oder Konfigurationsdateien). Viele Organisationen nutzen heute Artefakt-Repositorys als Proxy, sodass nur genehmigte Pakete abgerufen werden. Dies schafft ein Gateway, durch das unbekannte Pakete (selbst wenn der Name übereinstimmt) nicht hereingezogen werden. Schließlich können regelmäßige Audits von Abhängigkeitskonfigurationen und die Generierung einer SBOM (Software-Stückliste) helfen, festzustellen, ob ein unerwartetes externes Paket eingeschleust wurde.
Aikidos Plattform ist ausgestattet, um Dependency Confusion-Szenarien zu erkennen. Zum Beispiel gleicht Aikidos Abhängigkeitsscanner Ihr Paketmanifest sowohl mit öffentlichen als auch mit privaten Quellen ab. Wenn er einen Abhängigkeitsnamen sieht, der auf npm/PyPI existiert, aber intern sein sollte, löst er eine Warnung aus. Aikido kann auch Richtlinien durchsetzen, um nur bestimmte Register zuzulassen oder Namespace-Kontrollen zu erzwingen, um sicherzustellen, dass Ihre Builds nicht versehentlich auf nicht vertrauenswürdige Quellen zugreifen. Durch die SBOM-Analyse bietet Aikido Einblick, welche Paketversion und Quelle genau in einem Build verwendet wurde – was es einfacher macht, ein versehentlich eingeschleustes öffentliches Paket in einer internen App zu erkennen und zu verhindern. Kurz gesagt, Aikido kann dazu beitragen, dass das, was Sie bauen, genau dem entspricht, was Sie beabsichtigt haben, ohne Überraschungscode.
3. Gekaperte Bibliotheken und Protestware (Kompromittierte Maintainer)
Nicht alle Lieferkettenangriffe stammen von neuen, gefälschten Paketen – manchmal werden vertrauenswürdige Pakete bösartig aufgrund von Kompromittierungen von Maintainer-Konten oder vorsätzlicher Sabotage. Wenn ein Angreifer die Kontrolle über ein legitimes Paket erlangt (durch Phishing des Maintainers, Diebstahl von Zugangsdaten oder Ausnutzung laxer Sicherheitsmaßnahmen), kann er ein trojanisiertes Update das Konsumenten herunterladen, in der Annahme, es sei eine normale neue Version. Dies geschah im Jahr September 2025, als ein Maintainer namens „qix“ gephisht wurde und Angreifer bösartige Updates für 18 beliebte npm-Bibliotheken pushten, darunter debug, chalk, und ansi-regex. Diese Bibliotheken hatten zusammen Milliarden wöchentlicher Downloads, was bedeutet, dass die Auswirkungen von nur zwei Stunden Verfügbarkeit bösartigen Codes enorm waren. Ein weiteres Szenario ist „Protestware,“ bei der ein Open-Source-Maintainer seine Bibliothek absichtlich ändert (z. B. um politische Botschaften anzuzeigen oder schlimmer noch, um Systeme in bestimmten Ländern zu sabotieren). In beiden Fällen kann das Paket, dem Sie jahrelang vertraut und das Sie verwendet haben, plötzlich zu einem Waffe gegen Sie werden.
Funktionsweise: Angreifer zielen auf Pakete mit hoher Auswirkung ab – oft solche, die tief in Abhängigkeitsbäumen liegen, sodass Entwickelnde ein Update möglicherweise nicht bemerken. Gängige Taktiken umfassen Phishing von Maintainer-Anmeldeinformationen (wie beim oben genannten npm-Vorfall) oder die Ausnutzung von OAuth-/Token-Lecks. Sobald sie Zugriff haben, veröffentlichen sie eine neue Version, die bösartige Payloads enthält. Diese Payloads können ziemlich ausgeklügelt sein. Beim npm-Angriff 2025 war der eingeschleuste Code ein Krypto-Wallet-Stealer, der nur in Browser-Kontexten aktiviert wurde. Andere Backdoors könnten Umgebungsdaten sammeln, Reverse Shells öffnen oder Daten verschlüsseln (im Ransomware-Stil). Da die Version immer noch semantisch gültig ist (z. B. 4.4.2 zu 4.4.3) und das Paket abgesehen vom versteckten bösartigen Nebeneffekt oft immer noch normal funktioniert, kann es sich vor der Erkennung weit verbreiten. Benutzer entdecken die Kompromittierung in der Regel erst, wenn Sicherheitsscanner ungewöhnliches Verhalten melden oder wenn die Community/öffentliche Registries dies bekannt geben.
Risiken: Das offensichtliche Risiko besteht darin, dass Sie bösartigen Code unter dem Deckmantel einer vertrauenswürdigen Abhängigkeit ausführen. Dies kann zum Diebstahl sensibler Informationen führen (die Malware des npm-Vorfalls zielte auf Krypto-Transaktionen ab, könnte aber ebenso leicht Authentifizierungstoken oder Kundendaten ins Visier nehmen). Es untergräbt die Integrität Ihrer Software – selbst wenn Ihr Code sicher ist, kann die kompromittierte Bibliothek ihn vollständig untergraben. Zusätzlich untergraben diese Angriffe das Vertrauen in das Ökosystem; Teams könnten aus Angst Updates einfrieren (und dabei legitime Korrekturen verpassen). Im schlimmsten Fall kann ein weit verbreitetes kompromittiertes Paket als Hintertür in viele Unternehmen gleichzeitig dienen, da es im Wesentlichen ein Botnetz aller Installationen schafft, die den Angreifer kontaktieren.
Abhilfemaßnahmen: Die Verteidigung gegen gekaperte Pakete ist schwierig, da es sich um einen Vertrauensbruch handelt. Es gibt jedoch Best Practices, um den Schaden zu begrenzen. Behandeln Sie Abhängigkeits-Updates mit gesunder Skepsis: Überprüfen Sie Changelogs und Diffs neuer Versionen, insbesondere bei Kern-Utilities, die normalerweise nicht oft aktualisiert werden. Nutzen Sie automatisiertes Malware-Scanning für neue Paketversionen – einige Tools analysieren das Paketverhalten (z. B. erkennen sie, ob eine neue Version plötzlich Netzwerkaufrufe tätigt oder Systeminformationen liest). Das Festlegen von Versionen (und kein automatisches Upgrade auf die neueste Version ohne Überprüfung) kann Zeit verschaffen, um Community-Berichte zu beobachten. Die Verwendung von Lockfiles und Checksummen-Verifizierung (wie von npm, pips Hash-Prüfmodus usw. unterstützt) kann sicherstellen, dass Sie genau das installieren, was Sie erwarten – und erwägen Sie die Aktivierung von 2FA und Verifizierung für Ihre eigenen Pakete, falls Sie welche veröffentlichen. Aus prozessualer Sicht führen Sie ein Inventar Ihrer Abhängigkeiten (eine SBOM), damit Sie schnell erkennen können, ob Sie ein kompromittiertes Paket verwenden und reagieren müssen.
Aikidos kontinuierliches Abhängigkeits-Monitoring glänzt hier. Der Scanner von Aikido prüft nicht nur auf bekannte CVEs – er achtet auch auf verdächtiges Paketverhalten und bekannte Malware-Signaturen in Abhängigkeiten. Wenn beispielsweise eine neue Version von requests auf PyPI plötzlich versucht, bei der Installation Netzwerkverbindungen zu öffnen, würde Aikido diese Anomalie kennzeichnen. Aikido integriert Bedrohungsaufklärung (einschließlich Feeds bekannter kompromittierter oder gekaperter Pakete), sodass es Sie warnen kann, wenn eine Abhängigkeit in Ihrer Lieferkette als sabotiert gemeldet wird. Zusätzlich kann mit Aikidos AutoFix und Schwachstellen-Feeds, wenn eine bösartige Version durchrutscht, die Plattform einen Fix-PR empfehlen und sogar automatisch öffnen, um auf eine sichere Version zurückzusetzen oder zu aktualisieren. Der Schlüssel ist Geschwindigkeit – Aikido hilft, diese Vorfälle frühzeitig zu erkennen und Ihre Reaktion zu automatisieren, wodurch das Zeitfenster der Exposition reduziert wird.
4. Offengelegte Secrets und Zugangsdaten in Code oder CI
Es wird oft gesagt, dass Zugangsdaten und Secrets die Schlüssel zum Königreich sind. Im Kontext der Supply Chain Security können geleakte Secrets (API-Schlüssel, Cloud-Zugangsdaten, Signierschlüssel usw.) so gefährlich sein wie jede Malware. Warum? Weil, wenn ein Angreifer einen gültigen AWS-Schlüssel oder CI/CD-Token in Ihrem GitHub-Repo oder Ihren Build-Logs findet, er ihn direkt nutzen kann, um Ihre Systeme zu infiltrieren oder Ihre Pipeline zu vergiften. Geleakte Zugangsdaten sind eine Hauptursache für Sicherheitsverletzungen – laut dem Verizon Data Breach Report wurden 22 % der Sicherheitsverletzungen im Jahr 2024 durch offengelegte Zugangsdaten verursacht. Im Hinblick auf die Lieferkette können Secrets in Quellcode oder Konfiguration Angreifern ermöglichen, bösartigen Code zu veröffentlichen (unter Verwendung Ihrer Zugangsdaten), auf private Paket-Registries zuzugreifen oder bösartige Artefakte in Ihre Deployments zu pushen.
Wie es sich manifestiert: Secrets können auf viele Arten durchsickern. Ein Entwickelnder könnte versehentlich eine .env Datei mit Datenbankpasswörtern in ein öffentliches Repo committen. Oder eine CI/CD-Pipeline könnte ein sensibles Token in Logs ausgeben, die weltweit lesbar sind. Noch subtiler: Ein Angreifer, der initialen Zugriff erlangt, könnte Ihren Code nach hartcodierten Schlüsseln durchsuchen. Einmal erlangt, können diese Secrets verwendet werden, um Ihre Konten zu imitieren. Zum Beispiel könnte ein AWS-Schlüssel einem Angreifer ermöglichen, ein vergiftetes Container-Image in Ihr privates ECR-Registry zu pushen, das Ihr Deployment dann zieht. Ein GitHub Personal Access Token könnte einem Angreifer erlauben, Code in Ihr Repo zu committen oder Ihre Releases zu manipulieren. In CI-Pipelines, wenn ein Angreifer Zugangsdaten für CI oder die Cloud erlangt, kann er die normale Code-Überprüfung effektiv umgehen und bösartige Komponenten oder Infrastruktur direkt einfügen.
Risiken: Das direkte Risiko ist unbefugter Zugriff. Offengelegte Cloud-Schlüssel könnten zu Infrastruktur-Verletzungen oder Datendiebstahl führen. Offengelegte Paket-Registry-Zugangsdaten könnten einem Angreifer ermöglichen, eine neue Version einer internen Bibliothek mit Malware zu veröffentlichen (ein weiterer Weg zum Szenario des gekaperten Pakets). In CI könnten geleakte Token Angreifern ermöglichen, Build-Konfigurationen zu ändern, Secrets aus Tresoren abzurufen oder Artefakte abzufangen. Im Wesentlichen sind Secrets wie Generalschlüssel: Sobald der Angreifer sie hat, kann er sich oft durch Ihre Systeme bewegen, ohne eine Software-Schwachstelle ausnutzen zu müssen. Dies kann zu allem führen, von einer vollständigen Kompromittierung der Produktionsumgebung bis hin zu Angreifern, die Artefakte stillschweigend ändern (z. B. das Austauschen einer Binärdatei in einer Release-Pipeline durch eine mit Backdoor). Diese Szenarien sind Teil von Lieferkettenangriffen, da die Integrität des Software-Lieferprozesses durch gestohlenes Vertrauen gebrochen wird.
Abhilfemaßnahmen: Die beste Abhilfemaßnahme ist, Secrets gar nicht erst preiszugeben. Leichter gesagt als getan, aber es gibt konkrete Praktiken: Verwenden Sie Secret-Scanning-Tools in Ihren Repos, um API-Schlüssel oder Passwörter abzufangen, bevor sie committed werden. Git-Anbieter wie GitHub haben integriertes Secret-Scanning – aktivieren Sie es. Hinterlegen Sie niemals sensible Zugangsdaten hartcodiert im Code; verwenden Sie stattdessen Umgebungsvariablen oder Secret-Management-Dienste (und stellen Sie sicher, dass Ihre Repos diese Werte nicht in Konfigurationsdateien enthalten). In CI/CD maskieren Sie Secrets in Logs (die meisten Plattformen bieten Optionen, um das Ausgeben von Secret-Umgebungsvariablen zu verhindern). Rotieren Sie regelmäßig Schlüssel, damit ein Leak, falls er auftritt, nur für ein kurzes Zeitfenster gültig ist. Wenden Sie das Prinzip der geringsten Rechte an: Ein geleaktes Token, das nur Lesezugriff hat, ist weitaus weniger schädlich als ein Admin-Token. Für alle Schlüssel mit hohen Berechtigungen erzwingen Sie, wenn möglich, Multi-Faktor- oder IP-Beschränkungen. Überwachen Sie die Nutzung von Secrets – z. B. wenn ein Schlüssel, der nur von Ihrer App verwendet werden sollte, plötzlich an anderer Stelle genutzt wird, ist das ein Warnsignal.
Aikidos Secrets detection-Funktion ist darauf ausgelegt, offengelegte Anmeldeinformationen frühzeitig zu erkennen. Sie scannt Ihren Code, Konfigurationsdateien und sogar CI-Pipeline-Definitionen nach Mustern, die API-Schlüsseln, privaten Schlüsseln, Tokens und mehr entsprechen. Wenn beispielsweise jemand versehentlich einen GitHub Personal Access Token oder einen AWS Secret Key committet, wird Aikido dies sofort kennzeichnen, sodass Sie ihn bereinigen und rotieren können. Die Erkennung ist jedoch nur ein Teil der Lösung – Aikido kann in Ihre CI integriert werden, um einen Build fehlschlagen zu lassen, wenn ein Secret gefunden wird, wodurch die versehentliche Bereitstellung sensibler Informationen verhindert wird. Es hilft auch dabei, ein Inventar darüber zu führen, welche Secrets sich wo befinden, und ergänzt so Ihre Nutzung von Vaults oder Secret Managern. Durch die Integration von Secrets-Scanning in den Entwicklungs-Workflow (IDE-Plugins, Pre-Commit-Hooks, CI-Checks) hilft Aikido Entwickelnden, Anmeldeinformationen aus Repositorys und Pipelines fernzuhalten, und unterbindet damit einen der einfachsten Wege, den Angreifer bei Lieferkettenangriffen nutzen.
5. Unsichere CI/CD-Pipeline-Konfigurationen (Pipeline als Angriffsfläche)
Ihre CI/CD-Pipeline ist effektiv das Fließband Ihrer Softwarefabrik – und wenn sie fehlkonfiguriert oder unsicher ist, können Angreifer alles manipulieren, was von diesem Band kommt. CI/CD-Systeme (wie GitHub Actions, Jenkins, GitLab CI usw.) haben oft umfassenden Zugriff: Sie rufen Code ab, integrieren Abhängigkeiten, führen Tests aus, pushen Artefakte und stellen sogar in Produktion bereit. Dies macht sie zu einem attraktiven Ziel. Häufige Probleme bei der Pipeline-Sicherheit sind übermäßig breite Zugriffsrechte, mangelnde Isolation und die Verwendung unsicherer Standardeinstellungen. Eine aktuelle Analyse ergab, dass etwa 23,8 % der Software-Lieferkettenangriffe CI/CD-Build-Schwachstellen ausnutzen, was unterstreicht, dass Pipeline-Sicherheit nun eine wichtige Front ist. In der Praxis haben wir Vorfälle gesehen, bei denen Angreifer CI-Fehlkonfigurationen ausnutzten, um sich lateral zu bewegen. Zum Beispiel kann ein fehlkonfigurierter Jenkins-Server, der dem Internet ausgesetzt ist, oder ein CI-Job, der unbeabsichtigt nicht vertrauenswürdigen Code ausführt (z. B. das Erstellen von PRs von externen Mitwirkenden ohne Sandboxing), zu einer Kompromittierung führen.
Wie es sich manifestiert: Ein Szenario sind überprivilegierte Pipeline-Runner. Stellen Sie sich einen CI-Agenten vor, der Admin-Zugriff auf Ihre Cloud hat oder Artefakte direkt bereitstellen darf. Wenn ein Angreifer sich in die CI einschleusen kann (durch Code-Injection, kompromittierte Anmeldeinformationen oder Ausnutzung des CI-Tools), hat er nun effektiv die „Schlüssel zum Königreich“ – er kann Malware in Builds einschleusen oder sogar den CI-Agenten nutzen, um Befehle in Ihrer Infrastruktur auszuführen. Ein weiteres Szenario ist die Nichtdurchsetzung von Überprüfungen für eingehenden Code: z. B. könnte ein bösartiger Pull Request, der eine CI-Konfigurationsänderung enthält, um Secrets zu exfiltrieren oder Tests zu überspringen, durchrutschen, wenn Code-Reviews lax sind. Auch mounten viele CI-Pipelines Secrets (wie Signierschlüssel oder Bereitstellungsanmeldeinformationen) als Umgebungsvariablen. Wenn die Pipeline nicht so konfiguriert ist, dass sie einschränkt, wer Builds auslösen oder welchen Code ausführen kann, können diese Secrets von Angreifern gestohlen werden, die den Build manipulieren. Zum Beispiel könnten einige Standard-Setups geforkten Repository-PRs erlauben, den Haupt-CI mit Zugriff auf Secrets auszuführen – eine bekannte gefährliche Einstellung, die Secrets an bösartige Mitwirkende weitergeben kann.
Risiken: Eine kompromittierte CI/CD-Pipeline bietet einem Angreifer einen direkten Weg, Software während des Build- oder Deployment-Prozesses zu kompromittieren. Dies könnte dazu führen, dass unautorisierter Code an die Produktion oder an Benutzer ausgeliefert wird (man stelle sich bösartigen Code vor, der während des Builds hinzugefügt wurde und nie in der Quellcodeverwaltung existierte). Es kann auch zu weitreichenden Datenlecks führen; CI-Systeme enthalten oft Protokolle oder Artefakte mit sensiblen Informationen. Eine unsichere Pipeline kann missbraucht werden, um sich anderweitig zu bewegen – zum Beispiel, wenn Ihr Jenkins-Server Netzwerkzugriff auf interne Dienste hat, kann ein Angreifer, der Jenkins kompromittiert, diese Dienste ausnutzen. Im Wesentlichen ist eine anfällige CI ein Einfallstor für sowohl Ihr Softwareprodukt als auch Ihre Infrastruktur. Es ist auch ein oft übersehener Bereich – Entwicklungsteams konzentrieren sich auf die Sicherheit des Anwendungscodes, prüfen die Pipeline aber möglicherweise nicht mit der gleichen Sorgfalt.
Gegenmaßnahmen: Die Absicherung von CI/CD-Pipelines erfordert, sie wie Produktions-Assets zu behandeln. Zuerst den Zugriff absichern: Stellen Sie sicher, dass Ihr CI-System nicht offen zugänglich ist, verwenden Sie VPNs oder IP-Allow-Lists und verlangen Sie eine Authentifizierung für das Auslösen sensibler Jobs. Wenden Sie das Prinzip der geringsten Rechte auf Pipeline-Anmeldeinformationen an – wenn ein Build-Job beispielsweise nur Push-Zugriff auf ein Artefakt-Repository benötigt, geben Sie ihm nicht zusätzlich Cloud-Administratorrechte. Verwenden Sie separate Anmeldeinformationen für separate Jobs/Stages. Zweitens, Eingaben bereinigen: Verwenden Sie für öffentlich zugängliche Workflows (wie Open-Source-Projekte, bei denen jeder einen PR öffnen kann) isolierte Runner-Umgebungen ohne Secrets oder verlangen Sie eine manuelle Genehmigung für die Ausführung von nicht vertrauenswürdigem Code. Viele CI-Plattformen ermöglichen es Ihnen, Secrets so zu markieren, dass sie nicht für geforkte PRs verfügbar sind. Aktivieren Sie die Audit-Protokollierung für Ihre Pipeline: Wissen Sie, wer was in den Build-Konfigurationen geändert hat. Eine weitere wichtige Praxis ist das Fixieren Ihrer CI-Abhängigkeiten – wenn Ihre Pipeline Build-Container oder Drittanbieter-Aktionen/Plugins verwendet, fixieren Sie diese auf bestimmte Versionen oder Hashes (vermeiden Sie „latest“-Tags), um zu verhindern, dass ein Angreifer etwas austauscht (mehr dazu im nächsten Abschnitt). Aktualisieren Sie Ihre CI-Software und Plugins regelmäßig, da Schwachstellen in CI-Tools selbst auftreten. Schließlich sollten Sie (wo machbar) für jeden Build ephemere isolierte Runner verwenden, damit ein kompromittierter Build dem Angreifer keinen dauerhaften Zugang ermöglicht.
Aikido bietet CI/CD-Sicherheitsscanning, das hilft, Ihre Pipeline-Konfigurationen auf Best Practices und potenzielle Fehlkonfigurationen zu prüfen. Aikido kann beispielsweise Ihre GitHub Actions-Workflows oder Jenkins-Dateien analysieren, um Probleme wie ungepinnte Aktionen, die Verwendung von selbst gehosteten Runnern mit weitreichenden Berechtigungen oder Secrets, die für geforkte PRs offengelegt wurden, zu kennzeichnen. Es fungiert als Linter für die CI-Sicherheit. Die Aikido-Plattform integriert sich auch in CI-Pipelines, um Richtlinien durchzusetzen: Wenn jemand versucht, einen Deployment-Job von einem nicht autorisierten Branch auszuführen, oder wenn eine kritische Workflow-Datei in einem PR geändert wurde, kann Aikido zusätzliche Genehmigungen anfordern. Durch das kontinuierliche Scannen des Pipeline-Setups hilft Aikido sicherzustellen, dass Ihre „Software-Fabrik“ gut geschützt ist – keine offenen Türen, keine einfachen Wege für einen Angreifer, den Prozess zu kapern. Stellen Sie es sich als einen CI/CD-Konfigurationswächter vor, der mit Ihrem DevSecOps-Team zusammenarbeitet.
6. Vergiftete Pipeline-Abhängigkeiten (Drittanbieter-CI/CD-Tools und -Aktionen)
Moderne Pipelines binden oft eine Vielzahl von Drittanbieter-Tools, Docker-Images, Skripten und Aktionen zur Ausführung von Aufgaben (wie Code-Coverage, Deployments usw.) ein. Jede davon ist eine implizite Abhängigkeit in Ihrer Lieferkette. Wenn eine davon bösartig oder kompromittiert ist, kann Ihre Pipeline (und die daraus resultierende Software) kompromittiert werden. Ein frappierendes Beispiel hierfür war der Angriff auf die reviewdog/action-setup GitHub Action und die anschließende Kompromittierung von tj-actions/changed-files im Jahr 2025. Angreifer schafften es, bösartigen Code in diese weit verbreiteten CI-Aktionen einzuschleusen, indem sie deren Update-Prozess ausnutzten, wodurch jedes Projekt, das sie verwendete, Secrets von CI-Runnern preisgab. Ähnlich verhält es sich mit Pipeline-Skripten wie dem Codecov Bash Uploader (der 2021 kompromittiert wurde) – Tausende von Pipelines vertrauten einem Tool, das stillschweigend ihre Daten exfiltrierte. Diese Vorfälle zeigen, wie ein Angreifer das die Quelle vergiften kann, indem er die Tools angreift, auf die sich Ihre Pipeline verlässt.
So funktioniert's: Angreifer suchen nach beliebten CI/CD-Dienstprogrammen oder Images mit Lieferketten-Schwachstellen – vielleicht ein Maintainer, der keine Commits signiert, oder eine veraltete Abhängigkeit in einem Docker-Image. Durch die Kompromittierung des Upstream-Projekts (via Kontoübernahme, Exploit oder Einschleichen als Mitwirkender) können sie bösartigen Code einschleusen. Im Fall der GitHub Actions erlangte ein Angreifer Zugriff auf das Konto oder den Token des Maintainers und änderte den Aktionscode, sogar die Git-Referenzen neu taggte, sodass das, was als „v1“ markiert war, nun auf einen bösartigen Commit zeigte. Projekte, die uses: reviewdog/action-setup@v1 in ihrem Workflow verwendeten, zogen plötzlich eine manipulierte Aktion, die Secrets ausgab. Da CI-Systeme bei jedem Lauf normalerweise den neuesten getaggten Code abrufen, kann eine Pipeline unwissentlich geänderten Code von einem Drittanbieter ausführen. Docker-Images, die in CI (für Build oder Test) verwendet werden, sind ähnlich gefährdet – wenn jemand ein bösartiges Update für ein Image wie node:alpine verwendet, würden Sie alles ausführen, was in diesem Image enthalten ist.
Risiken: Die Auswirkungen hier sind ähnlich wie bei einem Bibliotheks-Hijacking, aber potenziell sogar direkter. CI-Tools laufen oft mit hohen Berechtigungen (einige GitHub-Runner haben Sudo usw.) und Zugriff auf Anmeldeinformationen. Eine vergiftete Aktion oder ein Skript kann sofort alle Ihre Umgebungs-Secrets exfiltrieren oder Backdoors in den zu erstellenden/testenden Code einschleusen. In einem realen Vorfall gab eine bösartige GitHub Action CI-Secrets in öffentliche Protokolle aus. Ein weiteres Risiko besteht darin, dass ein kompromittiertes Build-Tool die kompilierte Ausgabe ändern könnte (man stelle sich einen bösartigen Compiler vor, der immer eine bestimmte Schwachstelle oder Hintertür in Binärdateien einfügt). Der schwierige Teil für Verteidiger ist, dass diese Pipeline-Abhängigkeiten möglicherweise nicht so genau geprüft werden wie Ihre Code-Abhängigkeiten – viele Teams vertrauen blind einem Docker-Image oder einer Open-Source-Aktion, weil sie weit verbreitet ist. Das verschafft Angreifern einen heimlichen Zugang, und der Einbruch wird möglicherweise erst viel später (wenn überhaupt) entdeckt.
Gegenmaßnahmen: So wie Sie Anwendungsabhängigkeiten festlegen, legen Sie Ihre Pipeline-Abhängigkeiten fest.. In GitHub Actions sollten Sie anstelle von @v1 oder @main für eine Aktion einen spezifischen Commit-SHA verwenden, damit diese nicht stillschweigend geändert werden kann. Für Docker-Images sollten Sie Digests oder spezifische Versionen anstelle von aktuellsteverwenden. Dies stellt sicher, dass Sie jedes Mal eine bekanntermaßen gute Version ausführen. Als Nächstes gilt: Vertrauen ist gut, Kontrolle ist besser: Bevorzugen Sie Aktionen oder Tools, die weithin vertraut sind und und idealerweise über einen Verifizierungsmechanismus verfügen (einige Aktionen sind GitHub-verifiziert oder signiert). Überwachen Sie Upstream-Benachrichtigungen – abonnieren Sie Sicherheits-Feeds der von Ihnen verwendeten Drittanbieter-Tools, um über Kompromittierungen informiert zu werden. Wo möglich, sollten Sie kritische Pipeline-Tools selbst hosten oder von einem vertrauenswürdigen Anbieter beziehen: z. B. anstatt ein zufälliges Skript zur Build-Zeit aus dem Internet zu ziehen, integrieren Sie es (nach Überprüfung) in Ihre Codebasis, damit es sich nicht unbemerkt ändern kann. Verwenden Sie Sandboxing für risikoreiche Schritte – z. B. führen Sie Linter oder Testabdeckungstools in isolierten Containern mit eingeschränktem Zugriff aus. Ziehen Sie schließlich die Einführung von Frameworks wie Googles SLSA (Supply Chain Levels for Software Artifacts) für Ihre Pipelines in Betracht, die Richtlinien zur Härtung von Build-Prozessen bieten und die Herkunft für Build-Schritte erfordern.
🛡 Aikido Security Hinweis: Das CI/CD-Scanning von Aikido erstreckt sich auch auf die Abhängigkeiten Ihrer Pipeline. Es prüft, ob Ihre Workflows Aktionen mit veränderlichen Tags referenzieren oder von potenziell nicht vertrauenswürdigen Quellen ziehen. Zum Beispiel kann Aikido kennzeichnen, dass Sie uses: someaction@latest verwenden und vorschlagen, es an einen Commit zu pinnen. Der Abhängigkeitsscanner von Aikido prüft nicht nur Ihren Anwendungscode; er kann auch Ihre Build-Container und Tools auf bekannte Schwachstellen oder Malware-Signaturen scannen. Wenn Sie ein Basis-Docker-Image in CI verwenden, kann Aikido das SBOM dieses Images scannen, um sicherzustellen, dass es keine bekannten schädlichen Komponenten enthält. Im Wesentlichen hilft Aikido sicherzustellen, dass die Bestandteile Ihrer Pipeline so sicher sind wie die Bestandteile Ihrer Anwendung. Durch die Integration dieser Prüfungen stellt Aikido sicher, dass Ihre CI-Tools und Aktionen keine versteckte Hintertür darstellen. Falls ein beliebtes Tool doch kompromittiert wird, würde die Bedrohungsaufklärung von Aikido aktualisiert, und Sie würden eine Warnung erhalten, wenn Ihre Pipelines betroffen sind – so können Sie schnell reagieren (z. B. die Pipeline anhalten, auf eine sichere Version aktualisieren), bevor Schaden entsteht.
7. Nicht festgelegte Versionen und veränderliche Abhängigkeiten (Das „Latest“-Problem)
Die Verwendung von gleitenden oder nicht festgelegten Abhängigkeitsversionen ist eine Supply-Chain-Schwachstelle, die Sie auf zweierlei Weise treffen kann: Sie könnten unwissentlich ein bösartiges Update oder ein fehlerhaftes/anfälliges Update erhalten, weil Sie immer „latest“ ziehen. Ob es sich um ein Docker-Basis-Image mit dem Tag :latest oder einen Paketversionsbereich wie ^1.0.0 in npm handelt, bedeutet die Verwendung nicht-fixierter Versionen, dass Ihr Build heute eine andere Komponente abrufen könnte als gestern. Dies untergräbt die Reproduzierbarkeit des Builds und öffnet Angreifern die Tür, ihre Schritte zu timen. Wenn beispielsweise ein Angreifer ein Paket kompromittiert und Sie nicht an eine spezifische, bekanntermaßen gute Version pinnen, wird Ihr nächster Build die kompromittierte Version abrufen. Bei dem zuvor diskutierten GitHub Actions-Angriff war ein Faktor, dass Projekte einen veränderlichen Tag referenzierten (v1) den der Angreifer auf einen bösartigen Commit umgeleitet hat. Die Verwendung strikter Pins (wie Commit-SHAs oder exakte Versionen) hätte verhindert, dass diese Tag-Umleitung Builds beeinträchtigt.
So funktioniert's: Betrachten Sie ein Python-Projekt, das requests>=2.0 in seinen Anforderungen verwendet (was jede neue 2.x-Version zulässt). Wenn Sie `pip install` ausführen, wird die neueste 2.x-Version heruntergeladen. Wenn Betreuer (oder ein Angreifer) requests 2.999 morgen veröffentlichen und diese Probleme aufweist, ändert sich Ihre Umgebung unerwartet. Oder stellen Sie sich vor, Ihr Dockerfile verwendet FROM node:latest; wann immer das Node-Team dieses Image aktualisiert (oder wenn es einem Angreifer gelingt, ein ähnliches Image zu pushen), ziehen Ihre Builds ein neues Image mit möglicherweise unterschiedlichen Inhalten. Nicht fixierte Abhängigkeiten übergeben im Wesentlichen die Kontrolle über Ihre Lieferkette an die Zeitpläne externer Parteien. Angreifer mögen dies besonders, wenn sie Zugriff erhalten, um ein Update zu pushen – sie wissen, dass viele Benutzer automatisch aktualisieren werden. Selbst ohne einen böswilligen Akteur besteht das Risiko, dass ein schlechtes Update Fehler verursacht oder eine Sicherheitslücke einführt, bevor Sie es bemerken. Der berüchtigte left-pad-Vorfall (bei dem eine Paketentfernung Builds weltweit zum Erliegen brachte) ist ein Beispiel dafür, was passieren kann, wenn viele Projekte implizit einer externen neuesten Version vertrauen.
Risiken: Das Hauptrisiko ist der Mangel an Kontrolle und Transparenz. Sie denken vielleicht, Sie bauen denselben Code, aber in Wirklichkeit hat sich eine darunterliegende Bibliothek oder ein Image geändert. Diese Änderung könnte eine kritische Schwachstelle (wenn Sie automatisch auf eine Version mit einer neuen CVE aktualisiert haben) oder bösartige Logik sein. Bei Lieferkettenangriffen ist das Timing entscheidend: Wenn der Angreifer kurzzeitig eine schlechte Version einführen kann, während Sie bauen, gewinnt er, selbst wenn diese Version später behoben wird. Nicht fixierte Abhängigkeiten erschweren auch die Reaktion auf Vorfälle – wenn Sie nicht genau wissen, welche Version in einem bestimmten Build verwendet wurde, ist es schwierig nachzuvollziehen, ob Sie von einer bösartigen oder anfälligen Veröffentlichung betroffen waren. Im Wesentlichen untergräbt dies die Reproduzierbarkeit und Nachvollziehbarkeit, die für sichere Builds grundlegend sind. Die Integrität von Software-Builds hängt von deterministischen Eingaben ab; „latest“ ist das Gegenteil von deterministisch.
Abhilfe: Fixieren oder sperren Sie Ihre Abhängigkeiten immer auf bekannte gute Versionen oder Digests. Verwenden Sie exakte Versionsnummern in Paket-Manifesten und setzen Sie Lockfiles (package-lock.json, Pipfile.lock usw.) ein, damit jeder und jede Umgebung dieselben aufgelösten Versionen verwendet. Für Docker-Images fixieren Sie auf eine spezifische Version oder besser noch auf einen Digest-SHA (der unveränderlich ist). Für Git-basierte Abhängigkeiten oder Aktionen fixieren Sie auf Commit-Hashes. Wenn Sie Bereiche zulassen müssen (für kleinere Updates), sollten Sie zuverlässige Bots oder Update-Tools in Betracht ziehen, die Sie auf neue Versionen aufmerksam machen, anstatt diese automatisch zu ziehen. Implementieren Sie eine Richtlinie, dass kein Build ein Artefakt konsumieren sollte, das nicht explizit in der Quellcodeverwaltung (oder in einer Metadatendatei) verfolgt wird. Zusätzlich pflegen Sie eine SBOM für jede Veröffentlichung – dies ist eine Liste der exakten Komponentenversionen in Ihrem Produkt. Auf diese Weise können Sie, wenn ein Risiko auftritt (z.B. Version X wurde am Datum Y kompromittiert), schnell abfragen, welche Ihrer Veröffentlichungen diese Version enthielt. Es ist auch klug, Ihren Abhängigkeitsaktualisierungsprozess separat zu testen – aktualisieren Sie nicht blind in Produktions-Builds; haben Sie einen Staging- oder CI-Job, der Updates testet, damit Sie Probleme erkennen können. Letztendlich gibt Ihnen das Fixieren von Versionen die Kontrolle: Sie entscheiden, wann Sie nach der Überprüfung aktualisieren, anstatt von Upstream-Änderungen überrascht zu werden.
Die Tools von Aikido fördern nachdrücklich das Fixieren von Abhängigkeiten und die Versionstransparenz. Wenn Aikido eine SBOM für Ihr Projekt generiert, listet es jede Komponente und Version auf – dies hilft sicherzustellen, dass es keine „schwebenden“ Abhängigkeiten gibt. Aikido kann sich auch in Ihre CI integrieren, um Builds fehlschlagen zu lassen, die nicht fixierte Abhängigkeiten verwenden oder veränderliche Tags verwenden, was als Sicherheitsnetz dient. Wenn zum Beispiel jemand FROM python:latest in einem Dockerfile einführt oder eine GitHub Action ohne fixierten SHA hinzufügt, wird der Scanner von Aikido dies kennzeichnen. Darüber hinaus können die Abhängigkeitsverwaltungsfunktionen von Aikido automatisch Pull-Requests öffnen, um Abhängigkeiten kontrolliert (mit Sicherheitskontext) zu aktualisieren, sodass Sie nicht auf alten Versionen festsitzen, sondern sicher aktualisieren können. Durch die Verwendung von Aikido zur Überwachung und Verwaltung Ihrer Open-Source-Komponenten erhalten Sie effektiv einen Schutzschild, der sicherstellt, dass Sie genau wissen, was Sie bauen. In diesem Wissen liegt Macht (und Sicherheit).
8. Veraltete Komponenten mit bekannten Schwachstellen
Am anderen Ende des Spektrums der „neuesten“ Probleme steht das Risiko, veraltete Abhängigkeiten mit bekannten Sicherheitslücken (CVEs) zu verwenden. Dies ist eher eine traditionelle Schwachstelle, aber es ist definitiv ein Problem der Lieferkette: Ihre Software ist nur so sicher wie das schwächste Glied in ihrem Abhängigkeitsgraph. Angreifer nutzen oft bekannte Schwachstellen in beliebten Bibliotheken aus, bei denen Organisationen langsam mit dem Patchen waren. Zum Beispiel kann die Verwendung einer älteren Version einer Struts-, Log4j- oder OpenSSL-Bibliothek mit einer öffentlich bekannten kritischen CVE zu Remote Code Execution oder einer Datenpanne in Ihrer Anwendung führen – im Wesentlichen ein Versäumnis der Lieferkette, Updates durchzuführen. Angesichts der Explosion von Open Source ist es eine Herausforderung, alles auf dem neuesten Stand zu halten; jedoch zeigen Software-Kompositionsanalyse-(SCA)-Berichte durchweg, dass ein großer Prozentsatz von Anwendungen veraltete Bibliotheken mit bekannten Schwachstellen aufweist. Wenn Sie eine anfällige Open-Source-Komponente einbinden, muss ein Angreifer möglicherweise keinen neuen Exploit schreiben – er kann einfach die vorhandene CVE gegen Sie nutzen.
Wie es sich manifestiert: Oft integrieren Entwicklungsteams eine Bibliothek für bestimmte Funktionalitäten und vergessen dann, sie zu aktualisieren. Diese Bibliothek könnte weitere (transitive Abhängigkeiten) nach sich ziehen, und irgendwo in dieser Kette könnte ein kritischer Fehler stecken. Stellen Sie sich zum Beispiel eine Node.js-Anwendung vor, die ein Paket einbindet, das von einer veralteten lodash Version mit einer Prototype-Pollution-Schwachstelle abhängt. Ihre Anwendung könnte über diese Schwachstelle ausnutzbar sein, selbst wenn Ihr Code in Ordnung ist. Auch in CI/CD- und Build-Tools können veraltete Komponenten lauern – vielleicht enthält Ihr Build-Container ein altes OS-Paket mit einem Shellshock-Bug, oder Ihr CI-Server selbst ist ungepatcht. Die Manifestation ist in der Regel, dass ein Scanner oder Penetrationstest die bekannte CVE findet, oder schlimmer noch, ein Vorfall eintritt (z. B. die Anwendung wird über diese Komponente gehackt). Ein berüchtigter Fall war die Log4j „Log4Shell“-Schwachstelle (CVE-2021-44228); viele Organisationen wurden überrascht, da sie alte Log4j-Versionen verwendeten und von Exploits in freier Wildbahn betroffen waren. Ein solches Szenario ist genau das, was proaktive Supply-Chain-Security verhindern soll.
Risiken: Das Risiko durch bekannte, anfällige Komponenten ist offensichtlich: Angreifer wissen bereits, wie sie diese ausnutzen können. Sobald eine Schwachstelle öffentlich ist, gibt es oft Proof-of-Concept-Exploits oder zumindest detaillierte Beschreibungen dazu. Angreifer scannen das Internet nach Anwendungen oder Diensten, die die anfällige Komponente zu nutzen scheinen (z. B. durch Überprüfung von App-Headern oder spezifischem Verhalten). Wenn Ihre Software diese Komponente verwendet und auf anwendbare Weise exponiert ist, sind Sie ein Ziel. Dies kann je nach Schwachstelle zu einer vollständigen Systemkompromittierung, Datendiebstahl oder Dienstausfällen führen. Abgesehen von der direkten Ausnutzung gibt es auch Compliance- und Kundenvertrauensprobleme – der Betrieb bekannter Schwachstellen kann gegen Vorschriften oder vertragliche Sicherheitsanforderungen verstoßen. Es ist ein Indikator für mangelnde Sicherheitshygiene. Denken Sie daran, dass Ihre Lieferkette nicht nur den Code umfasst, den Sie schreiben, sondern auch den Code, den Sie konsumieren; das Vernachlässigen von Updates ist wie das Hinterlassen von Lücken in Ihren Verteidigungsanlagen, die in den Angreifer-Playbooks gut dokumentiert sind.
Gegenmaßnahmen: Etablieren Sie eine Kultur des kontinuierlichen Abhängigkeitsmanagements. Dies bedeutet, Ihre Projekte (und Container-Images) regelmäßig auf bekannte Schwachstellen zu scannen. Verwenden Sie SCA-Tools, um zu kennzeichnen, wenn eine Abhängigkeitsversion eine CVE aufweist. Viele Paketmanager verfügen mittlerweile über Audit-Befehle (z. B. npm audit, pip audit), um anfällige Pakete aufzulisten. Machen Sie dies zu einem Teil Ihrer CI, sodass Builds warnen oder fehlschlagen, wenn neue Schwachstellen eingeführt werden. Etablieren Sie einen Prozess (möglicherweise automatisiert über Bots wie Dependabot oder Aikido’s AutoFix), um Upgrades auf gepatchte Versionen anzustoßen. Es ist wichtig, Prioritäten zu setzen – nicht alle CVEs sind gleich; konzentrieren Sie sich auf solche mit hoher Schwere oder in Software, die von Ihrer Anwendung aus erreichbar ist. Stellen Sie außerdem sicher, dass Sie Ihre Build- und Deployment-Umgebung aktualisieren – z. B. Ihre Basis-Docker-Images mit Sicherheitspatches aktuell halten, CI-Tools oder Plugins auf gepatchte Releases aktualisieren. Ein weiterer wichtiger Punkt ist die Pflege einer Software Bill of Materials (SBOM) wie erwähnt, was Ihnen hilft, schnell die Frage zu beantworten: „Verwenden wir die Bibliothek, über die diese Woche alle in Panik geraten sind?“ Als Log4Shell zuschlug, konnten Organisationen mit einem guten SBOM Prozess sofort suchen und finden, wo Log4j verwendet wurde. Abonnieren Sie schließlich Sicherheitsbulletins für die wichtigsten Projekte, die Sie verwenden, damit Sie frühzeitig über neue Schwachstellen informiert werden. Schnelles Patchen ist entscheidend; Angreifer beginnen oft innerhalb von Tagen oder sogar Stunden nach der Ankündigung, beliebte CVEs auszunutzen.
Aikidos Abhängigkeitsscanner und SCA-Funktionen sind darauf ausgelegt, genau dieses Problem zu lösen. Er scannt Ihre Projekte, um alle Open-Source-Komponenten zu identifizieren und sie mit einer kontinuierlich aktualisierten Schwachstellendatenbank abzugleichen. Die Ausgabe ist nicht nur eine Liste von Problemen – Aikido liefert umsetzbare Informationen wie Schweregrad, ob ein Fix verfügbar ist, und sogar eine AutoFix-Funktion die automatisch sichere Update-Patches generieren kann. Wenn Ihr Maven-Projekt beispielsweise eine alte Struts-Bibliothek mit einem kritischen Fehler verwendet, kann Aikido die sichere Version vorschlagen und Ihre pom.xml für Sie aktualisieren. Darüber hinaus integriert sich Aikido in Ihren gesamten Entwicklungs-Workflow (IDE-Plugins, PR-Checks, CI), sodass bekannte Schwachstellen frühzeitig erkannt werden und nicht erst, wenn Ihre Software in Produktion ist. Es hilft Ihnen auch, SBOMs einfach zu generieren, was Ihnen Transparenz darüber verschafft, was sich in Ihrer Software befindet. Das bedeutet, wenn die nächste Zero-Day-Schwachstelle in einer gängigen Bibliothek Schlagzeilen macht, können Sie schnell Ihr Aikido-Dashboard abfragen, um zu sehen, ob Sie betroffen sind. Auf dem Laufenden bleiben bei Updates wird viel einfacher, wenn Aikido Ihnen kontinuierlich den Rücken freihält und sicherstellt, dass veraltete Komponenten nicht unbeachtet bleiben.
9. Mangelnde Integritätsprüfung (Unzureichende Signatur- und Ursprungsvalidierung)
Die letzte hervorzuhebende Schwachstelle ist systemischer Natur: das Versäumnis, die Integrität und den Ursprung von Komponenten zu überprüfen. Mit anderen Worten, das Nicht-Verwenden oder Nicht-Prüfen von Signaturen, Prüfsummen oder der Herkunft für den Code und die Binärdateien, die durch Ihre Software-Lieferkette fließen. Ohne Integritätsprüfung vertrauen Sie im Wesentlichen standardmäßig. Angreifer können dies ausnutzen, indem sie Artefakte manipulieren oder Quellen imitieren. Wenn Sie beispielsweise eine Drittanbieter-Bibliothek oder einen Installer über unverschlüsseltes HTTP oder von einer Mirror-Site herunterladen, ohne einen Hash/eine Signatur zu überprüfen, könnte ein Angreifer in der Mitte Ihnen eine kompromittierte Version liefern. Ähnlich verhält es sich, wenn Sie nicht überprüfen, ob ein Container-Image von einer vertrauenswürdigen Partei signiert ist, könnte Sie jemand dazu verleiten, ein ähnliches Image mit einer Backdoor auszuführen. Selbst innerhalb von CI/CD bedeutet mangelnde Verifizierung, dass, wenn ein Angreifer einen Schritt kompromittiert, nachfolgende Schritte Ausgaben blind vertrauen könnten. Ein anschaulicher Fall in der Docker-Welt war der „Ghostwriting“- oder Image-Layer-Tampering-Angriff, bei dem der Inhalt eines Images geändert wurde, ohne seinen Manifest-Digest zu ändern, wodurch eine naive Validierung umgangen wurde. Das Prinzip gilt allgemein für die Lieferkette: Ohne strenge Integritätsprüfungen können Angreifer unbemerkte Änderungen einschleusen.
Funktionsweise: Code-Signierung und -Verifizierung sind hier die primären Verteidigungsmechanismen. Viele Paket-Ökosysteme unterstützen mittlerweile das Signieren von Paketen (z. B. npm-Paketsignaturen, PyPIs kommende Signierung usw.), und Container-Registries unterstützen die Image-Signierung (wie Docker Content Trust mit Notary oder Sigstore Cosign für Kubernetes). Werden diese nicht verwendet oder nicht erzwungen, könnte ein Angreifer, der Netzwerkverkehr abfangen oder eine Build-Pipeline kompromittieren kann, bösartige Artefakte einschleusen, die als echt akzeptiert werden. Mangelnde Integritätsprüfung umfasst auch das Nicht-Verifizieren der Abhängigkeitsintegrität: z. B. das Nicht-Abgleichen der Prüfsumme einer heruntergeladenen Bibliothek mit der vom Anbieter veröffentlichten. In CI kann das Nicht-Verifizieren der Quellidentität (z. B. das Nicht-Prüfen, ob ein Git-Commit signiert ist oder aus dem erwarteten Repository stammt) dazu führen, dass falscher Code gezogen wird. Das Szenario ist oft ein fortgeschrittener Angriff – z. B. könnte ein ausgeklügelter Angreifer eine DNS- oder BGP-Route zu Ihrem Artefakt-Server kompromittieren und Ihnen für kurze Zeit Malware liefern, oder einen Build-Server kompromittieren, um Binärdateien nach der Kompilierung zu ändern. Wenn Sie Signaturen/Hashes nicht überprüfen, würden Sie nichts davon merken.
Risiken: Das offensichtliche Risiko ist eine vollständige Kompromittierung der Softwareintegrität. Sie könnten Software ausliefern, die von Angreifern manipuliert wurde, wodurch alle anderen Sicherheitsmaßnahmen untergraben werden. Besonders besorgniserregend ist dies bei Installationsdateien, Updates oder Container-Images, die weit verbreitet sind – ein Angriff hier kann einen massiven Explosionsradius haben (ähnlich dem SolarWinds-Vorfall, bei dem eine Kompromittierung des Build-Systems zu einem trojanisierten Software-Update führte). Ein weiteres Risiko ist die Supply-Chain-Attestierung – wenn Sie die Integrität Ihrer Komponenten nicht beweisen können, ist es schwierig, ihnen in sicheren Umgebungen zu vertrauen. Wir sehen einen verstärkten Druck von Industrie und Regulierungsbehörden für eine verifizierte Herkunft (z. B. die US Executive Order zu sicherer Software erfordert die Überprüfung der Integrität mittels SBOM und Signaturen). Mangelnde Verifizierung kann auch einfachere Angriffe wie die Abhängigkeitsersetzung ermöglichen (ein Angreifer tauscht eine Datei oder Bibliothek auf Ihrer Build-Maschine aus, weil Sie sie nie überprüfen). Im Wesentlichen ist das Nicht-Verifizieren eine Einladung an Angreifer, kreativ zu werden, denn Sie werden sie nur erwischen, wenn etwas offensichtlich kaputtgeht – heimliche Modifikationen bleiben unbemerkt.
Abhilfe: Beginnen Sie, Signierungs- und Verifizierungspraktiken in Ihrem Entwicklungslebenszyklus zu etablieren. Aktivieren Sie die GPG- oder Sigstore-Signierung für die Pakete und Container, die Sie erstellen und verteilen, und überprüfen Sie in ähnlicher Weise Signaturen bei den Dingen, die Sie konsumieren. Überprüfen Sie beispielsweise vor der Verwendung einer Binärdatei aus einem Release deren GPG-Signatur oder vergleichen Sie zumindest ihren SHA-256-Hash mit dem offiziellen. In Container-Deployments verwenden Sie Tools wie Cosign, um Container-Images anhand erwarteter öffentlicher Schlüssel zu verifizieren oder Admission Controller einzusetzen, um unsignierte Images zu blockieren. Implementieren Sie Zero-Trust für Artefakte: Nur weil eine Datei in Ihrem Netzwerk ist, heißt das nicht, dass sie sicher ist – überprüfen Sie sie. Verwenden Sie HTTPS für alle Paket- und Artefakt-Downloads (die meisten tun dies standardmäßig, aber stellen Sie sicher, dass niemand es herabstuft). Für interne Build-Prozesse sollten Sie Techniken wie reproduzierbare Builds und das Speichern von Hashes der Build-Ausgaben in Betracht ziehen, um Manipulationen zu erkennen. Der Einsatz einer Admission Control in CI oder im Deployment, die besagt „nur Artefakte zulassen, die bekannten guten Prüfsummen oder Signaturen entsprechen“, kann eine letzte Verteidigungslinie sein, falls upstream etwas Unbemerktes passiert ist. Der Schlüssel ist, die Verifizierung automatisiert und obligatorisch zu gestalten, sodass Entwickelnde nicht manuell auf Warnungen „okay“ klicken, sondern die Pipeline ungeprüften Code ablehnt.
Aikido hilft auf vielfältige Weise, die Integrität durchzusetzen. Durch seine SBOM-Analyse und die Integration mit Signatur-Tools kann Aikido validieren, dass Ihre Abhängigkeiten und Container das sind, was sie vorgeben zu sein. Aikido kann sich beispielsweise mit Sigstore/cosign integrieren, um sicherzustellen, dass jedes über Ihre Pipeline bereitgestellte Container-Image eine gültige Signatur Ihrer Organisation aufweist – andernfalls wird es gekennzeichnet oder blockiert. Die Aikido-Plattform verfolgt auch Prüfsummen gescannter Komponenten; wenn sich der Inhalt eines Artefakts unerwartet ändert (nicht mit der SBOM oder einem früheren Scan übereinstimmt), ist das ein roter Alarm. Darüber hinaus umfassen die Schwachstellen-Datenbank und Richtlinien von Aikido Prüfungen wie „stammt dieses Paket aus einer offiziellen Quelle?“, was indirekt die Integrität abdeckt (wenn jemand eine gefälschte Paketquelle einschleust, würde Aikido dies über Metadaten-Fehlübereinstimmungen erkennen). Durch die Integration von Aikido erhalten Teams einen automatisierten Integritäts-Gatekeeper. Es stellt sicher, dass von Code-Commit über Build bis zur Artefakt-Bereitstellung jedes Element nachvollziehbar und vertrauenswürdig ist. In Kombination mit den anderen Praktiken (Scanning, Secrets-Management usw.) gibt dies Entwickelnden die Gewissheit, dass ihre Software-Lieferkette durchgängig sicher ist, wobei Aikido jedes Glied in der Kette überprüft.
Fazit: Sichern Sie Ihre Lieferkette vom ersten Tag an
Lieferkettenangriffe auf Software mögen komplex klingen, aber wie wir gesehen haben, nutzen sie oft eher grundlegende Lücken aus: ungeprüfte Abhängigkeiten, ungesicherte Pipelines, durchgesickerte Anmeldeinformationen und unbestätigte Artefakte. Die gute Nachricht ist, dass Entwicklungsteams durch das Bewusstsein für diese gängigen Schwachstellentypen proaktive Schritte unternehmen können, um die Lücken zu schließen. Sicherheit ist nicht die Aufgabe anderer – sie beginnt am ersten Tag der Entwicklung und setzt sich durch jeden Commit, Build und jede Bereitstellung fort. Ein entwickelndenfreundlicher Sicherheitsansatz bedeutet, Praktiken wie das Scannen von Softwareabhängigkeiten, Secrets detection und CI/CD-Auditing in den täglichen Workflow zu integrieren, anstatt sie als nachträgliche Überlegungen zu behandeln.
Die Bedrohungen sind real und nehmen zu – von bösartigen npm-Paketen bis hin zu CI-Pipeline-Verletzungen – aber mit der richtigen Denkweise und den richtigen Tools können Sie die Nase vorn haben. Ermutigen Sie Ihr Team, eine gute „Lieferkettenhygiene“ zu praktizieren: Überprüfen Sie, was Sie importieren, rotieren und schützen Sie Secrets, sichern Sie Ihren Build-Prozess und verifizieren Sie alles. Automatisieren Sie so viel wie möglich mit modernen DevSecOps-Tools. Tatsächlich kann die Nutzung von Plattformen wie Aikido Security dies erheblich erleichtern. Aikido fungiert als Ihr intelligenter Sicherheitsassistent, der riskante Abhängigkeiten und Konfigurationen frühzeitig erkennt und Sie mit (oft automatisierten) Korrekturen anleitet, bevor sie zu Vorfällen werden.
Warten Sie nicht, bis ein aufsehenerregender Angriff zum Handeln zwingt. Übernehmen Sie jetzt die Kontrolle über Ihre Software-Lieferkettensicherheit. Beginnen Sie damit, Sicherheitstools in Ihre CI/CD-Pipeline und IDE zu integrieren – probieren Sie zum Beispiel Aikidos kostenloses Entwickelnden-Toolkit aus, um Ihre Abhängigkeiten und Pipelines auf Schwachstellen und Secrets zu scannen. Klären Sie Ihre Entwickelnden über diese Bedrohungen auf, damit sie zu Akteuren im Schutz werden und nicht nur zu Konsumenten von Open Source. Mit Wachsamkeit und der Unterstützung intelligenter Sicherheitsautomatisierung können Sie Software mit der Gewissheit bereitstellen, dass Ihre Lieferkette – von Code bis zur Cloud – widerstandsfähig gegenüber Angreifern ist. Sicheres Codieren und Bauen ist kein Hindernis für die Geschwindigkeit, sondern eine Investition in das Vertrauen und die Zuverlässigkeit Ihres Produkts. Ermöglichen Sie Ihrem Team, diese Praktiken noch heute zu übernehmen, und Sie werden das Risiko, das nächste warnende Beispiel für Lieferkettenangriffe zu werden, erheblich reduzieren. Viel Spaß (und Sicherheit) beim Codieren!
Weiterlesen:
Die 9 häufigsten Docker Containersicherheits-Schwachstellen
Die 7 häufigsten Cloud-Sicherheits-Schwachstellen
Die 10 wichtigsten Webanwendungs-Sicherheits-Schwachstellen, die jedes Team kennen sollte
Die 9 häufigsten Kubernetes-Sicherheits-Schwachstellen und Fehlkonfigurationen
Die häufigsten Code-Sicherheits-Schwachstellen in modernen Anwendungen
Die 10 häufigsten Python-Sicherheits-Schwachstellen, die Entwickelnde vermeiden sollten
Die häufigsten JavaScript-Sicherheits-Schwachstellen in modernen Web-Apps
