Top Sicherheit der Software-Lieferkette erklärt

Einleitung: Wann haben Sie das letzte Mal die Abhängigkeiten und Build-Prozesse hinter Ihrer Software überprüft? Die unangenehme Wahrheit ist, dass jede Open-Source-Bibliothek, die Sie npm installJedes Docker-Image, das Sie herunterladen, und jedes Skript in Ihrer CI-Pipeline ist ein potenzieller Angriffsvektor. Die moderne Entwicklung stützt sich stark auf externe Komponenten und Automatisierung, was einer neuen Art von Bedrohungen für die Software-Lieferkette Tür und Tor geöffnet hat. Tatsächlich Lieferkettenangriffe sprunghaft zugenommen – Sonatype berichtet von der Entdeckung über 700.000 bösartige Open-Source-Pakete seit 2019. Und erst kürzlich führte die Kompromittierung eines einzigen npm-Maintainer-Kontos dazu, dass 18 weit verbreitete Pakete mit Hintertüren mit Malware, wodurch wöchentlich Milliarden von Downloads gefährdet sind. Diese Vorfälle unterstreichen, warum Entwicklungsteams, DevOps-Ingenieure und DevSecOps sich Sicherheit der Software-Lieferkette mehr denn je um Sicherheit der Software-Lieferkette kümmern müssen.

Eine „Sicherheitslücke in der Software-Lieferkette“ bezieht sich auf jede Schwachstelle in den Prozessen oder Komponenten, die zur Erstellung und Bereitstellung Ihres Codes beitragen – von Paketen von Drittanbietern bis hin zu Build-Tools und CI/CD-Workflows. Angreifer haben erkannt, dass sie unzählige nachgelagerte Anwendungen kompromittieren können, indem sie eine vorgelagerte Komponente infizieren. Im weiteren Verlauf dieses Beitrags werden neun der kritischsten und häufig übersehenen Sicherheit der Software-Lieferkette aufgeführt. Für jede Schwachstelle erklären wir, wie sie funktioniert, wie sie sich in realen Projekten manifestieren kann, welche Risiken sie birgt und wie sie gemindert werden kann. Wir fügen auch Hinweise Aikido hinzu, um zu veranschaulichen, wie moderne Sicherheitstools (wie der Abhängigkeitsscanner, secrets , SBOM und das CI/CD-Scanning Aikido) dabei helfen, diese Probleme zu identifizieren oder zu verhindern.

Die 9 größten Schwachstellen in der Software-Lieferkette

1. Bösartige Typosquatting-Pakete

Einer der einfachsten Lieferkettenangriffe Typosquatting – wo Angreifer bösartige Pakete unter falschen Namen in Registries (npm, PyPI, RubyGems usw.) hochladen fast identisch mit beliebten BibliothekenDas Ziel besteht darin, Entwickler (oder deren automatisierte Tools) durch falsche Eingabe oder falsche Identifizierung des Paketnamens dazu zu verleiten, den Betrüger zu installieren. Beispielsweise haben sich Angreifer als Pakete wie Typescript-ESLint auf npm mit Namen wie @typescript_eslinter/eslint, das vor seiner Entdeckung tausende Male heruntergeladen wurde. Diese gefälschten Pakete enthalten oft versteckte Malware: Sie können ein Skript nach der Installation ausführen, das einen Trojaner installiert oder Daten ausspäht. In einem Fall installierte ein Typosquat eines Code-Formatierers unbemerkt ein bösartige ausführbare Datei (hübscher.bat), die beim Start von Windows bestehen blieben.

So funktioniert's: Angreifer beobachten beliebte Bibliotheken und erstellen ein bösartiges Paket mit einem Namen, der ein häufige Rechtschreibfehler oder VariantenDies kann so subtil sein wie ein fehlendes Bindestrich (Typen-Knoten gegen das Legitime @Typen/Knoten) oder einen anderen Namespace. Sie veröffentlichen diese Pakete im öffentlichen Repository mit einer verlockenden Versionsnummer oder Beschreibung. Ahnungslose Entwickler könnten sich beim Namen vertippen oder in Eile das falsche Paket auswählen und so den bösartigen Code herunterladen. Automatisierte Skripte und CI-Systeme sind ebenso anfällig, wenn der Paketname auch nur um ein Zeichen falsch ist.

Risiken: Nach der Installation läuft das schädliche Paket mit denselben Berechtigungen wie Ihre Anwendungsversion. Es kann Umgebungsvariablen (secrets) stehlen, Hintertüren installieren oder Malware der zweiten Stufe herunterladen. In Unternehmensumgebungen kann sich eine einzige infizierte Abhängigkeit auf viele Anwendungen oder Dienste ausbreiten. Diese Angriffe sind heimtückisch, da Entwickler den Fehler oft erst bemerken, wenn der Schaden bereits angerichtet ist. Das Vertrauen, das wir in Paketmanager setzen, kann missbraucht werden, um Code auf Entwicklerrechnern oder CI-Runnern auszuführen, was möglicherweise zu gestohlenen Anmeldedaten, Datenexfiltration und kompromittierten Servern führen kann.

Abwehrmaßnahmen: Um sich gegen Typosquatting zu schützen, sollten Entwickler Paketnamen doppelt überprüfen und nur Bibliotheken aus offiziellen oder verifizierten Quellen installieren. Aktivieren Sie 2FA für Paketregistrierungskonten (um zu verhindern, dass Angreifer ähnliche Bereiche oder Profile erstellen). Viele Ökosysteme bieten mittlerweile die Signierung oder Verifizierung von Paketen an – nutzen Sie diese Funktionen, um die Authentizität sicherzustellen. Der Einsatz automatisierter Tools ist ebenfalls von entscheidender Bedeutung. Ein Dependency-Scanner kann beispielsweise verdächtige Pakete oder Namen markieren, die nicht mit bekannten offiziellen Bibliotheken übereinstimmen. Die Verwendung einer „Allow-Liste“ mit genehmigten Paketen oder Paket-URL-Identifikatoren (pURL) kann verhindern, dass etwas installiert wird, das nur auf den ersten Blick korrekt erscheint. Schulen Sie Ihr Team, beim Hinzufügen neuer Abhängigkeiten wachsam zu sein.

Der Abhängigkeitsscanner Aikidokann bekannte schädliche Pakete und Typosquat-Varianten automatisch erkennen, bevor sie in Ihren Build gelangen. Beispielsweise kann Aikido SafeChain Feature-Blöcke, die brandneu oder bekanntermaßen bösartig sind, werden blockiert, um diese Gefahr zu verhindern. npm install vom Erfolg. Durch das Scannen des Manifests und der Lockfiles Ihres Projekts Aikido dabei, sicherzustellen, dass React-Router ist tatsächlich der echte React Router – keine Malware-Fälschung. Diese Art von proaktivem Scannen und Richtlinien (z. B. die Anforderung, dass Pakete ein bestimmtes Alter oder eine bestimmte Popularität aufweisen müssen) kann Typosquatting-Angriffe frühzeitig stoppenund Ihre Lieferkette sauber halten.

2. Abhängigkeitsverwirrung (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 die Art und Weise 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 dem gleichen Namen und einer höheren Version veröffentlichen, um den Resolver zu „verwirren“. Das Ergebnis? Ihr Build-System zieht möglicherweise den Code des Angreifers aus dem öffentlichen Register, anstatt das von Ihnen beabsichtigte interne Paket. Dieser Angriffsvektor wurde 2021 von dem Sicherheitsforscher Alex Birsan demonstriert, als er Dutzende großer Technologieunternehmen (Apple, Microsoft, Tesla usw.) hackte, indem er gefälschte Pakete hochlud, die mit den internen Projektnamen dieser Unternehmen übereinstimmten.

Wie es sich äußert: Angenommen, Ihr Unternehmen verfügt über ein internes npm-Paket namens @acme/Widget-Kern in Version 1.3.0, gehostet in einer privaten Registrierung. Die package.json-Anforderungen Ihres Projekts @acme/Widget-KernWenn ein Angreifer veröffentlicht @acme/Widget-Kern Version 9.9.9 an npm (öffentlich) und Ihr Build ist nicht an die private Quelle gebunden, könnte der Paketmanager die Version 9.9.9 aus dem öffentlichen Register abrufen (da er sie für eine neuere Version hält). Das bösartige Paket könnte eine Postinstall-Skript das bei der Installation automatisch ausgeführt wird und die Ausführung von Remote-Code in Ihrer Build-Umgebung ermöglicht. In CI/CD-Pipelines ist dies besonders gefährlich: Der Code wird auf Build-Agenten ausgeführt, die möglicherweise Zugriff auf sensible Umgebungsvariablen, Quellcode und Bereitstellungsschlüssel haben.

Risiken: Verwirrung hinsichtlich Abhängigkeiten kann zu einer unmittelbaren Gefährdung der Build- oder Entwicklungsumgebung führen. Die schädliche Nutzlast könnte secrets API-Schlüssel, Tokens, Anmeldedaten) exfiltrieren oder Backdoors in die gebaute Anwendung einschleusen, ohne dass sich der Code in Ihrem Repository verändert. Sie umgeht effektiv die herkömmliche Codeüberprüfung oder Schwachstellenscans Ihres Repositorys, da sich der schädliche Code in einer Abhängigkeit befindet, die Sie unwissentlich heruntergeladen haben. Die Auswirkungen können schwerwiegend sein: Angreifer könnten sich lateral in Unternehmensnetzwerke bewegen (wenn Build-Server kompromittiert sind) oder bösartige Logik in Software einfügen, die an Kunden ausgeliefert wird. Angesichts der Häufigkeit von Namenskonflikten bei internen Paketen handelt es sich um eine weit verbreitete Bedrohungsfläche.

Gegenmaßnahmen: Die Vermeidung von Abhängigkeitsverwirrung erfordert eine Kombination aus Technische Kontrollen und Hygiene. Immer Legen Sie den Geltungsbereich Ihrer privaten Pakete explizit fest. und konfigurieren Sie Ihre Paketmanager so, dass sie für bestimmte Namespaces private Registries bevorzugen. Paketmanager-Einstellungen wie die von npm @acme:Registrierung in .npmrc oder den Indexeinstellungen von pip sollte verwendet werden, um Sperren Sie Abhängigkeiten zur beabsichtigten Quelle.. Verwenden Strenge Versionsbindung und Lockfiles, sodass Ihr Build auch dann nicht automatisch eine höhere Version übernimmt, wenn diese an anderer Stelle verfügbar ist. Überwachen Sie öffentliche Paketregister auf versehentlich durchgesickerte interne Paketnamen (Angreifer erraten diese häufig anhand öffentlicher Repo-Erwähnungen oder Konfigurationsdateien). Viele Unternehmen verwenden mittlerweile Artefakt-Repositorys als Proxy, sodass nur zugelassene Pakete abgerufen werden. Dadurch entsteht eine Barriere, die verhindert, dass unbekannte Pakete (selbst wenn der Name übereinstimmt) eingespielt werden. Schließlich können regelmäßige Überprüfungen der Abhängigkeitskonfigurationen und die Erstellung einer SBOM Software-Stückliste) dabei helfen, festzustellen, ob sich ein unerwartetes externes Paket eingeschlichen hat.

Die Plattform Aikidoist so ausgestattet, dass sie Szenarien mit Abhängigkeitsverwirrungen erkennen kann. Der Abhängigkeitsscanner Aikidovergleicht beispielsweise Ihr Paketmanifest mit öffentlichen und privaten Quellen. Wenn er einen Abhängigkeitsnamen findet, der auf npm/PyPI existiert, aber eigentlich intern sein sollte, gibt er eine Warnung aus. Aikido auch Richtlinien durchsetzen, um nur bestimmte Registries zuzulassen oder Namespace-Kontrollen durchzusetzen, sodass Ihre Builds nicht versehentlich auf nicht vertrauenswürdige Quellen zugreifen. Durch SBOM Aikido Transparenz darüber, welche Paketversion und Quelle genau in einem Build verwendet wurde – so lässt sich leichter erkennen und verhindern, dass ein fremdes öffentliches Paket in eine interne App gelangt. Kurz gesagt: Aikido dazu beitragen, dass das, was Sie erstellen, genau Ihren Vorstellungen entspricht und keine überraschenden Codes enthält.

3. Entführte Bibliotheken und Protestware (kompromittierte Maintainer)

Nicht alle Lieferkettenangriffe von neuen, gefälschten Paketen – manchmal Vertrauenswürdige Pakete werden bösartig aufgrund von Kompromittierungen des Maintainer-Kontos oder vorsätzlicher Sabotage. Wenn ein Angreifer die Kontrolle über ein legitimes Paket erlangt (durch Phishing des Maintainers, Diebstahl von Anmeldedaten oder Ausnutzung laxer Sicherheitsvorkehrungen), kann er ein Trojanisiertes Update dass Verbraucher sie herunterladen, weil sie denken, es sei eine normale neue Version. Dies geschah in September 2025, als ein als „qix“ bekannter Betreuer phishingbetrogen und Angreifer haben bösartige Updates an 18 beliebte npm-Bibliotheken geschickt, darunter debug, chalk, und ansi-regexDiese Bibliotheken verzeichneten zusammen mehrere Milliarden Downloads pro Woche, was bedeutet, dass die Auswirkungen von nur zwei Stunden Verfügbarkeit des Schadcodes enorm waren. Ein weiteres Szenario ist „Protestware, bei dem ein Open-Source-Maintainer seine Bibliothek absichtlich verä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 seit Jahren vertrauen und das Sie seit Jahren verwenden, plötzlich zu einem Waffe gegen dich.

So funktioniert es: Angreifer zielen auf Pakete mit großer Reichweite ab – oft solche, die tief in Abhängigkeitsbäumen verborgen sind, sodass Entwickler ein Update möglicherweise nicht bemerken. Zu den gängigen Taktiken gehören das Phishing von Anmeldedaten von Maintainern (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 sehr ausgeklügelt sein. Beim npm-Angriff von 2025 handelte es sich bei dem injizierten Code um einen Krypto-Wallet-Stealer, der nur in Browser-Kontexten aktiviert wurde. Andere Backdoors können Umgebungsdaten sammeln, Reverse-Shells öffnen oder Daten verschlüsseln (im Stil von Ransomware). Da die Version semantisch weiterhin gültig ist (z. B. 4.4.2 bis 4.4.3) und das Paket oft abgesehen von den versteckten bösartigen Nebenwirkungen weiterhin normal funktioniert, kann es sich vor seiner Entdeckung weit verbreiten. Benutzer entdecken die Kompromittierung in der Regel erst, wenn Sicherheitsscanner ungewöhnliches Verhalten melden oder wenn die Community/öffentliche Register dies bekannt geben.

Risiken: Das offensichtliche Risiko besteht darin, dass Sie unter dem Deckmantel einer vertrauenswürdigen Abhängigkeit bösartigen Code ausführen. Dies kann zum Diebstahl sensibler Informationen führen (die Malware des npm-Vorfalls zielte auf Kryptotransaktionen ab, könnte aber genauso gut 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. Darüber hinaus untergraben diese Angriffe das Vertrauen in das Ökosystem; Teams könnten aus Angst Updates einfrieren (und damit 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 sich mit dem Angreifer verbinden.

Abwehrmaßnahmen: Die Abwehr von gekaperten Paketen ist schwierig, da es sich um einen Vertrauensbruch handelt. Es gibt jedoch bewährte Verfahren, um den Schaden zu begrenzen. Behandeln Sie Aktualisierungen von Abhängigkeiten mit gesunder Skepsis: Überprüfen Sie Änderungsprotokolle und Unterschiede neuer Versionen, insbesondere bei Kernprogrammen, die normalerweise nicht oft aktualisiert werden. Nutzen Sie automatisierte Malware-Scans für neue Paketversionen – einige Tools analysieren das Verhalten von Paketen (z. B. erkennen sie, wenn eine neue Version plötzlich Netzwerkaufrufe tätigt oder Systeminformationen liest). Das Festlegen von Versionen (und das Verzicht auf automatische Upgrades auf die neueste Version ohne Überprüfung) kann Zeit gewinnen, um Berichte aus der Community zu beobachten. Die Verwendung von Lockfiles und Prüfsummenüberprüfung (wie von npm, dem Hash-Prüfmodus von pip usw. unterstützt) kann sicherstellen, dass Sie genau das installieren, was Sie erwarten – und erwägen Sie die Aktivierung von 2FA und die Überprüfung Ihrer eigenen Pakete, wenn Sie solche veröffentlichen. Aus prozessualer Sicht sollten Sie ein Inventar Ihrer Abhängigkeiten (eine SBOM) führen, damit Sie schnell erkennen können, ob Sie ein kompromittiertes Paket verwenden und reagieren müssen.

Die kontinuierliche Abhängigkeitsüberwachung Aikidoglänzt hier. Der Scanner Aikidoüberprüft nicht nur auf bekannte CVEs, sondern achtet auch auf verdächtiges Verhalten in Bezug auf Pakete und bekannte Malware-Signaturen in Abhängigkeiten. Wenn beispielsweise eine neue Version von Anfragen auf PyPI plötzlich versucht, bei der Installation Netzwerkverbindungen zu öffnen, Aikido diese Anomalie melden. Aikido 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. Darüber hinaus Aikidomit AutoFix und Schwachstellen-FeedsWenn eine bösartige Version durchrutscht, kann die Plattform eine Korrektur empfehlen und sogar automatisch einen Fix-PR öffnen, um zu einer sicheren Version zurückzukehren oder ein Upgrade durchzuführen. Der Schlüssel ist Geschwindigkeit – Aikido , diese Vorfälle frühzeitig zu erkennen und Automatisieren Sie Ihre Antwort, wodurch das Expositionsfenster verkürzt wird.

4. Aufgedeckte Secrets Zugangsdaten in Code oder CI

Es wird oft gesagt, dass Anmeldedaten und secrets der Schlüssel zum Königreich secrets . Im Zusammenhang mit der Sicherheit der Lieferkette können durchgesickerte secrets API-Schlüssel, Cloud-Anmeldedaten, Signaturschlüssel usw.) genauso gefährlich sein wie jede Malware. Warum? Weil ein Angreifer, der einen gültigen AWS-Schlüssel oder CI/CD-Token in Ihrem GitHub-Repo oder Ihren Build-Protokollen findet, diesen direkt nutzen kann, um in Ihre Systeme einzudringen oder Ihre Pipeline zu vergiften. Durchgesickerte Anmeldedaten sind eine der Hauptursachen für Sicherheitsverletzungen – laut dem Verizon Data Breach Report wurden 22 % der Sicherheitsverletzungen im Jahr 2024 durch offengelegte Anmeldedaten verursacht. In Bezug auf die Lieferkette können secrets Quellcode oder secrets der Konfiguration Angreifern ermöglichen, betrügerischen Code (unter Verwendung Ihrer Anmeldedaten) zu veröffentlichen, auf private Paketregister zuzugreifen oder bösartige Artefakte in Ihre Bereitstellungen einzuschleusen.

Wie es sich äußert: Secrets auf vielfältige Weise bekannt werden. Ein Entwickler könnte versehentlich einen .env Datei mit Datenbankkennwörtern in ein öffentliches Repository. Oder eine CI/CD-Pipeline könnte ein sensibles Token in Protokollen ausgeben, die für alle lesbar sind. Noch subtiler könnte ein Angreifer, der sich zunächst Zugriff verschafft hat, Ihre Codebasis nach fest codierten Schlüsseln durchsuchen. Sobald er diese secrets erhalten hat, secrets verwenden, um sich als Ihr Konto auszugeben. Mit einem AWS-Schlüssel könnte ein Angreifer beispielsweise ein manipuliertes container in Ihr privates ECR-Register übertragen, das dann von Ihrer Bereitstellung abgerufen wird. Ein persönlicher GitHub-Zugriffstoken könnte es einem Angreifer ermöglichen, Code in Ihr Repo zu übertragen oder Ihre Releases zu manipulieren. In CI-Pipelines kann ein Angreifer, der an Anmeldedaten für CI oder Cloud gelangt, die normale Codeüberprüfung effektiv umgehen und direkt bösartige Komponenten oder Infrastruktur einfügen.

Risiken: Das unmittelbare Risiko besteht in unbefugtem Zugriff. Offengelegte Cloud-Schlüssel können zu Infrastrukturverletzungen oder Datendiebstahl führen. Offengelegte Anmeldedaten für Paketregister könnten es einem Angreifer ermöglichen, eine neue Version einer internen Bibliothek mit Malware zu veröffentlichen (ein weiterer Weg zum Szenario eines gekaperten Pakets). In CI könnten durchgesickerte Token Angreifern ermöglichen, Build-Konfigurationen zu ändern, secrets Tresoren abzurufen oder Artefakte abzufangen. Im Wesentlichen secrets wie Generalschlüssel: Sobald der Angreifer sie hat, kann er sich oft durch Ihre Systeme bewegen, ohne eine Software-Sicherheitslücke ausnutzen zu müssen. Dies kann zu einer vollständigen Kompromittierung der Produktionsumgebung führen oder dazu, dass Angreifer unbemerkt Artefakte verändern (z. B. indem sie eine Binärdatei in einer Release-Pipeline durch eine mit einer Hintertür versehene ersetzen). Diese Szenarien sind Teil von Lieferkettenangriffe die Integrität des Software-Lieferprozesses durch gestohlenes Vertrauen verletzt wird.

Abhilfe: Die beste Abhilfe besteht darin, secrets nicht secrets preiszugeben. Das ist leichter gesagt als getan, aber es gibt konkrete Vorgehensweisen: Verwenden Sie Secret-Scanning-Tools in Ihren Repositorys, um API-Schlüssel oder Passwörter zu erkennen, bevor sie committet werden. Git-Anbieter wie GitHub haben Secret-Scanning integriert – aktivieren Sie es. Codieren Sie sensible Anmeldedaten niemals fest in den Code ein, sondern verwenden Sie stattdessen Umgebungsvariablen oder Secret-Management-Dienste (und stellen Sie sicher, dass Ihre Repositorys diese Werte nicht in Konfigurationsdateien enthalten). Maskieren Sie in CI/CD secrets Protokollen (die meisten Plattformen bieten Optionen, um das Ausgeben geheimer Umgebungsvariablen zu verhindern). Wechseln Sie Schlüssel regelmäßig, damit sie im Falle einer Offenlegung nur für einen kurzen Zeitraum gültig sind. Wenden Sie das Prinzip der geringsten Privilegien an: Ein offengelegt Token, das nur Lesezugriff hat, ist weit weniger schädlich als ein Admin-Token. Setzen Sie für alle Schlüssel mit hohen Privilegien nach Möglichkeit Multi-Faktor- oder IP-Beschränkungen durch. Überwachen Sie die Verwendung von secrets wenn beispielsweise ein Schlüssel, der nur von Ihrer App verwendet werden sollte, plötzlich an anderer Stelle verwendet wird, ist das ein Warnsignal.

Die secrets Aikidowurde entwickelt, um offengelegte Anmeldedaten frühzeitig zu erkennen. Sie durchsucht Ihren Code, Ihre Konfigurationsdateien und sogar Ihre CI-Pipeline-Definitionen nach Mustern, die mit API-Schlüsseln, privaten Schlüsseln, Tokens und mehr übereinstimmen. Wenn beispielsweise jemand versehentlich einen persönlichen GitHub-Zugriffstoken oder einen geheimen AWS-Schlüssel committet, Aikido dies Aikido sofort gemeldet, sodass Sie ihn löschen und rotieren können. Die Erkennung ist jedoch nur ein Teil der Geschichte – Aikido in Ihre CI integriert werden, um einen Build abzubrechen, wenn ein Geheimnis gefunden wird, und so die versehentliche Bereitstellung sensibler Informationen zu verhindern. Es hilft auch dabei, einen Überblick darüber zu behalten, welche secrets wo secrets , und ergänzt so die Verwendung von Tresoren oder Geheimnismanagern. Durch die Integration secrets in den Entwicklungs-Workflow (IDE-Plugins, Pre-Commit-Hooks, CI-Checks) Aikido Entwicklern, Anmeldedaten aus Repositorys und Pipelines fernzuhalten und damit einen der einfachsten Wege für Angreifer bei Supply-Chain-Verstößen zu unterbinden.

5. Unsichere CI/CD-Pipeline-Konfigurationen (Pipeline als Angriffsfläche)

Ihre CI/CD-Pipeline ist praktisch die Fertigungsstraße Ihrer Softwarefabrik – und wenn sie falsch konfiguriert oder unsicher ist, können Angreifer alles manipulieren, was diese Fertigungsstraße verlässt. CI/CD-Systeme (wie GitHub Actions, Jenkins, GitLab CI usw.) haben oft einen umfassenden Zugriff: Sie ziehen Code, integrieren Abhängigkeiten, führen Tests durch, pushen Artefakte und stellen sogar in der Produktion bereit. Das macht sie zu einem attraktiven Ziel. Häufige Pipeline-Sicherheit sind zu weitreichende Zugriffsberechtigungen, mangelnde Isolierung und die Verwendung unsicherer Standardeinstellungen. Eine aktuelle Analyse ergab, dass etwa 23,8 % der Lieferkettenangriffe Schwachstellen im CI/CD-Build Lieferkettenangriffe , was unterstreicht, dass Pipeline-Sicherheit mittlerweile ein wichtiges Thema Pipeline-Sicherheit . In der Praxis haben wir Vorfälle gesehen, bei denen Angreifer CI-Fehlkonfigurationen ausnutzten, um sich lateral zu bewegen. Beispielsweise kann ein falsch konfigurierter Jenkins-Server, der für das Internet offen ist, oder ein CI-Job, der versehentlich nicht vertrauenswürdigen Code ausführt (z. B. das Erstellen von PRs von externen Mitwirkenden ohne Sandboxing), zu einer Kompromittierung führen.

Wie sich das äußert: Ein Szenario sind Pipeline-Runner mit übermäßigen Berechtigungen. Stellen Sie sich einen CI-Agenten vor, der Administratorzugriff auf Ihre Cloud hat oder Artefakte direkt bereitstellen darf. Wenn ein Angreifer sich in die CI einschleusen kann (durch eine Code-Injektion, kompromittierte Anmeldedaten oder Ausnutzung des CI-Tools), hat er nun praktisch die „Schlüssel zum Königreich“ – er kann Malware in Builds einschleusen oder sogar den CI-Agenten verwenden, um Befehle in Ihrer Infrastruktur auszuführen. Ein weiteres Szenario ist die Nichtdurchsetzung von Überprüfungen eingehender Codes: Beispielsweise könnte ein böswilliger Pull-Request, der eine CI-Konfigurationsänderung zum Exfiltrieren secrets zum Überspringen von Tests enthält, durchrutschen, wenn die Codeüberprüfungen lax sind. Außerdem mounten viele CI-Pipelines secrets wie Signaturschlüssel oder Berechtigungsnachweise für die Bereitstellung) als Umgebungsvariablen. Wenn die Pipeline nicht so konfiguriert ist, dass sie einschränkt, wer Builds auslösen darf oder welcher Code ausgeführt wird, secrets diese secrets von Angreifern gestohlen werden, die den Build manipulieren. Beispielsweise können einige Standardkonfigurationen es Fork-Repository-PRs ermöglichen, die Haupt-CI mit Zugriff auf secrets auszuführen secrets eine bekannte gefährliche Einstellung, die secrets böswillige Mitwirkende weitergeben kann.

Risiken: Wenn die CI/CD-Pipeline kompromittiert wird, erhält ein Angreifer direkten Zugriff auf die Software während der Erstellung oder Bereitstellung. Dies kann dazu führen, dass nicht autorisierter Code in die Produktion oder an Benutzer gelangt (stellen Sie sich vor, dass während der Erstellung bösartiger Code hinzugefügt wird, der nie in der Quellcodeverwaltung vorhanden war). Es kann auch zu einer weitreichenden Offenlegung von Daten führen, da CI-Systeme häufig Protokolle oder Artefakte mit sensiblen Informationen enthalten. Eine unsichere Pipeline kann missbraucht werden, um sich anderweitig Zugang zu verschaffen – wenn Ihr Jenkins-Server beispielsweise Netzwerkzugriff auf interne Dienste hat, kann ein Angreifer, der Jenkins kompromittiert, diese Dienste ausnutzen. Im Wesentlichen ist eine anfällige CI ein Einstiegspunkt sowohl für Ihr Softwareprodukt als auch für Ihre Infrastruktur. Es handelt sich dabei auch um einen häufig übersehenen Bereich – Entwicklerteams konzentrieren sich auf die Sicherheit des App-Codes, prüfen die Pipeline jedoch möglicherweise nicht mit derselben Sorgfalt.

Abhilfe: Um CI/CD-Pipelines zu sichern, müssen sie als Produktionsressourcen behandelt werden. Sperren Sie zunächst den Zugriff: Stellen Sie sicher, dass Ihr CI-System nicht offen zugänglich ist, verwenden Sie VPNs oder IP-Zulassungslisten und verlangen Sie eine Authentifizierung für die Auslösung sensibler Jobs. Wenden Sie das Prinzip der geringsten Privilegien auf Pipeline-Anmeldedaten an – wenn ein Build-Job beispielsweise nur Push-Zugriff auf ein Artefakt-Repository benötigt, gewähren Sie ihm keine Cloud-Administratorrechte. Verwenden Sie separate Anmeldedaten für separate Jobs/Phasen. Zweitens: Bereinigen Sie Eingaben: 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. Bei vielen CI-Plattformen können Sie secrets markieren secrets sie für geforkte PRs nicht verfügbar sind. Aktivieren Sie die Audit-Protokollierung in Ihrer Pipeline: So wissen Sie, wer was in den Build-Konfigurationen geändert hat. Eine weitere wichtige Maßnahme ist das Fixieren Ihrer CI-Abhängigkeiten – wenn Ihre Pipeline Build-Container oder Aktionen/Plugins von Drittanbietern verwendet, fixieren Sie diese auf bestimmte Versionen oder Hashes (vermeiden Sie „neueste“ 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 auch in CI-Tools selbst Schwachstellen auftreten können. Erwägen Sie schließlich, für jeden Build (sofern möglich) kurzlebige, isolierte Runner zu verwenden, damit ein kompromittierter Build dem Angreifer keinen dauerhaften Zugang verschafft.

Aikido CI/CD-Sicherheit , mit denen Sie Ihre Pipeline-Konfigurationen auf Best Practices und potenzielle Fehlkonfigurationen überprüfen können. So Aikido beispielsweise Ihre GitHub Actions-Workflows oder Jenkins-Dateien analysieren, um Probleme wie nicht fixierte Aktionen, die Verwendung von selbst gehosteten Runners mit weitreichenden Berechtigungen oder secrets in geforkten PRs secrets , zu kennzeichnen. Es fungiert wie ein Linter für CI-Sicherheit. Die Plattform Aikidolässt sich auch in CI-Pipelines integrieren, um Richtlinien durchzusetzen: Wenn jemand versucht, einen Deployment-Job aus einem nicht autorisierten Branch auszuführen, oder wenn eine wichtige Workflow-Datei in einem PR geändert wurde, Aikido zusätzliche Genehmigungen verlangen. Durch kontinuierliches Scannen der Pipeline-Einrichtung Aikido , dass Ihre „Software-Fabrik” gut geschützt ist – keine offenen Türen, keine einfachen Möglichkeiten für Angreifer, den Prozess zu kapern. Stellen Sie sich das als einen CI/CD-Konfigurationswächter vor, der mit Ihrem DevOps-Team zusammenarbeitet.

6. Gefährliche Pipeline-Abhängigkeiten (CI/CD-Tools und -Aktionen von Drittanbietern)

Moderne Pipelines ziehen oft eine Vielzahl von Tools von Drittanbietern, Docker-Images, Skripte und Aktionen um Aufgaben (wie Codeabdeckung, Bereitstellungen usw.) auszuführen. Jede dieser Aufgaben 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 eindrucksvolles Beispiel dafür war die Angriff auf die reviewdog/Aktionskonfiguration GitHub Action und anschließende Kompromittierung von tj-actions/changed-files im Jahr 2025. Angreifern gelang es, bösartigen Code in diese weit verbreiteten CI-Aktionen einzuschleusen, indem sie deren Aktualisierungsprozess ausnutzten, wodurch jedes Projekt, das diese Aktionen verwendete, secrets CI-Runnern preisgab. Ähnliches gilt für Pipeline-Skripte wie den Codecov Bash Uploader (der 2021 gehackt wurde) – Tausende von Pipelines vertrauten einem Tool, das stillschweigend ihre Daten exfiltrierte. Diese Vorfälle veranschaulichen, wie ein Angreifer den Brunnen vergiften indem Sie sich auf die Tools konzentrieren, auf die Ihre Pipeline angewiesen ist.

So funktioniert's: Angreifer suchen nach beliebten CI/CD-Dienstprogrammen oder Images, die Schwachstellen in der Lieferkette aufweisen – beispielsweise einen Maintainer, der Commits nicht signiert, oder eine veraltete Abhängigkeit in einem Docker-Image. Indem sie das Upstream-Projekt kompromittieren (durch Kontoübernahme, Exploit oder Eindringen als Mitwirkender), können sie bösartigen Code einfügen. Im Fall von GitHub Actions verschaffte sich ein Angreifer Zugriff auf das Konto oder Token des Maintainers und den Aktionscode geändert, sogar die Git-Referenzen neu zu taggen, sodass das, was als „v1“ getaggt war, nun auf einen bösartigen Commit verwies. Projekte, die Verwendung: reviewdog/action-setup@v1 in ihrem Workflow plötzlich eine fehlerhafte Aktion durchgeführt hat, die secrets preisgegeben hat. Da CI-Systeme in der Regel bei jedem Durchlauf den neuesten getaggten Code abrufen, kann eine Pipeline unwissentlich veränderten Code von einem Drittanbieter ausführen. Docker-Images, die in CI (für Build oder Test) verwendet werden, sind ebenfalls gefährdet – wenn jemand ein böswilliges Update auf ein Image wie Knoten:Alpine die Ihre Pipeline verwendet, würden Sie alles ausführen, was sich in diesem Image befindet.

Risiken: Die Auswirkungen sind hier ähnlich wie bei einer Bibliotheksentführung, aber potenziell noch direkter. CI-Tools werden oft mit hohen Berechtigungen ausgeführt (einige GitHub-Runner verfügen über sudo usw.) und haben Zugriff auf Anmeldedaten. Eine vergiftete Aktion oder ein vergiftetes Skript kann sofort alle Ihre secrets exfiltrieren oder Hintertüren in den zu erstellenden/zu testenden Code einschleusen. In einem realen Vorfall hat eine bösartige GitHub-Aktion secrets öffentliche Protokolle geschrieben. Ein weiteres Risiko besteht darin, dass ein kompromittiertes Build-Tool die kompilierte Ausgabe verändern könnte (stellen Sie sich einen bösartigen Compiler vor, der immer eine bestimmte Schwachstelle oder Hintertür in Binärdateien einfügt). Das Schwierige 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 auf ein Docker-Image oder eine Open-Source-Aktion, weil diese weit verbreitet sind. Das gibt Angreifern eine heimliche Möglichkeit, einzudringen, und die Sicherheitsverletzung wird möglicherweise erst viel später (wenn überhaupt) entdeckt.

Gegenmaßnahmen: Genauso wie Sie Anwendungsabhängigkeiten festlegen, Fixieren Sie Ihre Pipeline-AbhängigkeitenIn GitHub Actions wird anstelle von @v1 oder @Haupt Verwenden Sie für eine Aktion einen bestimmten Commit-SHA, damit dieser nicht unbemerkt geändert werden kann. Verwenden Sie für Docker-Images Digests oder bestimmte Versionen anstelle von aktuellsteDadurch wird sichergestellt, dass Sie jedes Mal eine bekanntermaßen funktionierende Version ausführen. Als Nächstes überprüfen und vertrauen, aber überprüfen: Bevorzugen Sie Maßnahmen oder Tools, die allgemein als vertrauenswürdig gelten. und Idealerweise sollten Sie über einen Verifizierungsmechanismus verfügen (einige Aktionen sind GitHub-verifiziert oder mit einer Signatur versehen). Überwachen Sie Upstream-Benachrichtigungen – abonnieren Sie die Sicherheits-Feeds der von Ihnen verwendeten Tools von Drittanbietern, damit Sie bei Sicherheitsverletzungen benachrichtigt werden. Verwenden Sie nach Möglichkeit kritische Pipeline-Tools von Anbietern oder selbst gehostete Tools: Anstatt beispielsweise bei der Erstellung ein zufälliges Skript aus dem Internet herunterzuladen, integrieren Sie es (nach Überprüfung) in Ihre Codebasis, damit es nicht ohne Ihr Wissen geändert werden kann. Verwenden Sie Sandboxing für riskante Schritte – führen Sie beispielsweise Linter oder Testabdeckungstools in isolierten Containern mit eingeschränktem Zugriff aus. Erwägen Sie schließlich die Einführung von Frameworks wie Googles SLSA (Supply Chain Levels for Software Artifacts) für Ihre Pipelines, die Richtlinien zur Absicherung von Build-Prozessen und zur Herkunftsnachweis für Build-Schritte enthalten.

🛡 Aikido aufruf: Das CI/CD-Scanning Aikidoerstreckt sich auch auf die Abhängigkeiten Ihrer PipelineEs wird überprüft, ob Ihre Workflows auf Aktionen mit veränderbaren Tags verweisen oder Daten aus potenziell nicht vertrauenswürdigen Quellen beziehen. Aikido beispielsweise melden, dass Sie Verwendung: someaction@latest und schlagen vor, es an einen Commit anzuhängen. Der Abhängigkeitsscanner Aikidoüberprüft nicht nur Ihren App-Code, sondern kann auch Ihre Container und Tools erstellen auf bekannte Schwachstellen oder Malware-Signaturen. Wenn Sie ein Basis-Docker-Image in CI verwenden, Aikido SBOM dieses Images scannen, SBOM sicherzustellen, dass es keine bekannten schädlichen Komponenten enthält. Im Wesentlichen Aikido , sicherzustellen, dass die Bestandteile Ihrer Pipeline genauso sicher sind wie die Bestandteile Ihrer Anwendung. Durch die Integration dieser Prüfungen Aikido , dass Ihre CI-Tools und -Aktionen keine versteckte Hintertür darstellen. Falls ein beliebtes Tool tut Wenn eine Kompromittierung auftritt, Bedrohungsaufklärung Aikidoaktualisiert, und Sie erhalten eine Warnmeldung, 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 angeheftete Versionen und veränderbare Abhängigkeiten (das „Neueste“-Problem)

Verwendung von Floating oder Nicht angeheftete Abhängigkeitsversionen ist eine Schwachstelle in der Lieferkette, die Ihnen in zweierlei Hinsicht schaden kann: Sie könnten unwissentlich einen böswilliges Update oder fehlerhaftes/anfälliges Update weil Sie immer „latest“ ziehen. Ob es sich nun um ein Docker-Basisimage mit dem Tag :latest oder einen Paketversionsbereich wie ^1.0.0 In npm bedeutet die Verwendung nicht festgelegter Versionen, dass Ihr Build heute möglicherweise eine andere Komponente abruft als gestern. Dies untergräbt die Reproduzierbarkeit des Builds und öffnet Angreifern die Tür, um ihre Angriffe zeitlich zu koordinieren. Wenn beispielsweise ein Angreifer ein Paket kompromittiert und Sie nicht auf eine bestimmte, als gut bekannte Version festlegen, wird Ihr nächster Build die kompromittierte Version abrufen. Bei dem zuvor beschriebenen Angriff auf GitHub Actions war ein Faktor, dass Projekte auf ein veränderbares Tag verwiesen (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 Auswirkungen auf Builds hatte.

So funktioniert's: Betrachten Sie ein Python-Projekt, das Anfragen >= 2,0 in seinen Anforderungen (zulässt jede neue 2.x-Version). Wenn Sie pip install ausführen, wird die neueste 2.x-Version heruntergeladen. Wenn die Betreuer (oder ein Angreifer) eine Version veröffentlichen Anfragen 2.999 morgen und es gibt Probleme, Ihre Umgebung ändert sich unerwartet. Oder stellen Sie sich vor, Ihre Dockerfile verwendet VON node:latest; Immer wenn 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 Grunde genommen die Kontrolle über Ihre Lieferkette an die Zeitpläne externer Parteien. Angreifer schätzen dies besonders, wenn sie Zugriff erhalten, um ein Update zu pushen – sie wissen, dass viele Benutzer automatisch ein Upgrade durchführen werden. Selbst ohne böswillige Akteure besteht das Risiko, dass ein fehlerhaftes Update zu Ausfällen führt oder eine Sicherheitslücke verursacht, bevor Sie es bemerken. Das berüchtigte Vorfall mit linkem Polster (wo das Entfernen eines Pakets weltweit zu Build-Fehlern führte) ist ein Beispiel dafür, was passieren kann, wenn viele Projekte implizit einer externen aktuellen Version vertrauen.

Risiken: Das Hauptrisiko besteht in mangelnder Kontrolle und Transparenz. Sie glauben vielleicht, dass Sie denselben Code erstellen, aber in Wirklichkeit hat sich eine zugrunde liegende 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 eine bösartige Logik sein. Bei Lieferkettenangriffe ist das Timing entscheidend: Wenn der Angreifer während der Erstellung kurzzeitig eine fehlerhafte Version einfügen kann, hat er gewonnen, selbst wenn diese Version später behoben wird. Nicht festgelegte 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 Version betroffen waren. Im Wesentlichen untergräbt dies die Reproduzierbarkeit und Rückverfolgbarkeit, die für sichere Builds grundlegend sind. Die Integrität von Software-Builds hängt von deterministischen Eingaben ab; „aktuellste Version” ist das Gegenteil von deterministisch.

Abhilfe: Fixieren oder sperren Sie Ihre Abhängigkeiten immer auf bekanntermaßen gute Versionen oder Digests. Verwenden Sie exakte Versionsnummern in Paketmanifesten und setzen Sie Lockfiles (package-lock.json, Pipfile.lock usw.) ein, damit alle Benutzer und Umgebungen dieselben aufgelösten Versionen verwenden. Fixieren Sie Docker-Images auf eine bestimmte Version oder besser noch auf einen Digest-SHA (der unveränderlich ist). Fixieren Sie Git-basierte Abhängigkeiten oder Aktionen auf Commit-Hashes. Wenn Sie Bereiche zulassen müssen (um kleinere Updates zu erhalten), sollten Sie die Verwendung zuverlässiger Bots oder Update-Tools in Betracht ziehen, die Sie auf neue Versionen aufmerksam machen, anstatt diese automatisch herunterzuladen. Implementieren Sie eine Richtlinie, wonach kein Build ein Artefakt verwenden darf, das nicht ausdrücklich in der Quellcodeverwaltung (oder in einer Metadatendatei) verfolgt wird. Führen Sie außerdem für jede Version eine SBOM – eine Liste der genauen Komponentenversionen in Ihrem Produkt. Auf diese Weise können Sie bei Auftreten eines Risikos (z. B. wenn Version X am Datum Y kompromittiert wurde) schnell abfragen, welche Ihrer Releases diese Version enthalten haben. Es ist auch ratsam, Ihren Abhängigkeitsaktualisierungsprozess separat zu testen – aktualisieren Sie nicht blindlings in Produktionsbuilds, sondern führen Sie einen Staging- oder CI-Job durch, der Aktualisierungen testet, damit Sie Probleme erkennen können. Letztendlich gibt Ihnen das Festlegen von Versionen die Kontrolle: Sie entscheiden nach der Überprüfung, wann Sie ein Upgrade durchführen, anstatt von Änderungen im Upstream überrascht zu werden.

Die Werkzeuge Aikidofördern nachdrücklich Abhängigkeitsfestlegung und VersionssichtbarkeitWenn Aikido eine SBOM Ihr Projekt Aikido , listet es alle Komponenten und Versionen auf und trägt so dazu bei, dass keine „schwebenden” Abhängigkeiten bestehen. Aikido auch in Ihre CI integriert werden, um Fehlgeschlagene Builds, die nicht fixierte Abhängigkeiten verwenden oder veränderbare Tags, die als Sicherheitsnetz fungieren. Wenn beispielsweise jemand FROM python:latest in einer Dockerfile oder eine GitHub-Aktion ohne festgelegten SHA hinzufügt, wird dies vom Scanner Aikidomarkiert. Darüber hinaus können die Abhängigkeitsverwaltungsfunktionen Aikidoautomatisch Pull-Anfragen öffnen, um Abhängigkeiten auf kontrollierte Weise (mit Sicherheitskontext) zu aktualisieren, sodass Sie nicht an alte Versionen gebunden sind, sondern sicher upgraden können. Durch die Verwendung Aikido Überwachung und Verwaltung Ihrer Open-Source-Komponenten erhalten Sie einen wirksamen Schutz, der sicherstellt, dass Sie wissen genau, was Sie bauen.Dieses Wissen verleiht Kraft (und Sicherheit).

8. Veraltete Komponenten mit bekannten Schwachstellen

Das andere Extrem zu den „aktuellen“ Problemen ist das Risiko, veraltete Abhängigkeiten zu verwenden , die bekannte Sicherheitslücken (CVEs) aufweisen. Hierbei handelt es sich eher um eine traditionelle Schwachstelle, die jedoch durchaus ein Problem für die Lieferkette darstellt: Ihre Software ist nur so sicher wie das schwächste Glied in ihrem Abhängigkeitsgraphen. Angreifer nutzen häufig bekannte Schwachstellen in beliebten Bibliotheken aus, die von Unternehmen nur langsam gepatcht werden. Beispielsweise kann die Verwendung einer älteren Version einer Struts-, Log4j- oder OpenSSL-Bibliothek mit einer veröffentlichten kritischen CVE zu einer Remote-Code-Ausführung oder einer Datenverletzung in Ihrer Anwendung führen – praktisch ein Versagen der Lieferkette bei der Aktualisierung. Angesichts der explosionsartigen Verbreitung von Open Source ist es eine Herausforderung, alles auf dem neuesten Stand zu halten. Software-Kompositionsanalyse (SCA) zeigen jedoch immer wieder, dass ein großer Prozentsatz der Anwendungen veraltete Bibliotheken mit bekannten Schwachstellen enthält. Wenn Sie eine anfällige Open-Source-Komponente verwenden, muss ein Angreifer möglicherweise keinen neuen Exploit schreiben – er kann einfach die vorhandene CVE gegen Sie einsetzen.

Wie es sich äußert: Häufig fügen Entwicklungsteams eine Bibliothek für bestimmte Funktionen hinzu und dann vergessen, es zu aktualisierenDiese Bibliothek könnte weitere Bibliotheken (transitive Abhängigkeiten) mit einbeziehen, und irgendwo in dieser Kette könnte sich ein kritischer Fehler befinden. Nehmen wir beispielsweise eine Node.js-Anwendung, die ein Paket einbindet, das von einer veralteten Version abhängt. lodash Version mit einer Schwachstelle aufgrund von Prototyp-Verschmutzung. Ihre App könnte über diese Schwachstelle ausgenutzt werden, selbst wenn Ihr Code einwandfrei ist. Auch in CI/CD- und Build-Tools können veraltete Komponenten lauern – vielleicht container Ihr container ein altes Betriebssystempaket mit einem Shellshock-Bug oder Ihr CI-Server selbst ist nicht gepatcht. In der Regel wird dies dadurch offensichtlich, dass ein Scanner oder Penetrationstest die bekannte CVE findet oder, schlimmer noch, ein Vorfall auftritt (z. B. wird die App über diese Komponente gehackt). Ein berüchtigter Fall war der Log4j „Log4Shell“-Sicherheitslücke (CVE-2021-44228)Viele Unternehmen wurden durch die Verwendung alter Log4j-Versionen überrascht und von Exploits in freier Wildbahn getroffen. Genau solche Szenarien sollen durch proaktive Supply-Chain-Sicherheit verhindert werden.

Risiken: Das Risiko durch bekanntermaßen anfällige Komponenten ist klar: Angreifer wissen bereits, wie sie diese ausnutzen können. Sobald eine Schwachstelle öffentlich bekannt ist, gibt es oft Proof-of-Concept-Exploits oder zumindest detaillierte Beschreibungen dazu. Angreifer durchsuchen das Internet nach Anwendungen oder Diensten, die die anfällige Komponente zu verwenden scheinen (z. B. durch Überprüfen von App-Headern oder bestimmten Verhaltensweisen). Wenn Ihre Software diese Komponente verwendet und in geeigneter Weise exponiert ist, sind Sie ein Ziel. Je nach Schwachstelle kann dies zu einer vollständigen Kompromittierung des Systems, Datendiebstahl oder Dienstausfällen führen. Abgesehen von der direkten Ausnutzung gibt es auch Probleme compliance des Kundenvertrauens – die Verwendung bekannter Schwachstellen kann gegen Vorschriften oder vertragliche Sicherheitsanforderungen verstoßen. Dies ist ein Indikator für mangelnde Sicherheitshygiene. Denken Sie daran, dass Ihre Lieferkette nicht nur den von Ihnen geschriebenen Code umfasst, sondern auch den von Ihnen verwendeten Code. Das Vernachlässigen von Updates ist wie das Hinterlassen von Lücken in Ihrer Verteidigung, die in den Playbooks der Angreifer gut dokumentiert sind.

Gegenmaßnahmen: Eine Kultur der Kontinuierliches AbhängigkeitsmanagementDas bedeutet, dass Sie Ihre Projekte (und container ) regelmäßig auf bekannte Schwachstellen überprüfen sollten. Verwenden Sie SCA , 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. Integrieren Sie dies in die CI, damit Builds eine Warnung ausgeben oder fehlschlagen, wenn neue Schwachstellen auftreten. Richten Sie einen Prozess ein (möglicherweise automatisiert über Bots wie Dependabot AikidoAutoFix), um Upgrades auf gepatchte Versionen anzuregen. Es ist wichtig, Prioritäten zu setzen – nicht alle CVEs sind gleich; konzentrieren Sie sich auf diejenigen mit hoher Schwere oder in Software, die von Ihrer Anwendung aus erreichbar ist. Stellen Sie außerdem sicher, dass Sie Aktualisieren Sie Ihre Build- und Bereitstellungsumgebung. – Halten Sie beispielsweise Ihre Basis-Docker-Images mit Sicherheitspatches auf dem neuesten Stand und aktualisieren Sie CI-Tools oder Plugins auf gepatchte Versionen. Ein weiterer wichtiger Punkt ist die Pflege einer Stückliste (SBOM) Wie bereits erwähnt, hilft Ihnen dies, schnell die Frage zu beantworten: „Verwenden wir die Bibliothek, über die diese Woche alle so aufgeregt sind?“ Als Log4Shell auftauchte, hatten Unternehmen mit einer guten SBOM Prozess konnte sofort suchen und finden, wo Log4j verwendet wurde. Abonnieren Sie schließlich Sicherheitsbulletins für die wichtigsten Projekte, die Sie verwenden, damit Sie sofort informiert werden, wenn neue Schwachstellen auftreten. Schnelles Patchen ist entscheidend; Angreifer beginnen oft innerhalb von Tagen oder sogar Stunden nach der Bekanntgabe mit der Ausnutzung beliebter CVEs.

Der Abhängigkeitsscanner und SCA Aikidowurden entwickelt, um genau dieses Problem zu lösen. Das Tool scannt Ihre Projekte, um alle Open-Source-Komponenten zu identifizieren, und gleicht diese mit einer ständig aktualisierten Schwachstellendatenbank ab. Das Ergebnis ist nicht nur eine Liste von Problemen – Aikido auch umsetzbare Informationen wie den Schweregrad, ob eine Lösung 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 einer kritischen Schwachstelle verwendet, Aikido die sichere Version vorschlagen und Ihr Projekt aktualisieren. pom.xml für Sie. Darüber hinaus Aikido in Ihren gesamten Entwicklungsworkflow (IDE-Plugins, PR-Checks, CI) Aikido , sodass bekannte Schwachstellen frühzeitig erkannt werden und nicht erst, nachdem Ihre Software in Produktion gegangen ist. Außerdem hilft es Ihnen dabei, SBOMs mühelos zu erstellen, sodass Sie einen Überblick über die Bestandteile Ihrer Software erhalten. Das bedeutet, dass Sie, wenn der nächste Zero-Day in einer gängigen Bibliothek Schlagzeilen macht, schnell Ihr Aikido abfragen können, um zu sehen, ob Sie davon betroffen sind. Über Updates auf dem Laufenden bleiben wird viel einfacher, wenn Aikido Ihnen Aikido den Rücken freihält und dafür sorgt, dass veraltete Komponenten nicht unbeachtet bleiben.

9. Fehlende Integritätsprüfung (unzureichende Signatur- und Ursprungsvalidierung)

Die letzte Schwachstelle, die hervorzuheben ist, ist eher systemischer Natur: die Nichtüberprüfung der Integrität und Herkunft von Komponenten. Mit anderen Worten: die Nichtverwendung oder Nichtüberprüfung von Signaturen, Prüfsummen oder Herkunftsangaben für den Code und die Binärdateien, die durch Ihre Software-Lieferkette fließen. Ohne Integritätsprüfung vertrauen Sie im Grunde genommen standardmäßig. Angreifer können dies ausnutzen, indem sie Artefakte manipulieren oder sich als Quellen ausgeben. Wenn Sie beispielsweise eine Bibliothek oder ein Installationsprogramm eines Drittanbieters über einfaches HTTP oder von einer Mirror-Site herunterladen, ohne einen Hash/eine Signatur zu überprüfen, könnte Ihnen ein Angreifer in der Mitte eine kompromittierte Version unterjubeln. Wenn Sie nicht überprüfen, ob ein container von einer vertrauenswürdigen Partei signiert ist, könnte Sie jemand dazu verleiten, ein ähnliches Image mit einer Hintertür auszuführen. Selbst innerhalb von CI/CD bedeutet eine fehlende Überprüfung, dass ein Angreifer, wenn er einen Schritt kompromittiert, die nachfolgenden Schritte blind den Ergebnissen vertrauen könnten. Ein anschauliches Beispiel aus der Docker-Welt war der „Ghostwriting”- oder Image-Layer-Manipulationsangriff, bei dem der Inhalt eines Images ohne Änderung seines Manifest-Digests verändert wurde, wodurch die naive Validierung umgangen wurde. Das Prinzip gilt für die Lieferkette im Allgemeinen: Ohne strenge Integritätsprüfungen können Angreifer unbemerkt Änderungen vornehmen.

So funktioniert es: Code-Signierung und -Verifizierung sind hier die wichtigsten Schutzmaßnahmen. Viele Paket-Ökosysteme unterstützen mittlerweile die Signierung von Paketen (z. B. npm-Paketsignaturen, die bevorstehende Signierung von PyPI usw.), und container unterstützen die Signierung von Images (wie Docker Content Trust mit Notary oder Sigstore Cosign für Kubernetes). Wenn diese nicht verwendet oder nicht durchgesetzt werden, könnte ein Angreifer, der entweder den Netzwerkverkehr abfangen oder eine Build-Pipeline kompromittieren kann, bösartige Artefakte einfügen, die als echt akzeptiert werden. Zur mangelnden Integritätsüberprüfung gehört auch die Nichtüberprüfung der Abhängigkeitsintegrität, z. B. wenn die Prüfsumme einer heruntergeladenen Bibliothek nicht mit der vom Anbieter veröffentlichten Prüfsumme abgeglichen wird. In CI kann die Nichtüberprüfung der Identität der Quelle (z. B. wenn nicht überprüft wird, ob ein Git-Commit signiert ist oder aus dem erwarteten Repository stammt) dazu führen, dass falscher Code abgerufen wird. Das Szenario ist oft ein fortgeschrittener Angriff – z. B. könnte ein raffinierter Angreifer eine DNS- oder BGP-Route zu Ihrem Artefakt-Server kompromittieren und Ihnen für kurze Zeit Malware servieren oder einen Build-Server kompromittieren, um Binärdateien nach der Kompilierung zu verändern. Wenn Sie Signaturen/Hashes nicht überprüfen, würden Sie davon nichts mitbekommen.

Risiken: Das offensichtliche Risiko ist eine vollständige Beeinträchtigung der Softwareintegrität. Sie könnten Software ausliefern, die von Angreifern manipuliert wurde, wodurch alle anderen Sicherheitsmaßnahmen untergraben werden. Dies ist besonders besorgniserregend bei Installationsdateien, Updates oder container , die weit verbreitet sind – ein Angriff hier kann massive Auswirkungen haben (ähnlich wie beim SolarWinds-Vorfall, bei dem eine Kompromittierung des Build-Systems zu einem mit Trojanern versehenen Software-Update führte). Ein weiteres Risiko ist die Überprüfung der Lieferkette – wenn Sie die Integrität Ihrer Komponenten nicht nachweisen können, ist es schwierig, ihnen in sicheren Umgebungen zu vertrauen. Wir beobachten einen zunehmenden Druck seitens der Industrie und der Regulierungsbehörden, die Herkunft zu überprüfen (z. B. verlangt die US-Verordnung zur Sicherheit von Software die Überprüfung der Integrität mittels SBOM Signaturen). Das Fehlen einer Überprüfung kann auch einfachere Angriffe wie die Substitution von Abhängigkeiten ermöglichen (ein Angreifer tauscht eine Datei oder Bibliothek auf Ihrem Build-Rechner aus, weil Sie diese nie überprüfen). Im Wesentlichen ist das Nichtüberprüfen eine Einladung für Angreifer, kreativ zu werden, da Sie sie nur dann erwischen, wenn etwas offensichtlich kaputt geht – heimliche Änderungen bleiben unbemerkt.

Abhilfe: Führen Sie Signatur- und Verifizierungsverfahren in Ihrem Entwicklungszyklus ein. Aktivieren Sie die GPG- oder Sigstore-Signatur für die von Ihnen erstellten und vertriebenen Pakete und Container und überprüfen Sie in ähnlicher Weise die Signaturen der von Ihnen verwendeten Elemente. Überprüfen Sie beispielsweise vor der Verwendung einer Binärdatei aus einer Version deren GPG-Signatur oder vergleichen Sie zumindest deren SHA-256-Hash mit dem offiziellen Hash. Verwenden Sie bei container Tools wie Cosign, um container anhand der erwarteten öffentlichen Schlüssel zu überprüfen, oder nutzen Sie Zulassungscontroller, um nicht signierte Images zu blockieren. Implementieren Sie Zero Trust für Artefakte: Nur weil sich eine Datei in Ihrem Netzwerk befindet, bedeutet das nicht, dass sie sicher ist – überprüfen Sie sie. Verwenden Sie HTTPS für alle Paket- und Artefakt-Downloads (die meisten tun dies mittlerweile standardmäßig, aber stellen Sie sicher, dass niemand ein Downgrade vornimmt). Für interne Build-Prozesse sollten Sie Techniken wie reproduzierbare Builds und die Speicherung von Hashes der Build-Ausgaben in Betracht ziehen, um Manipulationen zu erkennen. Der Einsatz einer Zulassungssteuerung in CI oder Deployment, die besagt, dass „nur Artefakte zugelassen werden, die mit bekannten guten Prüfsummen oder Signaturen übereinstimmen“, kann eine letzte Verteidigungslinie sein, wenn upstream etwas Unerwartetes passiert ist. Der Schlüssel liegt darin, die Überprüfung zu automatisieren und verbindlich zu machen, sodass Entwickler nicht manuell auf „OK“ klicken müssen, wenn Warnungen angezeigt werden, sondern die Pipeline unverifizierten Code ablehnt.

Aikido auf vielfältige Weise Aikido Durchsetzung der Integrität Aikido . Durch seine SBOM und die Integration mit Signatur-Tools Aikido überprüfen, ob Ihre Abhängigkeiten und Container tatsächlich das sind, was sie vorgeben zu sein. So Aikido beispielsweise mit Sigstore/cosign integriert werden, um sicherzustellen, dass jedes über Ihre Pipeline bereitgestellte container eine gültige Signatur Ihres Unternehmens aufweist – ist dies nicht der Fall, wird es markiert oder blockiert. Die Plattform Aikidoverfolgt auch die Prüfsummen der gescannten Komponenten. Wenn sich der Inhalt eines Artefakts unerwartet ändert (nicht mit der SBOM dem vorherigen Scan übereinstimmt), wird eine rote Warnung ausgegeben. Darüber hinaus umfassen die Schwachstellendatenbank und die Richtlinien AikidoÜberprüfungen wie „Stammt dieses Paket aus einer offiziellen Quelle?“, was indirekt die Integrität abdeckt (wenn jemand eine gefälschte Paketquelle einschleust, Aikido dies über Metadaten-Unstimmigkeiten erkennen). Durch die Integration Aikido erhalten Teams einen automatisierten Integritätswächter. Dieser stellt sicher, dass vom Code-Commit über den Build bis hin zur Bereitstellung des Artefakts jedes einzelne Element nachverfolgt werden kann und vertrauenswürdig ist. In Kombination mit den anderen Praktiken (Scannen, secrets Management usw.) gibt dies Entwicklern die Gewissheit, dass ihre Software-Lieferkette durchgängig sicher ist, da Aikido jedes Glied in der Kette Aikido .

Fazit: Sichern Sie Ihre Lieferkette vom ersten Tag an

Lieferkettenangriffe komplex klingen, aber wie wir gesehen haben, nutzen sie oft eher grundlegende Lücken aus: ungeprüfte Abhängigkeiten, ungesicherte Pipelines, durchgesickerte Anmeldedaten und nicht verifizierte Artefakte. Die gute Nachricht ist, dass Entwicklerteams durch das Bewusstsein für diese häufigen Schwachstellen proaktive Maßnahmen ergreifen 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 bei jedem Commit, Build und Deployment fort. Ein entwicklerfreundlicher Sicherheitsansatz bedeutet, Praktiken wie Scan von Softwareabhängigkeiten, secrets und CI/CD-Audits in den täglichen Arbeitsablauf zu integrieren, anstatt sie als Nebensache zu behandeln.

Die Bedrohungen sind real und nehmen zu – von bösartigen npm-Paketen bis hin zu Verstößen gegen die CI-Pipeline –, aber mit der richtigen Einstellung und den richtigen Tools können Sie die Oberhand behalten. Ermutigen Sie Ihr Team, eine gute „Supply-Chain-Hygiene“ zu praktizieren: Überprüfen Sie, was Sie importieren, rotieren und schützen Sie secrets, sichern Sie Ihren Build-Prozess und überprüfen Sie alles. Automatisieren Sie so viel wie möglich mit modernen DevSecOps . Tatsächlich können Sie durch den Einsatz von Plattformen wie Aikido kann dies erheblich vereinfachen. Aikido als Ihr intelligenter Sicherheitsassistent, der riskante Abhängigkeiten und Konfigurationen frühzeitig erkennt und Sie mit (oft automatisierten) Korrekturen unterstützt, bevor sie zu Vorfällen werden.

Warten Sie nicht, bis ein Schlagzeilen machender Angriff Sie zum Handeln zwingt. Übernehmen Sie Sicherheit der Software-Lieferkette die Verantwortung für Sicherheit der Software-Lieferkette Ihrer Sicherheit der Software-Lieferkette . Beginnen Sie damit, Sicherheitstools in Ihre CI/CD-Pipeline und IDE zu integrieren – probieren Sie beispielsweise das kostenlose Entwickler-Toolkit Aikidoaus, um Ihre Abhängigkeiten und Pipelines auf Schwachstellen und secrets zu überprüfen. Klären Sie Ihre Entwickler über diese Bedrohungen auf, damit sie zu Akteuren im Bereich Schutz werden und nicht nur Konsumenten von Open Source. Mit Wachsamkeit und der Hilfe intelligenter Sicherheitsautomatisierung können Sie Software mit der Gewissheit liefern, dass Ihre Lieferkette – vom Code bis zur Cloud – gegen Angreifer geschützt ist. Sicheres Codieren und Entwickeln ist kein Hindernis für die Geschwindigkeit, sondern eine Investition in das Vertrauen und die Zuverlässigkeit Ihres Produkts. Befähigen Sie Ihr Team, diese Praktiken noch heute anzuwenden, und Sie werden das Risiko, das nächste warnende Beispiel für eine Lieferkette zu werden, erheblich verringern. Viel Spaß beim (sicheren) Codieren!

Weiterlesen:
Die 9 häufigsten Container
Die 7 häufigsten Cloud
Die 10 häufigsten Sicherheitslücken in Webanwendungen, die jedes Team kennen sollte
Die 9 häufigsten Sicherheitslücken und Fehlkonfigurationen Kubernetes-Sicherheit und Fehlkonfigurationen
Top-Code-Sicherheitsschwachstellen in modernen Anwendungen
Top 10 Python-Sicherheitsschwachstellen, die Entwickler vermeiden sollten
Top JavaScript-Sicherheitsschwachstellen in modernen Webanwendungen ‍