Security by Design durch Integration von DevSecOps in Entwicklerteams

Nach wie vor integrieren zu wenige Entwickler Sicherheitsmechanismen von Grund auf in ihre Anwendungen, warnen die Sicherheitsexperten von Radware. Hacker können daher zunehmend Schwachstellen in Anwendungen oder APIs ausnutzen, die während des Entwicklungsprozesses übersehen wurden. [...]

Die Aufgabe von DevSecOps besteht darin, eingebettete Sicherheit von unten nach oben aufzubauen, die über rein technologische Lösungen hinausgeht, indem sie die Kluft zwischen den widersprüchlichen Agenden der Anwendungsentwickler und der Sicherheitsverantwortlichen überbrückt. (c) leowolfert -stock.adobe.com

Laut Untersuchungen von Radware sind DevOps und App-Entwickler sehr offen gegenüber Open Source Code (67 Prozent), Microservices (68 Prozent) und serverlosen Frameworks (73 Prozent), die im Allgemeinen standardmäßig als sicherer empfunden werden. Darüber hinaus werden 70 Prozent der Webanwendungen mindestens einmal pro Woche modifiziert. In der Folge versäumt es über die Hälfte der Unternehmen, die Sicherheit in ihre CI/CD-Pipeline (Continuous Integration/Continuous Delivery) zu integrieren. Stattdessen ziehen Entwicklerteams es vor, sich im Nachhinein mit möglichen Schwachstellen und Risiken zu befassen, wenn sie höchstwahrscheinlich längst mit einer anderen Aufgabe beschäftigt sind. Mit anderen Worten: Sicherheit ist nicht in die App integriert, und Sicherheitslücken gerade in APIs fallen während des Entwicklungsprozesses häufig nicht auf.

Eine mögliche Lösung dieses Problems ist laut Radware die Integration von DevSecOps-Ingenieuren in die Entwicklungsteams. Die Aufgabe von DevSecOps besteht darin, eingebettete Sicherheit von unten nach oben aufzubauen, die über rein technologische Lösungen hinausgeht, indem sie die Kluft zwischen den widersprüchlichen Agenden der Anwendungsentwickler und der Sicherheitsverantwortlichen überbrückt. DevSecOps sind normalerweise Anwendungssicherheitsexperten, die als Teil des Anwendungsentwicklungsteams arbeiten, um sicheren Code zu schreiben. Zwei von fünf Organisationen haben nach Umfragen von Radware jedoch noch keinen DevSecOps-Experten eingestellt.

Drei erforderliche Fähigkeiten

Dabei ist die Integration eines DevSecOps-Ingenieurs in das Team ein großer erster Schritt. Ihnen sollten jedoch die Werkzeuge an die Hand gegeben werden, um eine Wirkung zu erzielen – das heißt sichereren Code freizugeben, der auf Schwachstellen gescannt wird, eingebettete Zugangskontrollen hat und sensible Daten schützt mit dem Endziel, tatsächlich sicherere Softwareprodukte zu entwickeln und zu liefern. Um dieses Ziel zu erreichen, ist mehr erforderlich als nur Wissen über Anwendungssicherheit:

  • Fähigkeiten im Bereich zwischenmenschlicher Beziehungen sind ebenso wichtig wie technische Fähigkeiten, etwa das Schreiben von Code oder die Entwicklung von Software. Hier geht es um Konfliktmanagement und die Fähigkeit, alle – Kollegen wie Vorgesetzte – auf ein gemeinsames Ziel auszurichten und das richtige Gleichgewicht zwischen Produktivität und Sicherheit zu finden.
  • Vertrautheit mit möglichst vielen CI/CD-Tools. Da jedes Team unterschiedliche Tools verwendet und jeder DevOps-Leiter eine andere Architektur für seine CI/CD-Pipeline entwirft, wird nicht jede Sicherheitslösung passen. Wenn sie nicht passt, führt dies zu Unterbrechungen, verlangsamt die Freigabe und macht das Unternehmen verwundbar. Selbst die besten Sicherheitslösungen lassen sich nicht immer nahtlos in die CI/CD-Pipeline integrieren, und DevOps würde normalerweise einer nahtlosen Integration einen höheren Stellenwert beimessen als der Sicherheit. Dies bedeutet, dass der DevSecOps-Ingenieur eine breite Übersicht über Sicherheitswerkzeuge und deren Interoperabilität mit gängigen Technologien verfügen muss, die in verschiedenen Entwicklungsumgebungen eingesetzt werden. Die Fähigkeit, Sicherheitsmaßnahmen schnell in die CI/CD-Pipeline-Prozesse zu integrieren, ist das, worum es bei DevSecOps geht.
  • Expertise im Threat Modeling: Ein Sicherheitshintergrund ist ein guter Anfang, zumal es sich bei DevSecOps in vielen Fällen um Software-Ingenieure handelt, die Sicherheitsverantwortung übernommen haben. Dennoch sind Kenntnisse im Bereich der Bedrohungsmodellierung von entscheidender Bedeutung. Der DevSecOps-Ingenieur geht das Design durch, um Schwachstellen in Komponenten und Datenflüssen zu finden, um später mögliche Bedrohungen abzubilden und schließlich die Sicherheitskontrollen und -lösungen zu priorisieren, die eingesetzt werden sollen.

Der Erfolg von DevSecOps hängt sehr stark von dem Verständnis ab, dass die Rolle nicht nur technischer, sondern auch verfahrenstechnischer Natur ist. Sie sind diejenigen, die integrierte Sicherheit von unten nach oben erleichtern können, um die von oben nach unten gestellten Erwartungen zu erfüllen. Die Einführung von Anwendungen auf der Grundlage eines sichereren Codes wird nicht alle Sicherheitsrisiken lösen, aber zumindest das Vertrauen der Kunden fördern.


Mehr Artikel

News

Public Key Infrastructure: Best Practices für einen erfolgreichen Zertifikats-Widerruf

Um die Sicherheit ihrer Public Key Infrastructure (PKI) aufrecht zu erhalten, müssen PKI-Teams, sobald bei einer Zertifizierungsstelle eine Sicherheitslücke entdeckt worden ist, sämtliche betroffenen Zertifikate widerrufen. Ein wichtiger Vorgang, der zwar nicht regelmäßig, aber doch so häufig auftritt, dass es sich lohnt, PKI-Teams einige Best Practices für einen effektiven und effizienten Zertifikatswiderruf an die Hand zu geben. […]

News

UBIT Security-Talk: Cyberkriminalität wächst unaufhaltsam

Jedes Unternehmen, das IT-Systeme nutzt, ist potenziell gefährdet Opfer von Cyberkriminalität zu werden, denn die Bedrohung und die Anzahl der Hackerangriffe in Österreich nimmt stetig zu. Die Experts Group IT-Security der Wirtschaftskammer Salzburg lädt am 11. November 2024 zum „UBIT Security-Talk Cyber Defense“ ein, um Unternehmen in Salzburg zu unterstützen, sich besser gegen diese Bedrohungen zu wappnen. […]

Be the first to comment

Leave a Reply

Your email address will not be published.


*