Security der Software-Lieferkette verbessern

Die Bedrohung für Software-Lieferketten scheint sich angesichts zweier erheblicher Verstöße zu verschärfen. Zunächst entdeckte Slack verdächtige Aktivitäten in seinem privaten GitHub-Repository zur Erstellung von Software, die darin bestanden, dass eine begrenzte Anzahl von Mitarbeiter-Tokens gestohlen und missbraucht wurde, um Zugriff auf ein extern gehostetes Repository zu erhalten. Ein nicht identifizierter Bedrohungsakteur hatte außerdem private Code-Repositories heruntergeladen, aber weder die primäre Codebasis von Slack noch Kundendaten waren in den heruntergeladenen Repositories enthalten.

CircleCI, ein Anbieter von Continuous Integration/Continuous Delivery (CI/CD), der von vielen Unternehmen zur Erstellung und Bereitstellung von Anwendungen verwendet wird, warnt seine Kunden, alle auf der Plattform gespeicherten geheimen Informationen – also Passwörter, API-Schlüssel, SSH-Schlüssel, Konfigurationsdateien, OAuth-Token usw. – sofort zu ändern, nachdem ein Security-Vorfall bei dem Unternehmen untersucht wurde.

Es ist nicht klar, welche Auswirkungen diese Vorfälle letztlich haben werden, aber nach ähnlichen Verstößen bei LastPass und SolarWinds ist das Bewusstsein für die Notwendigkeit einer besseren Security der Software-Lieferkette geschärft. Während jeder dieser Vorfälle bedauerlich ist, kann die Tatsache, dass sie rechtzeitig aufgedeckt und offengelegt werden, tatsächlich ein Zeichen für einen bedeutenden Fortschritt sein.

Vor nicht allzu langer Zeit war die Wahrscheinlichkeit gering, dass solche Verstöße entdeckt werden. Es wird immer noch viel darüber diskutiert, wie man Software-Lieferketten am besten sichern kann, aber Fortschritte werden offensichtlich erzielt. Das Problem ist, dass all diese Konzentration auf Software-Lieferketten dazu führt, dass mehr Cyberkriminelle sich ermutigt fühlen, sie anzugreifen. Natürlich weiß niemand mit Sicherheit, wie kompromittiert Software-Lieferketten sind, aber dies wird mehr denn je genau überprüft. Einige Software-Lieferketten könnten schon seit Jahren kompromittiert sein, ohne dass jemand davon weiß.

Das Wichtigste ist, dass Anwendungsentwickler und Cybersecurity-Experten eine Arbeitsbeziehung aufbauen. Die größte Barriere für die Einführung der besten DevSecOps-Praktiken, die zur Sicherung von Software-Lieferketten erforderlich sind, bleibt weitgehend kultureller Natur. Seit mehr Jahren als irgendjemand zugeben möchte, betrachten viele Entwickler Cybersecurity als ein Hindernis für die Anwendungsentwicklung, das überwunden oder umgangen werden muss und nicht als Kernaspekt eines Qualitätssicherungsprozesses. Die Gesamtzahl der Schwachstellen in Anwendungen, die in Produktionsumgebungen laufen, dürfte in die Milliarden gehen.

Wichtig ist jedoch, dass nicht alle diese Schwachstellen gleichermaßen schwerwiegend sind. Ein Grund für das große Misstrauen zwischen Anwendungsentwicklern und Cybersecurity-Teams ist, dass letztere in der Vergangenheit dazu tendierten, Listen von Schwachstellen zu erstellen, die ohne viel Kontext gepatcht werden müssen. Entwickler, die zwischen den Schreiben von neuem Code und dem Patchen von altem Code hin-und hergerissen sind, stoßen sich an Listen von Schwachstellen, von denen sich nach der Untersuchung herausstellt, dass sie aufgrund der Art und Weise, wie der Code erstellt oder bereitgestellt wurde, keine Auswirkungen auf die Anwendung haben. Schlimmer noch: Wenn sie entdeckt wird, ist die Wahrscheinlichkeit, dass die Schwachstelle jemals ausgenutzt wird, bestenfalls gering.

Glücklicherweise zeichnet sich zwischen Entwicklern und Cybersecurity-Experten ein neuer Geist der Entspannung und Zusammenarbeit ab. Anstatt einander mit Misstrauen zu begegnen, gibt es jetzt eine wirkliche Gelegenheit, die Art des Dialogs so zu verändern, dass alle Beteiligten davon profitieren. Wie bei jeder Verhandlung zum Beenden eines Konflikts wird auch hier jemand entschlossen genug sein müssen, den ersten Schritt zu tun.