Kontinuierlich, einmal täglich oder alle paar Tage: So häufig geben 70 Prozent der für die DevSecOps-Studie 2022 von GitLab befragten Entwickler-Teams Software-Code frei. Ein Anstieg von 11 Prozent gegenüber dem Vorjahr. Die Umfrage ergab auch, dass die Befragten am meisten in Sicherheit investieren. Das sind die guten Nachrichten.
Weniger gut hingegen ist, dass der Trend zur mangelnden Absprache und gegenseitigen Anpassung zwischen Sicherheits- und Entwicklungsteams anhält. In dieser Umfrage erklärte mehr als die Hälfte der Befragten, dass Sicherheit eine Leistungskennzahl für Entwickler in ihrem Unternehmen ist. 50 Prozent der befragten Sicherheitsexperten gaben jedoch an, dass Entwickler Sicherheitsprobleme nicht erkennen würden, wobei etwa 75 Prozent der Schwachstellen von Sicherheitsexperten gefunden werden.
Die Prioritäten der Sicherheitsabteilung und der Entwickler weichen voneinander ab, lange bevor die erste Codezeile überhaupt geschrieben wird. Zwar wissen die meisten Unternehmen um die Bedeutung der Sicherheit, aber sie schaffen nicht die Voraussetzungen für eine echte funktionsübergreifende Zusammenarbeit und bessere Sicherheit im gesamten Unternehmen.
Unternehmen können indes Entwickler- und Sicherheitsteams zu Beginn des Softwareentwicklungszyklus (SDLC) besser aufeinander abstimmen und so Spannungen im weiteren Verlauf verringern – ohne sich auf Tools und teure Risikobewertungen zu verlassen.
Metriken und Anreize aufeinander abstimmen. Derzeit haben Entwickler und Sicherheitsexperten häufig widersprüchliche Prioritäten. Für Entwickler ist die Geschwindigkeit, mit der sie neue Funktionen freigeben, ein Anreiz; für Sicherheitsexperten hingegen ist es ein Anreiz, Risiken zu reduzieren – was bedeuten kann, dass sie sich bewusst Zeit nehmen, um Bedrohungen und die Gefährdung des Unternehmens besser zu verstehen. Solange die Ziele und Kennzahlen der beiden Teams nicht aufeinander abgestimmt sind, werden sie immer im Streit liegen.
Um die Zusammenarbeit zwischen diesen Teams zu verbessern, müssen sie sich frühzeitig auf nichtfunktionale Anforderungen in der Entwurfsphase einigen und sich gegenseitig zugestehen, dass Kompromisse notwendig sind. Beispielsweise können sich beide Teams darauf verständigen, dass ein fehlgeschlagener Sicherheitsscan nicht gleichbedeutend mit einer fehlgeschlagenen Pipeline und Produktivitätseinbußen ist. Sie sollten einen risikobasierten Ansatz in Erwägung ziehen, um fehlgeschlagene Scans in den richtigen Kontext zu setzen und Schwachstellen auf der Grundlage anderer Abhilfemaßnahmen zu bewerten.
Teams bilden. Unternehmen sollten prüfen, ob ihre Sicherheitsteams über die erforderlichen Qualifikationen verfügen, um Risiken in der Entwicklungsumgebung nicht nur zu verstehen, sondern auch damit umgehen zu können. So sollten die Mitglieder des Sicherheitsteams Kenntnisse und Erfahrungen in den Bereichen Softwareentwicklung, sichere Codierungstechniken und dynamischere Sicherheitstests haben. Ein Team mit unterschiedlichen Hintergründen kann entscheidend für ein Sicherheitsprogramm sein, das die Entwickler bei der Entwicklung sicherer Produkte unterstützt.
Da es nach wie vor schwierig ist, talentierte IT-Sicherheitskräfte zu finden und zu halten, sollten Unternehmen prüfen, wie viel Zeit Teams für die Pflege und Versorgung von Sicherheitstools aufwenden – und entscheiden, ob dies die beste Nutzung knapper Ressourcen ist. Konsolidierte und verwaltete Plattformen können dazu beitragen, dass die Mitglieder der Sicherheitsteams mehr Zeit haben, bessere Partner für die Entwicklungsteams werden – und mehr Zeit für die Design- und Betriebsphasen des SDLC aufwenden können.
Verantwortung und Erwartungshaltung klarziehen. Jedes Unternehmen, das Software einsetzt oder sich auf sie verlässt, möchte wahrscheinlich Software schneller bereitstellen, um mit der Geschwindigkeit des Marktes mithalten zu können. Ein einziger Sicherheitsvorfall reicht jedoch aus, um selbst das effizienteste Entwicklungsteam in den Schatten zu stellen. Daher ist Sicherheit eine Schlüsselkomponente von Qualitätssoftware; sie muss eine Teamleistung sein.
Die Entwicklung von Software ist ein schneller Prozess; einige neue Angriffsvektoren und sich daraus ergebende Schwachstellen werden erst nach der Bereitstellung erkannt. Unternehmen, die nicht richtig ausgerichtet sind, müssen die Erwartungen und die Unterstützung für die Entwicklung eines sicheren Produkts auf allen Ebenen neu justieren. Sicherheitsteams müssen sich darüber im Klaren sein, dass es immer wieder Schwachstellen geben wird, die in die Produktion gelangen.
Um die Zahl der aktiven Schwachstellen auf ein Minimum zu reduzieren, sollten die Sicherheitsteams den Entwicklern die Werkzeuge und Daten zur Verfügung stellen, die sie benötigen, um Schwachstellen so früh wie möglich zu erkennen – insbesondere solche, die wiederholt auftreten. Die Richtlinien für den Umgang mit diesen Schwachstellen sollten ebenfalls dokumentiert werden.
Der Sicherheit muss während des gesamten Entwicklungsprozesses Priorität eingeräumt werden. Entwickler sollten die Sicherheitsteams unterstützen, indem sie Problembereiche identifizieren und kennzeichnen, Fragen stellen und den Mitgliedern des Sicherheitsteams helfen, den geschriebenen Code zu verstehen. Die Teams sollten außerdem eine einheitliche DevSecOps-Plattform für die Softwareentwicklung einführen, damit alle internen Stakeholder Prioritäten und wichtige Messbereiche kommunizieren können – mit nur einer einzigen Referenzquelle.
Die Unausgewogenheit zwischen Entwicklern und Sicherheitsexperten ist für jedes Unternehmen, das effizient Software bereitstellen und die Sicherheit nicht gefährden möchte, untragbar. Neue Arbeitsabläufe und Organisationsstrukturen müssen her, die eine bessere funktionsübergreifende Zusammenarbeit ermöglichen, und die Kluft zwischen Entwicklern und Sicherheitsexperten endgültig schließen.
Francis Ofungwu,
Global Field CISO,
GitLab
Dies ist die gekürzte deutsche Fassung eines Beitrags, der erstmals in Techbeacon erschienen ist.
https://techbeacon.com/devops/bridging-development-security-divide