Angreifer in der Supply Chain entwickeln ihre Taktiken weiter und konzentrieren sich auf den Diebstahl von Zugriffen anstatt ausschließlich auf das Einschleusen von bösartigem Code. Aktuelle Kampagnen, die Paketmanager und Container-Registries ins Visier nehmen, zeigen ein klares Muster: das Sammeln von Anmeldeinformationen aus Entwicklungsumgebungen und CI/CD-Pipelines. Dazu gehören API-Schlüssel, Cloud-Anmeldeinformationen, SSH-Schlüssel und Tokens. Dieser Wandel erfordert eine neue Perspektive auf die Sicherheit der Software-Supply-Chain. ### Jenseits traditioneller Sicherheitsmaßnahmen Traditionell konzentrierten sich Sicherheitsbemühungen auf gemeinsam genutzte Systeme wie Quellcode-Repositories, CI/CD-Plattformen und Paketmanager. Obwohl diese Bereiche weiterhin kritisch sind, ist ein umfassenderer Ansatz erforderlich. Die moderne Softwarebereitstellung beginnt auf der Entwickler-Workstation, wo Code geschrieben, Abhängigkeiten installiert und Anmeldeinformationen getestet werden. Diese Workstations sind integraler Bestandteil der Software-Supply-Chain und sollten nicht als bloße Endpunkte behandelt werden. ### Supply-Chain-Angriffe: Operationen zum Sammeln von Anmeldeinformationen Aktuelle Vorfälle, darunter die Kampagnen **TeamPCP** und **Shai-Hulud**, unterstreichen die Konvergenz von Supply-Chain-Angriffen und dem Diebstahl von Anmeldeinformationen. Angreifer nutzen vergiftete Pakete, kompromittierte Images und anfällige Entwicklertools, um Zugang zu sensiblen Informationen zu erhalten. Die **TeamPCP**-Kampagne umfasste das Sammeln von Tokens, Cloud-Anmeldeinformationen, SSH-Schlüsseln, **npm**-Konfigurationsdateien und Umgebungsvariablen. **Shai-Hulud** nutzte infizierte Entwicklungsumgebungen weiter aus, um Tausende von Geheimnissen über **GitHub**, Cloud-Dienste und interne Systeme zu sammeln. Dies stellt eine Verlagerung von einfacher Softwaremanipulation hin zur gezielten Sammlung von Anmeldeinformationen an Punkten des inhärenten Vertrauens dar. Kompromittierte Anmeldeinformationen ermöglichen es Angreifern, vertrauenswürdige Softwaresysteme zu ändern, zu veröffentlichen, zu erstellen, bereitzustellen oder sich als diese auszugeben. Die Geschwindigkeit moderner Automatisierung ermöglicht eine schnelle Verbreitung bösartiger Updates. ### Der Weg des Angreifers: Kontext auf Entwicklerseite Entwickler-Workstations sind aufgrund ihrer Konzentration von Kontext wertvolle Ziele. Sie enthalten oft lokale Repositories, `.env`-Dateien, Shell-Verläufe, SSH-Schlüssel, Paketmanager-Anmeldeinformationen, Build-Skripte und Browsersitzungen. Diese aggregierten Informationen sind deutlich gefährlicher als isolierte Datenpunkte. Beispielsweise bieten ein einzelner Zugriffstoken in Kombination mit Git-Remote-Informationen, Bereitstellungsskripten und CI-Konfigurationen Angreifern ein klares Verständnis seiner potenziellen Auswirkungen. Die Kompromittierung einer Entwickler-Workstation kann Quellcodeverwaltungssysteme, Cloud-Konten, Paketveröffentlichungs-Workflows, CI/CD-Systeme und interne APIs offenlegen. ### Entwicklermaschinen: Konzentrierte Autorität Während ein Standard-Laptop eines Mitarbeiters Unternehmensdaten preisgeben kann, kann eine Entwickler-Workstation die Fähigkeit zur Softwareänderung preisgeben. Dieser Unterschied ist entscheidend für die Endpunktsicherheitsüberlegungen. Entwickler benötigen weitreichenden Zugriff, um ihre Arbeit auszuführen, einschließlich des Zugriffs auf private Repositories, Cloud-Dienste und interne Tools. Ihre Maschinen werden zu einem Knotenpunkt von Quellcode, Anmeldeinformationen, Automatisierung und Berechtigungsautorität. Eine lokale Kompromittierung kann Angreifern einen Weg in Systeme eröffnen, die Software erstellen, ändern, freigeben oder betreiben. Wichtige Fragen für Sicherheitsteams: * Können Sie identifizieren, welche Anmeldeinformationen von Entwickler-Workstations aus nutzbar sind? * Können Sie den Wert und die Lebensdauer dieser Anmeldeinformationen begrenzen? * Können Sie sensible Materialien erkennen, bevor sie in den Git-Verlauf, CI-Protokolle oder Chats gelangen? * Können Sie den Zugriff bei Verdacht auf eine Kompromittierung der Workstation schnell widerrufen und rotieren? * Können Sie zwischen einer lokalen Exposition mit geringen Auswirkungen und Anmeldeinformationen mit Administratorähnlichen Berechtigungen unterscheiden? Die Beantwortung dieser Fragen erfordert die Zusammenarbeit zwischen AppSec-, Endpoint-, Identity-, Platform- und Cloud-Sicherheitsteams. ### Automatisierung und KI: Verstärkung der Angriffsfläche Automatisierung verkürzt die Zeit zwischen Kompromittierung und Auswirkung. Abhängigkeitsupdate-Bots und CI/CD-Systeme können Änderungen schnell verbreiten. KI-gestützte Entwicklung führt neue Übergabepunkte für sensible Daten ein, darunter Prompts, Terminalausgaben und generierter Code. Sicherheitsteams sollten KI-Codierungsrisiken mit der gleichen Brille wie Supply-Chain-Risiken betrachten. Berücksichtigen Sie, auf welche Quellen und Daten das Tool zugreifen kann, was es ausführen kann, wohin die Ausgabe geht und welche Anmeldeinformationen sich in der Nähe befinden. ### Nachgelagerte Kontrollen: Notwendig, aber unzureichend Repository-Scanning, Branch-Schutz, CI/CD-Richtlinien, Artefaktsignierung, Abhängigkeitsanalyse und Laufzeitkontrollen bleiben unerlässlich. Die Geschwindigkeit moderner Angriffe erfordert jedoch proaktive Maßnahmen. Das Erfassen sensibler Materialien während der Entwicklung, bevor es den Git-Verlauf oder CI-Protokolle erreicht, minimiert die potenziellen Auswirkungen. Reife Programme sollten zwischen Aktionen unterscheiden, die blockiert, gewarnt oder einfach nur Telemetrie zur Untersuchung generieren sollten. ### Behandlung der Workstation als lokale Supply-Chain-Grenze Die moderne Software-Supply-Chain beginnt auf der Entwickler-Workstation, wo Code, Anmeldeinformationen, Automatisierung und Vertrauen zusammenlaufen. Es ist entscheidend, die Entwickler-Workstation als lokale Supply-Chain-Grenze zu behandeln, die die IDE, das Terminal, den Git-Client, den Paketmanager, die Container-Tools und KI-Assistenten umfasst. Hier werden individuelle Entwickleraktionen zu einem organisationsweiten Risiko für die Softwarebereitstellung.