Die Cybersicherheit bis Ende 2026 überstehen

Die letzten Wochen waren wirklich hart. Ein Entwickler-Laptop führte bei Binance zum größten Diebstahl in der Geschichte der Kryptowährungen. LiteLLM wurde auf PyPI erneut manipuliert. PHP2Shell und Node2Shell trafen PHP und Node.js, die zusammen einen riesigen Anteil des Internets ausmachen. Und vergessen wir nicht eMudhra und die privaten Schlüssel, die innerhalb von Sekunden wiederhergestellt werden konnten.

Bei diesen Vorfällen kamen bekannte Techniken zum Einsatz, die kaum ausgefeilt waren. Die Angreifer handelten jedoch zügig, und das Zeitfenster zwischen der Offenlegung und der Ausnutzung der Schwachstelle schließt sich rasch. Bei einigen Schwachstellen ist es bereits geschlossen.

Unternehmen sollten davon ausgehen, dass ein Laptop, ein Anbieter, ein Softwarepaket oder ein CI-Runner in ihrer Infrastruktur irgendwann kompromittiert wird. Ist dies einmal geschehen, hängt der Schaden davon ab, wie weit der Angreifer von dort aus vordringen kann.

Im Folgenden finden Sie sechs Maßnahmen, die wir empfehlen, um bis Ende 2026 sicher zu bleiben.

Gestohlene Zugangsdaten unbrauchbar machen

Wir haben gesehen, wie viel Schaden gestohlene Zugangsdaten in den Händen von Angreifern anrichten können. Daher ist es von größter Bedeutung, den Schadenumfang zu begrenzen, sobald Zugangsdaten offengelegt wurden. Die meisten Teams haben keine Vorkehrungen für den Fall getroffen, dass ihre Zugangsdaten tatsächlich gestohlen werden. Geht man von der Annahme aus, dass sie offengelegt werden, ist es einfacher, die richtigen Ausgleichsmaßnahmen zu ergreifen.

In der Praxis bedeutet das:

• Verwenden Sie kurzlebige Tokens oder einen Just-in-Time-Zugriff (JIT), sodass ein Dienst oder eine Person nur so lange Zugriff auf ein Geheimnis hat, wie es für die jeweilige Aufgabe erforderlich ist. Sollte diese Zugangsberechtigung kompromittiert werden, ist sie zu diesem Zeitpunkt bereits kurz vor dem Ablauf oder bereits abgelaufen.
• Halten Sie den Geltungsbereich eng. Wenn ein Dienst nur Lesezugriff benötigt, gewähren Sie ihm keinen Schreibzugriff.
• Führen Sie die Drei-Faktor-Authentifizierung als Standard für jedes Tool ein. Aktivieren Sie die Zwei-Faktor-Authentifizierung (2FA) überall, wo dies möglich ist. Verlangen Sie beispielsweise die 2FA auf GitHub und richten Sie IP-Beschränkungen ein.
• Überprüfen Sie Ihre Anwendungen auf alle ausgestellten API-Schlüssel und Tokens. Stellen Sie fest, wofür diese verwendet werden. Vergewissern Sie sich, dass Sie deren Geltungsbereich verstehen. Widerrufen Sie nicht mehr benötigte Schlüssel und Tokens oder nutzen Sie die Überprüfung, um einen Plan für die regelmäßige Erneuerung von Anmeldedaten zu erstellen.

Sichern Sie den Code, den Sie nicht selbst geschrieben haben

PHP2Shell hat schmerzlich deutlich gemacht, wie groß das Risiko ist, das in dem Code steckt, den man übernimmt. Basis-Images und Open-Source-Bibliotheken bringen ihre eigenen Probleme mit sich, ebenso wie die ihnen zugrunde liegenden Laufzeitumgebungen. Sobald diese in Ihren Bestand aufgenommen werden, tragen Sie die Verantwortung dafür. Sie können es nicht vermeiden, Code zu übernehmen, aber Sie können entscheiden, was Sie übernehmen und auf welche Weise.

In der Praxis:

• Beginnen Sie mit Minimal- container -Images. Diese enthalten weitaus weniger Pakete als Standard-Images, was standardmäßig eine geringere Angriffsfläche und weniger CVEs bedeutet.
• Kombinieren Sie Minimal-Images mit einem Anbieter für gehärtete „ container “-Images, damit eventuell auftretende CVEs schnell behoben werden.
• Forken oder spiegeln Sie Bibliotheken intern und nutzen Sie diese über Ihren eigenen Feed.
• Verwenden Sie „hardened“-Bibliotheken für Abhängigkeiten, deren Lebenszyklus abgelaufen ist, oder überall dort, wo Sie eine verlängerte Lebenszyklusunterstützung mit zurückportierten Sicherheitskorrekturen benötigen.
• Finden Sie heraus, welche Produkte nicht mehr weiterentwickelt werden, indem Sie Ihren Bestand auf Versionen überprüfen, die nicht mehr gepflegt werden.
• Nutzen Sie „ Software-Kompositionsanalyse “ (SCA), um alle Open-Source-Abhängigkeiten, einschließlich transitiver Abhängigkeiten, zu verfolgen und die dabei gefundenen Sicherheitslücken zu melden und zu beheben.
• Installieren Sie Patches, sobald kritische Sicherheitslücken bekannt werden. Exploits folgen mittlerweile innerhalb weniger Tage nach der Bekanntgabe.

Entfernen Sie Anbieter, die Sie nicht benötigen

Die Zunahme der Anbieter ist eine Tatsache, und jeder Anbieter, den Sie in Ihr Unternehmen holen, stellt ein Risiko dar, wenn er nicht gut verwaltet wird. Das GitHub-Plugin, das Sie letztes Jahr installiert und nur einmal verwendet haben? Das ist ein Risiko. Ebenso wie die npm-Abhängigkeit, die Sie für ein Projekt installiert haben, das Sie inzwischen aufgegeben haben. Zu den Anbietern zählen alle, deren Code oder Dienste in Ihrer Infrastruktur laufen – von Unternehmen, die Sie bezahlen, bis hin zu Open-Source-Betreuern.

In der Praxis:

• Erstellen Sie eine übersichtliche Bestandsaufnahme aller Anwendungen, Plugins, Integrationen und Dienste in Ihrer gesamten Infrastruktur.
• Verzichten Sie nach Möglichkeit auf Drittanbieter. Bei den Anbietern, die Sie weiterhin nutzen, sollten Sie deren Dienste über Ihren eigenen Artifact-Feed spiegeln oder als Proxy bereitstellen.
• Beschränken Sie IDE-Erweiterungen und Plugins auf ein Minimum.
• Listen Sie alle OAuth-Berechtigungen, GitHub-Apps, persönlichen Zugriffstoken und verbundenen SaaS-Integrationen auf und widerrufen Sie diejenigen, die Sie nicht nutzen.
• Prüfen Sie jeden Anbieter, bevor Sie ihn einbinden. Fragen Sie, wer die Wartung übernimmt und welche Zugriffsrechte erforderlich sind, und prüfen Sie, ob eine bereits bei Ihnen eingesetzte Lösung dieselbe Aufgabe erfüllt.
• Externe Anbieter werden unverzüglich nach Projektende oder Vertragsablauf entlassen.
• Nehmen Sie Szenarien für Sicherheitsverletzungen bei Lieferanten in Ihren Plan zur Reaktion auf Vorfälle auf und testen Sie diese. Gehen Sie davon aus, dass bei einem Ihrer Lieferanten eine Sicherheitsverletzung auftritt, und spielen Sie dann durch, wie Ihr Team darauf reagiert.

Was nicht online sein muss, sollte offline geschaltet werden

PHP2Shell hat gezeigt, dass Teams jeden Dienst, den sie online betreiben, rechtfertigen und schnell herausfinden müssen, welche Dienste in ihrer Infrastruktur laufen.

Dieser vergessene Webserver aus dem Jahr 2019, der „eigentlich nur für interne Entwicklungsarbeiten laufen sollte“, ist genau die Art von ungepatchtem Rechner, auf den es Angreifer abgesehen haben. Oft erfahren die Teams erst dann von seiner Existenz, wenn es bereits zu spät ist.

In der Praxis:

• Überprüfen Sie Ihre IT-Infrastruktur, einschließlich Ihrer externe Angriffsfläche, und erstellen Sie eine Bestandsaufnahme aller laufenden Dienste und Systeme.
• Prüfen Sie diese Liste genau und seien Sie bereit, zu begründen, warum jeder Punkt auf der Liste steht.
• Sorgen Sie für eine nachverfolgbare Zuordnung der Ressourcen, indem Sie jede einzelne mit einem Verantwortlichen und einem Verwendungszweck kennzeichnen. Kennzeichnen Sie auch Umgebungen und setzen Sie die Kennzeichnung durch Richtlinien durch.
• Systeme sollten vom öffentlichen Internet ferngehalten werden, sofern sie nicht unbedingt dort sein müssen. Interne Tools sollten hinter einem VPN oder einem Zero-Trust-Zugang geschützt werden.
• Üben Sie Ihren Patching-Prozess gründlich, damit Sie bereit sind, wenn wichtige Informationen veröffentlicht werden.
• Nutzen Sie Zeitpläne für die automatische Abschaltung, damit die Rechenkapazitäten nur dann online sind, wenn sie benötigt werden. Ein Kubernetes-Entwicklungscluster, den Sie nur dienstags nutzen, kann für den Rest der Woche heruntergefahren werden – und das senkt zudem Ihre Kosten.

Steuern Sie, was auf den Computern der Benutzer ausgeführt wird

Malware-Angriffe auf Geräte nehmen zu, und allein in einer Woche hatAikido fast 500 davon abgewehrt. Entwickelnde -Rechner sind ein attraktives Ziel, da sie Anmeldedaten und Zugriff auf Systeme enthalten, die mitunter von entscheidender Bedeutung sind. In den obigen Abschnitten wird erläutert, wie sich die Einsatzmöglichkeiten dieser Anmeldedaten einschränken lassen, und durch die Kontrolle darüber, was tatsächlich auf Entwicklerrechnern ausgeführt wird, lässt sich die Angriffsfläche weiter verringern. Der Vercel-Hack in diesem Jahr hat uns zudem gezeigt, wie eine einzige Browser-Erweiterung zu einem Vorfall führen kann.

In der Praxis bedeutet das:

• Überprüfen Sie die Benutzerrechner und erstellen Sie eine Bestandsaufnahme der installierten Software und Versionen, einschließlich Browser-Erweiterungen, IDE-Erweiterungen, MCP-Servern und KI-Tools.
• Die Installation neuer Plugins und Erweiterungen wird blockiert, bis diese genehmigt wurden.
• Führen Sie eine Zulassungsliste, damit die Nutzer nicht auf die gängigen Begriffe warten müssen.
• Legen Sie ein Mindestalter für Pakete oder eine Wartezeit fest. Die meisten schädlichen Pakete werden innerhalb weniger Stunden erkannt, sodass eine Wartezeit das Risiko der Installation einer schädlichen Version verringert.
• secrets en nicht auf der Festplatte speichern. Infostealer suchen zuerst nach Token im Klartext in .env-Dateien und im Shell-Verlauf. Secrets -Manager und kurzlebige Token sind hier Ihre Verbündeten.

Greife dich selbst zuerst an

„Check yourself before you wreck yourself“ ist ein fundierter Sicherheitsratschlag. Führen Sie Penetrationstests in Ihrem Netzwerk durch und automatisieren Sie Angreifer-Simulationen für alle Dienste, die Sie betreiben, damit Sie die Schwachstellen entdecken, bevor es jemand anderes tut.

Ein Leck zu beheben, bevor es zu einer Überschwemmung kommt, klingt selbstverständlich – aber tun Sie das auch wirklich? Automatisierte Tools erleichtern dies. In der Praxis:

• Setzen Sie „ Verwaltung der Angriffsfläche “ (ASM)-Tools in Ihrer gesamten Infrastruktur ein, damit Sie wissen, welche Ressourcen exponiert sind – einschließlich derer, die Sie gar nicht mehr auf dem Schirm hatten.
• Führen Sie regelmäßig externe Netzwerk-Penetrationstests durch, nicht nur einmalig.
• Testen Sie Apps, die regelmäßig veröffentlicht werden, kontinuierlich, anstatt das Testen als eine einmal im Jahr zu erledigende Pflichtübung zu betrachten.
• Simulieren Sie mithilfe von Tabletop-Übungen einen Sicherheitsverstoß und prüfen Sie, worauf ein Angreifer von einem kompromittierten Rechner oder CI-Runner aus tatsächlich Zugriff haben könnte.

Vollständige Checkliste

Bereiten Sie Ihr Team Schritt für Schritt vor.

Diese Woche

• Durchsuche die Rechner der Entwickler nach Cloud-Anmeldedaten, SSH-Schlüsseln, API-Tokens und .env-Dateien.
• Legen Sie für jeden von Ihnen verwendeten Paketmanager, einschließlich npm und PyPI, ein Mindestalter von mindestens 48 Stunden fest.
• Blockieren Sie Malware bereits bei der Installation mit der „ Aikido Safe Chain“.
• Prüfen Sie, was über das Internet zugänglich ist, und entfernen Sie alles, was nicht dort sein muss, aus dem Internet.

In diesem Monat

• Verlegen Sie die Produktions secrets en von den Laptops in einen „ secrets -Manager“ und ändern Sie regelmäßig alle Anmeldedaten, die Sie auf den Entwicklerrechnern gefunden haben.
• Überprüfen Sie die Abhängigkeiten und entfernen Sie nicht mehr verwendete oder nicht mehr gepflegte Abhängigkeiten.
• Erstellen Sie ein Anbieterverzeichnis, das Ihre Apps, Plugins, Abhängigkeiten und Dienste umfasst, und weisen Sie jedem Eintrag einen Verantwortlichen zu.
• Legen Sie Zeitpläne für die automatische Abschaltung von Rechenressourcen außerhalb der Produktion fest.
• Entfernen Sie, soweit möglich, die lokalen Administratorrechte auf den Benutzergeräten.
• Führen Sie „ KI-Codeanalyse “ für Code aus, der mit dem Internet verbunden ist, sowie für Code, der Authentifizierungen oder Zahlungen abwickelt.
• Speichern Sie Identitätsanbieter-, Cloud-Audit-, Quellcodeverwaltungs- und CI-Protokolle an einem Ort, an dem sie nicht durch Produktionszugangsdaten gelöscht werden können.
• Legen Sie ein Ziel für die Behebung kritischer, internetseitiger Sicherheitslücken fest, gemessen in Stunden oder Tagen.

Vor Ende 2026

• Stellen Sie „ Verwaltung der Angriffsfläche “ in Ihrer gesamten Infrastruktur bereit.
• Führen Sie einen externen Netzwerk-Penetrationstest durch und vereinbaren Sie den nächsten Termin für 2027.
• Führen Sie Tabletop-Übungen durch, bei denen von einem Sicherheitsverstoß durch einen kompromittierten Anbieter, den Laptop eines Entwicklers, einen CI-Runner oder ein Paket ausgegangen wird.
• Führen Sie zum Jahresende eine Bestandsaufnahme aller Lieferanten und Dienstleistungen durch, damit für jeden Posten bis zum Jahreswechsel 2027 ein Verantwortlicher feststeht.

Weitere Informationen finden Sie unter „Sicherheit der Software-Lieferkette : Best Practices“.

Fazit

Bis zum Jahresende und noch lange darüber hinaus werden immer wieder neue CVEs und kompromittierte Pakete auftauchen. Gehen Sie davon aus, dass Sie irgendwann davon betroffen sein werden, und stellen Sie sicher, dass Sie in dieser Situation bestmöglich gewappnet sind. Teams, die den Umfang der Auswirkungen eines einzelnen Sicherheitsvorfalls begrenzen, können den nächsten Vorfall schneller eindämmen als Teams, die darauf setzen, jeden Angriffspunkt zu blockieren.

Für einen längerfristigen Ausblick lesen Sie „PHP2Shell“ – übermorgen.