The Source Sicherheit und Compliance
Artikel

Mehr als nur Kultur: Gehe auf die Grundursachen für häufige Frustration im Sicherheitsbereich ein

Mehr als nur Kultur: Gehe auf die Grundursachen für häufige Frustration im Sicherheitsbereich ein

October 29, 2024 Lesedauer: 5 Min.
Josh Lemos
Josh Lemos Chief Information Security Officer

In der jährlichen Umfrage von GitLab unter DevSecOps-Expert(inn)en wurden in diesem Jahr zahlreiche Themen aufgedeckt, die sich auf eine Organisationskultur beziehen, die eine tiefere Abstimmung zwischen Engineering- und Sicherheitsteams verhindern könnte. Die Mehrheit (58 %) der Befragten im Sicherheitsbereich gab an, dass es für sie schwierig ist, die Entwicklung dazu zu bringen, die Behebung von Sicherheitslücken zu priorisieren. 52 % sagten, dass übermäßige Bürokratisierung die rasche Behebung von Sicherheitslücken oft behindert. Außerdem nannten die Befragten im Sicherheitsbereich einige spezifische Frustrationspunkte in ihrer Arbeit, darunter die Schwierigkeit, Sicherheitsergebnisse zu verstehen, zu viele falsch positive Ergebnisse und Tests, die erst spät im Softwareentwicklungsprozess stattfinden.

DevSecOps verspricht eine bessere Integration zwischen Engineering und Sicherheit, aber es ist klar, dass Frustrationen und Fehlausrichtungen bestehen bleiben. Diese Herausforderungen sind nämlich Symptome eines größeren Problems, wie Unternehmen Sicherheit sehen und wie Teams zusammenarbeiten und ihre Zeit für Sicherheit aufwenden.

Entkomme dem Sicherheitslücken-Hamsterrad

Das Scannen von Sicherheitslücken zeigt alle potenziellen Sicherheitslücken auf – aber nur weil ein Softwarepaket eine häufige Sicherheitslücke oder Gefährdung (CVE; Common Vulnerability or Exposure) aufweist, bedeutet das nicht, dass diese zugänglich oder ausnutzbar ist. Sowohl Sicherheitsteams als auch Entwickler(innen) priorisieren und filtern Sicherheitslücken, die exponentiell im Laufe der Jahre angewachsen sind, seit authentifizierte Sicherheitsscans zur Norm wurden.

Der Umstieg auf authentifizierte Scans hat die Wirksamkeit von Sicherheitsprogrammen in vielerlei Hinsicht verbessert, hat jedoch die Entwickler(innen) in eine endloses Hamsterrad getrieben, in dem sie Dinge beheben müssen, die nicht wichtig sind. Wenn Teams ihre Bemühungen auf Patches verschwenden, die nicht ausnutzbare Sicherheitslücken beheben, werden sie von wichtigeren Aufgaben abgehalten, wie etwa von Patches für gefährliche und ausnutzbare Schwachstellen. Das ist die Hauptursache für die heutige Trennung zwischen Sicherheits- und Engineering-Teams.

Wie können Unternehmen also die Grundursachen dieser Probleme angehen und eine bessere Integration zwischen Engineering und Sicherheit fördern? Hier sind drei Möglichkeiten, um häufige Frustrationspunkte hinsichtlich der Sicherheit schon von Grund auf zu verhindern.

1. Schalte das Rauschen aus und konzentriere dich auf umsetzbare, deutliche Signale

Übermäßige falsch positive Ergebnisse sind der am zweithäufigsten genannte Frustrationspunkt, den die Befragten im Sicherheitsbereich in unserer Umfrage angaben. Falsch positive Ergebnisse sind natürlich eine Herausforderung, sie sind aber oft auch ein verstecktes Problem im Sicherheitslückenmanagement.Wenn ein Unternehmen viele falsch positive Ergebnisse hat, kann dies ein Anzeichen dafür sein, dass vielleicht nicht alles Mögliche getan wurde, um sicherzustellen, dass die Sicherheitsergebnisse auch wirklich deutlich sind. Unternehmen sollten den Fokus ihrer Sicherheitsbemühungen auf das Wesentliche beschränken. Das bedeutet, dass herkömmliche Lösungen für statische Anwendungssicherheitstests (SAST) wahrscheinlich nicht ausreichen. SAST ist ein leistungsstarkes Tool, das jedoch viel seines Wertes verliert, wenn die Ergebnisse nicht genutzt werden können oder der entsprechende Kontext fehlt. Damit SAST so effektiv wie möglich ist, muss es nahtlos mit anderen Sicherheits- und Entwicklungstools zusammen eingesetzt werden und den Entwickler(inne)n zugänglich sein.Ein weiteres Problem ist, dass die meisten Scan-Tools ein sehr enges Kontextfenster haben, um die Sicherheitslücken zu verstehen. Dies ist einer der Bereiche, in denen KI mit KI-basierten Funktionen, die Sicherheitslücken erklären, helfen kann.

2. Minimiere den Tech-Stack und damit die Angriffsfläche

Nicht nur bei Sicherheitstests gilt, sich auf das Wesentliche zu konzentrieren – das sollte damit beginnen, wie ein Unternehmen überhaupt Software erstellt.

Obwohl KI verspricht, die Softwareentwicklungsprozesse zu vereinfachen, deutet unsere Umfrage darauf hin, dass viele Unternehmen noch einen langen Weg vor sich haben. Tatsächlich wollten jene Befragten, die KI nutzen, ihre Toolchain deutlich wahrscheinlicher konsolidieren als jene, die keine KI nutzen. Das lässt darauf schließen, dass der Anstieg an verschiedensten Problempunkten durch unterschiedliche KI-Modelle die Komplexität erhöht, anstatt sie zu verringern.

Die ständig zunehmende Komplexität der Tech-Stacks von Unternehmen trägt wesentlich zu Frustrationen im Bereich der Sicherheit bei. Eine gewisse Komplexität ist beim Aufbau großer, facettenreicher Softwaresysteme unvermeidlich. Unternehmen sollten jedoch Maßnahmen ergreifen, um Komplexität zu vermeiden, die sich aus suboptimalen Designentscheidungen ergibt, wie z. B. schwer zu wartender Code und redundante Abhängigkeiten. Diese unnötige Komplexität schafft eine größere Angriffsfläche und generiert mehr Sicherheitsscan-Ergebnisse, die Teams durchsuchen, priorisieren und bearbeiten müssen.

Unternehmen sollten bei der Softwareentwicklung den Grundsatz der Softwareminimierung walten lassen, also sich bewusst sein, welche Tools sie einsetzen und was sie in ihre Codebase integrieren möchten. Das trägt dazu bei, Abhängigkeiten zu minimieren, die Sicherheit der Software-Lieferkette zu verbessern, Scanner-Rauschen zu reduzieren und die Belastung der Entwickler(innen) zu reduzieren, wenn es darum geht, nicht kritische Probleme zu beheben.

3. Normalisiere die sogenannten „Paved Roads“

Sicherheitstests, die zu spät im Lebenszyklus der Softwareentwicklung stattfinden, waren ein weiterer der größten Frustrationspunkte, die unsere Umfrageteilnehmer(innen) erleben. Teams sind vielleicht frustriert, wenn sie etwas veröffentlichen wollen und sich das verzögert, weil eine Sicherheitslücke zu spät erkannt wird. In vielen Fällen wäre es jedoch gar nicht möglich gewesen, diese Sicherheitslücke früher zu finden. Es wäre jedoch möglich, einfach bereitstellbare, wiederverwendbare Sicherheitskomponenten zu nutzen und die Variablen und möglichen Sicherheitslücken dadurch einzugrenzen.Teams können Überraschungen in der späten Phase vermeiden, indem sie getestete und abgesicherte Entwurfsmuster basierend auf wiederholbaren Anwendungsfällen nutzen: den Ansatz der sogenannten „gepflasterten Straßen“ (Paved Roads). Eine gepflasterte Straße ist ein empfohlener Pfad, der eine kuratierte Auswahl an Tools, Prozessen und Komponenten enthält. Dieser Straße können Teams folgen, um sichere Anwendungen effizienter zu erstellen, z. B. indem sie GitOps nutzen, um gut konstruierte und getestete Infrastructure as Code zu versionieren und bereitzustellen, die sich für alle Workloads skalieren lässt.

Durch solche gepflasterten Straßen geht zwar etwas Flexibilität verloren, doch der betriebliche Aufwand und Überarbeitungen für Engineering-Teams werden reduziert und die Sicherheit wird verbessert. Das muss eine gemeinsame Anstrengung zwischen Sicherheit und Entwicklung sein. Das Sicherheitsteam kann helfen, gepflasterte Straßen zu entwerfen, aber das Engineering muss einbezogen werden, um sie als Teil der Codebasis zu betreiben und zu warten.

Sicherheit ist eine Domain, kein Team

Wir erleben bereits, dass Sicherheit immer mehr in den Bereich der Engineering-Teams rutscht, und können annehmen, dass die Grenzen zwischen den Bereichen auch weiter verschwimmen werden. Durch die rasche Einführung von KI und der damit einhergehenden Beschleunigung der Softwareentwicklung – 66 % der Befragten unserer Umfrage gaben an, dass sie Software bereits doppelt so schnell oder noch schneller veröffentlichen als im Vorjahr – ist es für Unternehmen äußerst wichtig, Systeme und Frameworks einzuführen, die für den größtmöglichen Sicherheitsvorteil optimiert sind. Deshalb ist die Idee einer kulturellen Trennung zwischen Entwicklung und Sicherheit nicht die ganze Geschichte. Es ist unerlässlich, eine Kultur der Zusammenarbeit zu fördern. Sicherheits- und Engineering-Teams müssen aber auch wirklich zusammenarbeiten, um die grundlegenden Aspekte der Softwareentwicklung neu zu durchdenken, wie etwa die Optimierung bestehender Codebases und der Aufbau skalierbarer Lösungen, bei denen das Engineering im Mittelpunkt steht und die nahtlos von technischen Teams im gesamten Unternehmen eingeführt werden können.

Anwendungssicherheit im digitalen Zeitalter

Lies dir die Ergebnisse unserer Umfrage unter mehr als 5.000 DevSecOps-Expert(inn)en aus der ganzen Welt durch und erfahre, wie Unternehmen mit zunehmenden Angriffsflächen und sich ändernden Einstellungen zu Sicherheit und KI zu kämpfen haben.
Bericht lesen

Wichtigste Erkenntnisse
  • Der Umstieg auf authentifiziertes Scannen im Schwachstellenmanagement verbessert zwar die Wirksamkeit, aber dadurch arbeiten Engineers ggf. an nicht kritischen Aufgaben, wodurch ein Konflikt zwischen den Sicherheits- und Engineering-Teams entstehen kann.
  • Ein minimalistischer Ansatz bei der Softwareentwicklung kann Abhängigkeiten auf ein Minimum reduzieren, das Scanner-Rauschen reduzieren und die Belastung der Entwickler(innen) verringern, um so zu verbesserter Software-Sicherheit beizutragen.
  • Mit einem Ansatz, der auf sogenannte „Paved Roads“, also bereits getestete und abgesicherte Entwurfsmuster mit wiederholbaren Anwendungsfällen basiert, kann die Last der Engineering-Teams verringert und die Sicherheit verbessert werden.