In den letzten Jahren hat sich DevSecOps zu einem der neuesten Schlagworte in Unternehmen entwickelt, die sich bemühen, ihre Initiativen für sichere Software zu verbessern. Aber was genau ist DevSecOps und wie setzen Sie es in die Realität um? Leider führt das Hinzufügen einiger Buchstaben zu DevOps nicht unbedingt zum Erfolg.
Für die meisten Software Security Cicles ist DevSecOps die Grundüberzeugung, dass Sicherheits- und Entwicklungsteams gemeinsam für die Stärkung der Sicherheit verantwortlich sein müssen. In der Realität bedeutet das die Verknüpfung von Entwicklungs-, Sicherheits- und Betriebsprozessen. Mit diesem Konzept soll Sicherheit so früh wie möglich gewährleistet werden, wobei der gesamte Lebenszyklus der Softwareentwicklung abgedeckt wird. Das Ziel ist Sicherheitslücken und damit verbundene Risiken zu finden, zu beheben und zu verhindern, ohne die Entwicklung zu verlangsamen und die Markteinführungszeit zu beeinträchtigen.
In der Theorie ist es leicht zu verstehen, was DevSecOps bedeutet und warum es zum Ziel vieler Unternehmen weltweit wird. Aber wie erreichen Sie es tatsächlich in der Realität? Die Wahrheit ist, dass viele Unternehmen, die versuchen, DevSecOps-Prinzipien umzusetzen, feststellen, dass ihr traditioneller Ansatz zur Codeanalyse nicht mehr mit der Geschwindigkeit und Häufigkeit der Veröffentlichung neuer Releases Schritt halten kann. Bevor wir jedoch den Ansatz der neuen Codeanalyse im Zusammenhang mit Initiativen für sichere Software erörtern, müssen wir den Ansatz der SAST + DAST-Analyse und die zugrunde liegenden Schwierigkeiten hervorheben, die bei modernen Softwareentwicklungsinitiativen häufig auftreten.
In der Vergangenheit implementierten Unternehmen AppSec-Programme, die hauptsächlich auf statische Code-Analyse (z. B. SAST) ausgelegt waren. Diese wurden zum Testen einer gesamten Codebasis gegen Ende des Entwicklungsprozesses verwendet, wobei Codierungsfehler erkannt wurden, die zu Schwachstellen führen konnten. Die Entwickler gingen zurück und reparierten die Codezeilen, die ein Problem darstellten. Die durch diesen Ansatz verursachten Verzögerungen waren kein großes Problem, da die Markteinführungszeit nicht die hohe Bedeutung für die Softwareentwicklung hatte, wie das heute der Fall ist.
Sobald SAST abgeschlossen war erfolgte die dynamische Codeanalyse (z. B. DAST), um simulierte Angriffe durchzuführen und zu sehen, wie eine Anwendung in der realen Welt reagieren könnte. Wenn weitere Probleme entdeckt wurden und behoben werden mussten, gingen die Entwickler erneut zurück und räumten den Code auf, um Laufzeitschwachstellen zu beheben. Obwohl SAST und DAST in der Regel von einem Team von Sicherheitsexperten gemanaged wurde, die hauptsächlich isoliert arbeiteten, war das Endergebnis eine bessere Sicherheit. Verzögerte Veröffentlichungen neuer Releases, Reibungen zwischen Sicherheit und Entwicklung sowie die Ablehnung von Sicherheitstests waren jedoch ein inhärentes Nebenprodukt.
Heute ist der mehrtägige SAST + DAST-Analyseansatz, der von einer kleinen Gruppe von Sicherheitsexperten durchgeführt wird, im Rahmen moderner DevSecOps Prozesse nicht mehr zeitgemäß, insbesondere wenn das Unternehmen mehrere Softwareversionen monatlich, wöchentlich oder sogar täglich benötigt. Obwohl an diesem Ansatz nichts grundlegend falsch war und das Endergebnis normalerweise eine sicherere Software war, passt der SAST + DAST-Analyseansatz einfach nicht gut zu den zugrunde liegenden Zielen von DevSecOps.
Aus einer einfachen funktionalen Perspektive gesehen müssen Unternehmen immer eine statische Code-Analyse durchführen. Der Schlüssel zu einem modernen, neuen Analyseansatz liegt jedoch darin, die Funktionalität in die Werkzeuge zu integrieren, die Entwickler beim Schreiben der Codezeilen verwenden. Ist das nicht der Fall, dann lässt sich der Analyseansatz nur selten in DevSecOps-Initiativen integrieren.
Zweitens und wiederum aus rein funktionaler Sicht müssen Unternehmen auch eine Software Composition Analysis (SCA) durchführen. Warum? Das ist einfach. In der modernen Anwendungsentwicklung sollten Unternehmen ihre Entwickler dazu ermutigen, Open Source zu verwenden, anstatt zu versuchen, das Rad neu zu erfinden. Die Verwendung von Open Source-Komponenten und Bibliotheken von Drittanbietern wird in der modernen Softwareentwicklung zur Selbstverständlichkeit. Wenn dieser Ansatz zur Software Composition Analysis im Einklang mit der statischen Code-Analyse durchgeführt werden kann, ist dies offensichtlich die Methode, die in DevSecOps am besten funktioniert, da auch sie die Bereitstellung der Software nicht verlangsamt.
Schließlich müssen Unternehmen, wieder aus rein funktionaler Sicht, auch interaktive Sicherheitsanalysen durchführen, während Builds ausgeführt werden. Wenn dieser Analyseansatz bereits während der Funktionsprüfung angewendet wird, umso besser. Wenn diese Analyse von QS-Testern durchgeführt wird, die dem Blick darauf richten, wie eine Anwendung in der Produktion funktioniert und die selten über umfassende Kenntnisse und Erfahrungen im Bereich Anwendungssicherheit verfügen, dann kann es leicht passieren, dass Sicherheitslücken sogar als zusätzlicher Vorteil identifiziert werden.
Der eigentliche Schlüssel zur erfolgreichen Implementierung neuer Codeanalyseansätze, die den DevSecOps-Zielen entsprechen, besteht darin, die Funktionen jeder Lösung zu verstehen und diese Funktionen dann anzuwenden, wann und wo sie am sinnvollsten sind. Und heute werden diese benötigten Funktionen wie folgt bereitgestellt:
Der eigentliche Vorteil von DevSecOps besteht darin, dass die Funktionalität aller drei Funktionen in einem nahtlosen Code-Analyse-Ansatz zusammengefasst wird, idealerweise alle aus einem Guss. Wenn dieser Ansatz erfolgreich, auf möglichst integrierte und automatisierte Weise und innerhalb der von Entwicklern verwendeten Werkzeuge erreicht wird, kann der Begriff DevSecOps tatsächlich verwirklicht werden.
