Dependabot ist vielen Entwicklerteams als unverzichtbarer Helfer bekannt, der automatisiert veraltete Abhängigkeiten in ihren Projekten erkennt und eigenständig Pull Requests (PRs) erzeugt, um Aktualisierungen anzustoßen. Dieser Dienst von GitHub übernimmt eine zentrale Rolle, um Softwareprojekte aktuell und sicher zu halten, ohne dass Nutzer ständig manuell nach neuen Versionen suchen müssen. Doch wie jede Automatisierung ist auch Dependabot nicht gefeit gegenüber Angriffen – im Gegenteil, gerade seine Automatisierung und das hohe Vertrauen in seine Aktionen machen ihn zu einem lohnenswerten Ziel für Cyberkriminelle. Diese nutzen mit sogenannten Confused Deputy-Angriffen die Vertrauensstellung von Dependabot aus, um bösartigen Code in viel genutzte Open-Source-Repositories einzuschleusen und Workflow-Sicherungen zu umgehen.
Diese Form der Angriffe hat vor allem durch die Veröffentlichung neuer Techniken und reale Vorfälle im Jahr 2024 große Aufmerksamkeit erhalten und zeigt, wie tiefgreifend Supply-Chain-Angriffe inzwischen sein können. Doch wie genau funktionieren solche Attacken, warum sind sie so gefährlich und was können Entwickler tun, um sich zu schützen? Dependabot als automatischer Butler gilt als sehr vertrauenswürdig. Über eine Konfigurationsdatei namens dependabot. yml können Nutzer Einfluss darauf nehmen, wie und wann Updates angestoßen werden. Ist Dependabot aktiviert, überwacht er das Repository regelmäßig, scannt nach veralteten Abhängigkeiten und eröffnet automatisch PRs mit den vorgeschlagenen Aktualisierungen. Üblicherweise werden diese Updates mit Branch-Namen wie dependabot/<ecosystem>/<package>/<version> erstellt, die Dependabot kontrolliert und regelmäßig aktualisiert.
In vielen Projekten existieren automatisierte Workflows, die Dependabot-PRs direkt prüfen und bei positivem Ergebnis sofort mergen, um den Entwicklungsfluss zu beschleunigen. Auf den ersten Blick erscheint diese Automatisierung sicher, denn nur Dependabot sollte Pull Requests eröffnen und entsprechende Rechte besitzen. Doch genau hier liegt die Schwachstelle: Der sogenannte Confused Deputy-Angriff macht sich zunutze, dass Workflows, die auf dem GitHub-Event pull_request_target basieren, mit einem GitHub-Kontext arbeiten, der sich bei der Ausführung eines Workflows nicht immer auf den tatsächlichen Ersteller des Pull Requests bezieht, sondern auf denjenigen, der das Event auslöst. Dadurch kann ein Angreifer zwar keine PRs direkt auf dem Zielrepository eröffnen, aber er kann Dependabot manipulieren, indirekt bösartigen Code durch automatisierte Merge-Prozesse einzuschleusen.
Der Angriff beginnt klassisch mit einem Fork eines Zielrepositories, das entsprechende automatische Merge-Workflows für Dependabot-PRs enthält. Der Angreifer modifiziert in seinem Fork das Default-Branch mit schädlichem Code und sorgt dafür, dass Dependabot im Fork einen veralteten Dependency-Update-Branch erstellt – dieser beinhaltet somit die manipulierten Inhalte. Anschließend erstellt der Angreifer einen Pull Request vom Abhängigkeits-Update-Branch seines Forks zum Zielprojekt. Bei der ersten Auslösung des automatischen Merge-Workflows wird der ausführende Nutzer als Angreifer erkannt, sodass das Merge nicht stattfindet. Der entscheidende Trick ist nun, dass der Angreifer den Kommentar @dependabot recreate auf die ursprüngliche PR setzt. Dependabot reagiert und erzwingt durch eine Synchronisation die erneute Ausführung des Merge-Workflows – jedoch mit dem Absender dependabot[bot].
Dadurch wird die Bedingung zum automatischen Mergen erfüllt, und die bösartigen Inhalte gelangen in das Ziel-Repository. Dieses Vorgehen ist ein Paradebeispiel für einen Confused Deputy-Angriff: Dependabot wird unfreiwillig zum ausführenden Werkzeug des Angreifers, weil er dessen Befehle missverständlich interpretiert und vertrauliche Zugriffsrechte missbraucht werden. Doch der Angriff endet nicht bei bloßem Code-Upload. Forscher haben herausgefunden, dass durch geschicktes Manipulieren von Branch-Namen ein so genannter Command Injection-Angriff möglich ist, bei dem Schadcode direkt durch ungesicherte Variablen in Workflow-Skripten ausgeführt wird. Speziell Variablen wie github. event. pull_request. head. ref – also der Branchnamen – landen oft ungefiltert in Shell-Kommandos, was Angreifern das Einschleusen von Systembefehlen ermöglicht. Zunächst schien dieser Vektorkanal durch das feste Namensschema von Dependabot-Branches ausgeschlossen.
Doch Forscherteams entdeckten zwei neuartige Techniken, um Dependabot-Branches so umzubenennen, dass sie weiterhin funktionieren, aber die Schadcodeausführung ermöglichen. Die erste Technik, „Merge Conflict Tango“ genannt, nutzt absichtliche Merge-Konflikte zwischen Dependabot-Branches und dem Default-Branch im Fork, um über die GitHub-Weboberfläche einen neuen Branch mit einem feindlichen Branchnamen zu erzeugen, der nicht die üblichen Benennungsvorgaben verletzt. Durch die erneute Ausführung von @dependabot recreate wird dieser bösartige Branch von Dependabot benutzt und die Befehle im Workflow aktiviert. Die zweite Methode, „Default Branch Merge Shuffle“, besteht darin, den Default-Branch des Forks auf den bösartigen Branchnamen zu setzen und mittels eines @dependabot merge Kommandos die Änderungen in diesen Branch zu mergen. Auch hier löst die Synchronisation in Verbindung mit dem Dependabot-Account einen ausgeführten Schadcode-Workflow aus.
Eine weitere alarmierende Facette ist die Möglichkeit, Branch Protection-Regeln auf geschützten Hauptbranchs durch solche Angriffe zu umgehen. Da Dependabot oft eigene Push-Berechtigungen im Zielrepository benötigt, steht er typischerweise auf den Ausnahmelisten, die Branch-Protection-Regeln einschränken sollen. Ein Angreifer mit Schreibzugriff auf Dependabot-Branches kann somit durch Erzeugung oder Manipulation einer Dependabot-PR und anschließende Steuerung mittels @dependabot merge Kommentare die Schutzeinstellungen umgehen und Schadcode nahezu unbemerkt ins Hauptprojekt injizieren. Ein echter Albtraum für die Supply-Chain-Sicherheit. Warum trifft es gerade Dependabot? Seine Popularität und tiefgreifende Integration machen ihn zum idealen Ziel. Da es ein vertrauenswürdiger Service ist, dem viele Schreib- und Merge-Rechte eingeräumt werden, ist das Angriffspotenzial hoch.
Andere bots könnten ähnlich angegriffen werden, doch Dependabot ist aufgrund seiner Verbreitung und der Automatisierung von Update-PRs besonders exponiert. Entwickler und Unternehmen sollten daher Awareness für diese Angriffsklasse entwickeln. Maßnahmen zum Schutz basieren primär auf Vorsicht bei der Nutzung des pull_request_target Events und der sorgsamen Überprüfung, welche Nutzerkontexte im Workflow als vertrauenswürdig eingestuft werden. Es empfiehlt sich, spezifische GitHub Actions einzusetzen, die Dependabots Identität robust validieren, wie etwa die von der Community angebotenen Lösungen fastify/github-action-merge-dependabot oder ahmadnassri/action-dependabot-auto-merge. Darüber hinaus sollten Branch-Protection-Regeln nicht nur wichtige Hauptbranchs schützen, sondern auch Dependabot-spezifische Branches mit ähnlichen Restriktionen versehen, um ungewollte Pushes von Angreifern zu verhindern.
Die neue Regel Confused Deputy Auto-Merge, die in Static-Analysis-Tools wie dem Open-Source-Scanner poutine integriert ist, identifiziert solche gefährlichen automatisierten Merge-Workflows und hilft dabei, potenzielle Schwachstellen frühzeitig zu entdecken. Die Sicherheit in DevOps- und CI/CD-Pipelines gewinnt mit solchen Angriffen weiter an Bedeutung. Open-Source-Projekte, die auf Dependabot und ähnliche Automatisierungen setzen, tun gut daran, nicht nur ihre Codesicherheit, sondern auch die Integrität der Entwicklungsprozesse laufend zu überwachen und kompromisssichere Automatismen zu etablieren. Die Entdeckung und auch Veröffentlichung dieser Techniken zeigen, dass die allgemeine Denkweise über Sicherheit bei automatisierten Workflows neu justiert werden muss. Entwickler sind gut beraten, nicht blind auf automatisierte Abhängigkeitsupdates zu vertrauen, sondern diese konsequent mit sicheren Mechanismen zu überwachen.
Insgesamt demonstriert die Analyse dieser Pwn Requests eindrucksvoll, wie durch intelligentes Ausnutzen von Vertrauensstellungen in der Softwarelieferkette weitreichende Kompromittierungen möglich sind. Ein Aufruf, sowohl auf technischer als auch organisatorischer Ebene automatisierte Prozesse kontinuierlich auf ihre Sicherheit hin zu evaluieren, um Supply-Chain-Angriffe frühzeitig zu erkennen und wirkungsvoll zu stoppen.
