Das goldene Zeitalter der DevOps-Software-Best Practices hat sich wie eine gemütliche Decke der Konsistenz über uns gelegt. Innerhalb dieser Utopie des perfekten Änderungsmanagements und gut geölter Industriestandards entstand eine natürliche Entwicklung hin zu einer wasserdichten Cybersicherheit namens DevSecOps.

Natürlich, wenn ich „goldenes Zeitalter“ sage, meine ich eigentlich „Wilder Westen“. Und mit „gemütliche Decke der Konsistenz“ meine ich wirklich „kaltes Papierblatt der Unsicherheit“. In der gesamten Technologiebranche bedeutet die Implementierung von DevOps für verschiedene Unternehmen unterschiedliche Dinge – sogar innerhalb einiger Unternehmen bedeutet es für verschiedene Teams unterschiedliche Dinge.

Entwirrung von DevSecOps

Seit der Begriff vor einem Jahrzehnt geprägt wurde, ist die Bedeutung von DevOps unklar geblieben, und die heutige Landschaft stellt ein Sammelsurium von DevOps-Workflows dar. Grundpfeiler wie CI/CD-Tools haben eine weit verbreitete Akzeptanz erfahren, während Produkte wie Value Stream Management Software nur in wenigen ausgewählten Unternehmen verstreut sind.

In der Technologiewelt bedeutet das, dass es der perfekte Zeitpunkt ist, um eine Störung zu verursachen – und DevSecOps ist genau das Richtige.

Was ist DevSecOps?

DevSecOps, das für Development Security Operations steht, stellt einen notwendigen Aufruf zum Handeln dar, verpackt als unerträgliches Schlagwort. Die zugrunde liegende Botschaft ist dringend und eindringlich: Cybersicherheit muss ebenfalls ein Standard im DevOps-Workflow (Entwicklung und IT-Betrieb) sein. Angesichts der Natur von Continuous Delivery Software-Umgebungen ist es für Cybersicherheitsexperten zunehmend schwierig geworden, nach den Entwicklern aufzuräumen. DevSecOps zielt darauf ab, von Anfang an hochsicheren Code zu erstellen, anstatt im Nachhinein.

(Was den Begriff selbst betrifft, nun ja... er setzt einen interessanten Präzedenzfall für Namenskonventionen. Es gibt viele nützliche Prinzipien, die in erfolgreiche DevOps-Prozesse integriert werden können – und sollten –, aber nennen wir es nicht DevSecPrivMindfulnessAIOps.)

Es bleibt abzuwarten, ob sich der Begriff DevSecOps durchsetzt, aber vorerst erfüllt er seine Aufgabe und jagt der Branche einen Schauer über den Rücken. Vielleicht hat das mehr mit der übelkeitserregenden Terminologie zu tun als mit ihren Implikationen, aber es dient dennoch als Weckruf für Entwicklungsteams über die sehr reale Notwendigkeit für sicheren Code. Wie beantworten Unternehmen und Teams diesen Aufruf?

DevSecOps-Tools

DevOps-Teams benötigen den richtigen Software-Stack, um DevSecOps oder Sicherheit durch Design vollständig zu realisieren. Darüber hinaus müssen diese Tools nahtlos in bestehende Pipelines integriert werden.

In einer idealen Welt würde das perfekte Produkt für die Aufgabe auch den Großteil der Arbeitslast automatisieren. Entwickler werden sich nicht auf den Rhythmus einer starken Cybersicherheit einlassen, es sei denn, die Lösung ist kopfschmerzfrei. Abgesehen von ein paar festen Schulungssitzungen und einer stetigen Versorgung mit Ibuprofen, welche Optionen gibt es?

Nachdem sie nach einigen Jahren der Stagnation endlich Fuß auf dem Markt gefasst haben, bieten Software Composition Analysis (SCA) Tools eine nahtlose, automatisierte Lösung für Entwickler, um die Open-Source- und Drittanbieter-Elemente ihrer Anwendungen zu verwalten. Der Anwendungsentwicklungsprozess neigt dazu, schnell einen beeindruckenden Haufen von Drittanbieter-Abhängigkeiten und -Komponenten anzusammeln. SCA-Tools integrieren sich in bestehende DevOps-Workflows, um diese Komponenten ständig auf Schwachstellen und Updates zu scannen und so umfassende Sicherheit inmitten des Spaghetti von API-Aufrufen zu gewährleisten. Diese Produkte gehen dann noch einen Schritt weiter und schlagen sogar Schwachstellenbehebungen bei der Erkennung vor, was sie zu einer Notwendigkeit für jeden aufstrebenden DevSecOps-Bereich macht.
Andere Legacy-Tools, die verwendet und kombiniert werden können, um eine wasserdichte DevSecOps-Umgebung zu schaffen, umfassen Vulnerability Scanner Software, Dynamic Application Security Testing (DAST) Software, Static Application Security Testing (SAST) Software oder Penetration Testing Software... schauen Sie, es gibt viele Lösungen zur Auswahl. Alle tragen einzigartigen Wert zu einem DevSecOps-Workflow bei.

Die DevSecOps-Methodik ist weit davon entfernt, standardisiert zu sein

Die Fülle an verschiedenen Lösungen, die DevSecOps ansprechen, wenn wir es wirklich so nennen, scheint großartig. Allerdings hat sich die Branche nicht auf eine standardisierte Mischung von Tools für eine „Best Practice“-DevSecOps-Arbeitsumgebung geeinigt. Infolgedessen enden wir mit einer wischiwaschi Arbeitsplatzphilosophie, anstatt eines festgelegten Verfahrenssatzes zur tatsächlichen Implementierung. Kommt Ihnen das bekannt vor?

Wenn Unternehmen vermeiden wollen, das Implementierungszirkus zu wiederholen, den wir DevOps nennen, sind sie auf einem schlechten Weg. Schauen Sie sich nur die Nutzungsausbreitung in dieser Umfrage von 57 Cybersicherheitsexperten aus verschiedenen Branchen an, die von ZeroNorth durchgeführt wurde.

Diese Ergebnisse rufen nicht gerade Phrasen wie „Industriestandard“ oder „alles ist gut“ hervor. Von sieben möglichen Scan- und Test-Tools wird nur eines von mehr als einem Viertel der befragten Fachleute unternehmensweit genutzt. Was besonders beunruhigend ist, wenn man bedenkt, dass das nicht einmal der vollständige Datensatz ist.

Diese spezielle Grafik musste auf zwei verschiedene Seiten des ZeroNorth-Berichts aufgeteilt werden. Und sicher, vielleicht hätten sie die Schrift ein wenig kleiner machen können. Aber das sind immer noch insgesamt 12 verschiedene Arten von brauchbaren Cybersicherheitstools – alle mit extrem unterschiedlicher Implementierung in der Branche.

Der gleiche Bericht ergab, dass 98% der Fachleute Cybersicherheit in DevOps als entweder „extrem wichtig“ oder „sehr wichtig“ betrachten. Jeder ist sich im Allgemeinen einig, dass DevOps-Teams Cybersicherheits-Best-Practices übernehmen müssen, aber jeder hat unterschiedliche Vorstellungen davon, was das bedeutet. Dieses Problem ist inhärent in vagen Philosophien wie „DevOps“ und „DevSecOps“: Jedes Team wird diese Philosophien basierend auf ihrem eigenen internen Workflow und ihrer Kultur interpretieren.

Die Zukunft von DevSecOps in DevOps- und CI/CD-Initiativen

Basierend auf dem branchenweiten Gefühl für bessere Sicherheit im Zeitalter der digitalen Transformation scheint es wahrscheinlich, dass die DevSecOps-Philosophie hier bleibt. Die Frage ist, ob diese Philosophie zu einer standardisierten Anwendung führen wird – und wie lange das dauern wird. Wenn das vergangene Jahrzehnt von DevOps ein Anhaltspunkt ist, werden wir wahrscheinlich ein Flickwerk von Implementierungen sehen, angetrieben von Schlagwörtern und Träumen.

Es ist jedoch möglich, dass die branchenweite Erfahrung mit DevOps für effektivere digitale Transformationsbemühungen in der Zukunft vorbereitet hat. Jetzt, da Unternehmen mit Cloud, DevOps und CI/CD-Initiativen Fuß gefasst haben, könnte eine glänzende neue Ergänzung der Arbeitsumgebung weniger ätherisch erscheinen. Vielleicht wird die entscheidende Dringlichkeit für Sicherheit eine einheitliche Front motivieren.

In welcher Form auch immer, wir können erwarten, dass in Zukunft große Verschiebungen hin zu DevSecOps in verschiedenen Branchen stattfinden werden. Es könnte auf dem Weg dorthin Wachstumsschmerzen geben, insbesondere wenn Entwickler und Geschäftspartner neue Sicherheitsinitiativen als Hindernisse innerhalb effizienter Workflows betrachten. Unternehmen müssen jedoch Wege finden, um sichere DevOps zu realisieren, wenn sie das Risiko kostspieliger Sicherheitsfiaskos vermeiden wollen.