Wie DevSecOps Citizen-Entwickler unterstützt

Bis 2025 insgesamt globale Datenerstellung wird 181 Zettabyte erreichen. Für Unternehmen sind diese Daten ein Gewinn, der es ihnen ermöglicht, eine Vielzahl von Technologieplattformen zu nutzen, um hochgradig personalisierte Kundenerlebnisse zu schaffen, die Loyalität schaffen und neue Geschäfte anziehen. Diese Erfahrungen sind jedoch von Cloud-Infrastrukturen abhängig, die gemeinsame Sicherheitsmodi verwenden. Hierin liegt das Risiko, und es nimmt zu, da die Technologie wächst und eine neue Armee von Bürgerentwicklern integriert wird, die Low-Code- und No-Code-Plattformen nutzen.

Die Vererbungsmentalität verstehen und überwinden 

Gartner schätzt, dass bis 2025 70 % der Unternehmensanwendungen auf Low-Code- und No-Code-Plattformen wie Salesforce und ServiceNow erstellt werden. Mit einer vererbungsbasierten Denkweise zu reagieren, ist ein sicherer Weg, mehr als zwei Drittel der Unternehmensanwendungen vor einem Ausfall zu schützen.   

„Vererbungsmentalität“ ist eine treffende Beschreibung für die Probleme, mit denen die Infrastruktur zu kämpfen hat. Es erinnert an reiche, verwöhnte Kinder, die völlig von der geleisteten Arbeit und den Menschen abhängig sind, die vor ihnen kamen. Das ist kein guter Weg, ein Vermächtnis aufzubauen, und es ist ein ebenso schlechter Weg, ein System aufzubauen.

Wenn Sie eine veraltete Denkweise haben, gehen Sie davon aus, dass die Infrastruktur eingerichtet ist. Die Plattform ist sicher und die Sicherheit ist integriert. Vertrauen wird einfach deshalb vorausgesetzt, weil die Technologie schon vor dem Administrator vorhanden war.

Diese Vererbungsmentalität plagt Low-Code- und No-Code-Plattformen. Benutzer verlassen sich auf die Sicherheit einer Plattform, die sie durch die gesamte Unternehmensinfrastruktur führt. Stattdessen sollte die Sicherheit dieser Plattform nur für diese Plattform gelten.

Nehmen wir an, Salesforce-Entwickler erstellen ein automatisiertes Zuweisungsprogramm für neue Leads. Sie verwenden es innerhalb von Salesforce für interne Aufgaben, und es ist in Ordnung. Sie können sich auf die Sicherheit der Plattform verlassen. Sie beschließen, es zu erweitern, um die Automatisierung zu verbessern. Sie verbinden dieses Programm mit einem externen CRM wie ServiceNow, SAP oder Oracle. Die Vererbungsmentalität setzt sich durch: Salesforce ist sicher. ServiceNow, SAP oder der Drittanbieter sind sicher.

Salesforce + Drittanbieter = sicher.

Aber in diesem Pluszeichen steckt eine Menge Unbekanntes. Wie verbinden Sie das in Salesforce erstellte interne Programm sicher und konform mit dem externen Programm, das auf der Plattform eines Drittanbieters erstellt wurde? In diesem einzelnen Charakter steckt viel Raum für Fehler.  

Und das ist nur eine Verbindung. Viele in Salesforce erstellte Programme berühren Hunderte andere. Das bedeutet, dass Hunderte von Unbekannten von Leuten, die wenig bis gar keine Entwicklungserfahrung haben, wie das oben beschriebene Pluszeichen behandelt werden.  

Die einzige Lösung besteht darin, diese Entwicklung durch eine Rückkehr zu den DevSecOps-Prinzipien wieder auf den Boden der Tatsachen zurückzuführen.

Etablierung des DevSecOps Frameworks 

DevSecOps Frameworks wurden geschrieben, neu geschrieben und noch einmal geschrieben, seit das Konzept erstellt wurde. Bei der Etablierung muss das Rad nicht neu erfunden werden, vor allem nicht SAFECode und die Cloud Security Alliance hat sechs Säulen aufgebaut:

1. Gemeinsame Verantwortung: Sicherheit liegt in der Verantwortung jedes Einzelnen im Unternehmen – aber Menschen können keine Standards einhalten, die sie nicht kennen. Es sollten Führungskräfte eingesetzt werden, die die Cybersicherheitsrichtlinien vorantreiben und sicherstellen, dass diese im gesamten Unternehmen verbreitet werden.  
2. Zusammenarbeit und Integration: Wissen muss geteilt und weitergegeben werden. Der halbe Grund dafür, dass Unternehmen in die alte Denkweise verfallen, ist, dass jeder, der das alte System kannte, nicht mehr existiert. Kontinuierlicher Wissensaustausch hilft, dieses Problem zu beseitigen.
3. Pragmatische Umsetzung: Die pragmatische Implementierung knüpft an die Entwicklererfahrung an. Schwierige, alltägliche und unhandliche Prozesse werden nicht lange befolgt. Sicherheit sollte in die Entwicklungspraktiken integriert werden – das heißt, jede Codezeile erfordert eine Testzeile. Ein leistungsstarkes Unternehmen würde noch einen Schritt weiter gehen und ein Tool verwenden, um jede Testcodezeile zu automatisieren.
4. Compliance und Entwicklung: Compliance-Anforderungen sollten den Entwicklungsprozess so leiten, dass Entwickler nicht davon abweichen können. Ein Entwickler für ein Finanzinstitut würde beispielsweise an einer Plattform arbeiten, die so konzipiert ist, dass sie dem Gramm-Leach-Bliley Act entspricht. Der Entwickler muss die einzelnen Einzelheiten des Gesetzes nicht kennen, um konform zu sein, da diese in die Plattform integriert sind.  
5. Automation: Vorhersehbare, wiederholbare und umfangreiche Aufgaben sollten nach Möglichkeit automatisiert werden, um die Entwickler zu entlasten und das Risiko menschlicher Fehler zu verringern.
6. Monitor: Moderne Cloud-Infrastrukturen verändern und wachsen. Es ist wichtig, den Überblick zu behalten – idealerweise durch eine Form der Orchestrierung, die einen Überblick über alle verschiedenen Zusammenhänge ermöglicht.

In einer Low- oder No-Code In Bezug auf die Umwelt sind diese Säulen nicht so einfach, wie man erwarten würde. Bei den Personen, die diese Tools verwenden, handelt es sich häufig um Geschäftsexperten, die kaum mit den DevSecOps-Grundlagen vertraut sind.

Menschen, Prozesse und Technologie zusammenbringen

Der Einsatz von Low-Code- und No-Code-Plattformen kann tatsächlich dazu beitragen, diese Kompetenzlücke zu schließen. Mitarbeiter möchten neue Fähigkeiten erlernen. Unternehmen können dies unterstützen, indem sie ein DevSecOps-Framework einrichten, das sich auf Menschen, Prozesse und Technologie konzentriert. 

• Prozesse: In einer Zero-Trust-Umgebung müssen sich Low-Code- und No-Code-Entwickler keine Sorgen darüber machen, Verbindungen herzustellen, die die Systemintegrität gefährden, weil sie dazu nicht in der Lage sind. Sie verfügen über keine grundsätzliche Autorität außerhalb ihres isolierten Systems.  
• Menschen: Eine Kultur der Verantwortung unterscheidet sich von einer Kultur der Schuldzuweisungen. Verantwortlichkeit bedeutet, dass sich Einzelpersonen wohl fühlen, wenn sie ein Problem oder einen Fehler melden, weil der Fokus auf dem Problem und nicht auf der Person liegt.
• Technologie: Technologie ist das größte Hindernis für die ordnungsgemäße Umsetzung der DevSecOps-Prinzipien, da sie nicht in der Hand der Entwickler liegt. Sie müssen das nutzen, was die Organisation ihnen gibt. Wenn diese Technologie nicht funktioniert, werden Entwickler Problemumgehungen finden, die weder sicher noch sicher sind. Im Wesentlichen wird die Technologie zu einem großen Schatten-IT-Generator.

Wir leben in einer aufregenden Zeit der Entwicklung. Immer mehr Menschen haben die Möglichkeit, Software zu entwickeln, Strategien zu testen und den Geschäftswert zu steigern. Aber damit ist auch ein Risiko verbunden. Unternehmen, die nach Möglichkeiten suchen, dieses Risiko auf die Technologie abzuwälzen, werden ihre Entwicklung auf dem Boden der Tatsachen halten und gleichzeitig Raum für Entdeckungen lassen.