Schädliche Pull Requests erhöhen die Risiken für weit verbreitete Entwickler-Workflows

Eine neu hervorgehobene Schwachstelle in CI/CD-Workflows lenkt die Aufmerksamkeit darauf, wie Open-Source- und Cloud-Entwicklungsprojekte mit Codebeiträgen umgehen. Im Mittelpunkt stehen schädliche Pull Requests, über die sich schädliche Änderungen in automatisierte Build- und Release-Prozesse einschleusen lassen, wenn Überprüfungs- und Validierungskontrollen nicht streng genug sind.

Dem Bericht zufolge betrifft die Schwachstelle in den Workflows mehrere bekannte Projekte und Entwicklertools, darunter Microsofts Azure Sentinel, Googles AI Agent Development Kit, Apache Doris, Cloudflares Workers SDK und den Formatter Black der Python Software Foundation. Obwohl die Projekte unterschiedliche Zielgruppen und Anwendungsfälle bedienen, setzen sie alle auf Softwarebereitstellungspipelines, die zu attraktiven Zielen werden können, wenn das Vertrauen in Mitwirkende und Automatisierung ineinandergreifen.

Sicherheitsforscher und Maintainer warnen zunehmend davor, dass auf Pull Requests basierende Angriffe erfolgreich sein können, weil sie gängige Praktiken der Zusammenarbeit ausnutzen. In vielen modernen Entwicklungsumgebungen wird der Code externer Mitwirkender automatisch getestet, bevor er zusammengeführt wird. Wenn diese Prüfungen nicht sorgfältig isoliert sind, kann ein Angreifer möglicherweise Build-Schritte beeinflussen, Geheimnisse offenlegen oder Änderungen einschleusen, die bei einer routinemäßigen Überprüfung nur schwer zu erkennen sind.

Warum das Problem wichtig ist

Selbst wenn ein Pull Request Produktionssysteme nicht direkt verändert, kann er dennoch erhebliche Risiken für die gesamte Software-Lieferkette schaffen. Eine Kompromittierung in der Entwicklungsphase kann sich auf nachgelagerte Releases, Paketdistributionen und Benutzerumgebungen ausweiten.

• Bei der Überprüfung oder beim Testen kann Automatisierung nicht vertrauenswürdigen Code ausführen.
• Geheimnisse, Tokens oder Signaturschlüssel können offengelegt werden, wenn Pipeline-Kontrollen unzureichend sind.
• Vertrauenswürdige Projekte können zu Einstiegspunkten für einen umfassenderen Missbrauch der Lieferkette werden.

Der Bericht unterstreicht die Notwendigkeit stärkerer Sicherheitsvorkehrungen für Workflows von Mitwirkenden, darunter strengere Berechtigungen, ein sicherer Umgang mit Geheimnissen und eine restriktivere CI/CD-Ausführung für Beiträge von außen. Für Teams, die beliebte Tools und Infrastrukturen betreiben, ist die Schlussfolgerung eindeutig: Der Komfort bei der Zusammenarbeit darf nicht zulasten der Pipeline-Sicherheit gehen.