Ein Angebot von

Sichere, agile Softwareentwicklung: Muss es DevSecOps oder SecDevOps heißen?

| Autor / Redakteur: Mark Lambert * / Sebastian Gerstl

Bild 1: Der traditionelle DevSecOps-Ansatz in Sachen Security.
Bild 1: Der traditionelle DevSecOps-Ansatz in Sachen Security. (Bild: Parasoft)

DevSecOps oder SecDevOps: Auch wenn es wie eine semantische Spitzfindigkeit aussehen mag, liegt in der Reihenfolge der Worte doch einiges Gewicht. Wie kann es gelingen, die Herangehensweise an das Thema Security in der Entwicklung schon von der Einstellung her zu verändern?

Es steht außer Zweifel, dass DevOps und Security für Softwareorganisationen die Prioritätenliste anführen. Das Ergebnis der Integration des Security-Aspekts in DevOps war die Einführung der Begriffe SecDevOps und DevSecOps. Beide Begriffe werden zwar wie Synonyme behandelt, aber die Reihenfolge der Worte ist durchaus von Bedeutung. Denn in den meisten Fällen wird der Security-Aspekt erst nach erfolgter Bereitstellung gewissermaßen nachgerüstet. Dieser Beitrag beschreibt, weshalb das Abliefern sicherer Software einfacher ist, wenn die Security vom Beginn des Software-Entwicklungsprozesses an als integraler Bestandteil der Entwicklung betrachtet wird und nicht als ein Tor, das man am Ende der Ablieferungspipeline noch passieren muss.

Was bedeutet Security in DevSecOps?

Ungeachtet der verstärkten Fokussierung auf das Thema Security stellt es für Softwareteams eine Herausforderung dar, Security in einen Prozess und in eine Pipeline einzubinden. Der Druck, ein Projekt im Zeitplan und unter Einhaltung des vorgegebenen Finanzbudgets fertigzustellen, lässt andere Überlegungen oftmals in den Hintergrund treten. Infolgedessen neigen wir dazu, Security als einen letzten Arbeitsschritt zu betrachten, den ein Release-Kandidat noch absolvieren muss, wie Bild 1 illustriert.

Security-Know-how ist in der Regel dünn gesät und in einem Unternehmen nur bei wenigen Personen vorhanden, die zudem oft einem zentralen Security-Team angehören. Diesem Team kommt die Aufgabe zu, das jeweilige Produkt mithilfe seiner Trickkiste zu testen, um vor dem Einsatz etwaige Schwachstellen im Release-Kandidaten aufzudecken. Wenn das Team nun – was unausweichlich ist – eine Sicherheitslücke findet, überbringt es diese „schlechte Nachricht“ an das Entwicklungsteam. Dieses wiederum besitzt weder die entsprechende Ausbildung in Sachen Security noch das Wissen, wie man die vom Security-Team genutzten Tools anwendet. Als Folge werden die Mitglieder des Security-Teams häufig als „die Bösen“ angesehen, die den Release-Prozess „nur wegen einiger Security-Schwachstellen“ aufhalten. Wie sieht also die typische Reaktion des Teams aus? Anschaulich ist das in Bild 2 erklärt.

Seien wir einmal ehrlich: Es ist eine harte Nuss, Security-Nachbesserungen, Kontrollmechanismen und Codierstandards in ein Projekt einzubringen, das vom Entwicklungsteam bereits als abgeschlossen angesehen wird. Also passiert Folgendes: Das Produkt verlässt das Unternehmen trotz bekannter (und auch unbekannter) Sicherheitslücken und möglicherweise mit dem Versprechen, diese „im nächsten Release zu beseitigen“. Genau dies passiert, wenn man das Thema Security erst nach der Entwicklung berücksichtigt: zuerst „Dev“, dann „Sec“, dann „Ops“. Auch wenn es so nicht beabsichtigt ist - in vielen Unternehmen ist genau dies die Realität. Abhilfe verspricht die nachfolgend beschriebene, bessere Herangehensweise.

Was bedeutet Security in SecDevOps?

Security-Kontrollen, Richtlinien, Codierstandards und Policys müssen vollständig in den Softwareentwicklungsprozess integriert sein. Erreichen lässt sich dies, indem man den Security-Aspekt ganz von Anfang an zu einem Bestandteil des Prozesses und der Pipeline macht: zuerst „Sec“, dann „Dev“ und dann „Ops“. Das Security-Team (vielleicht auch ein auf Security spezialisierter Architekturentwickler oder leitender Entwickler) definiert als erstes die notwendigen Policys für das Team.

Bei diesen Policys kann es sich um sichere Codierstandards, Regeln zur Vermeidung von unsicheren APIs und unzureichender Verschlüsselung, Anweisungen für die Verwendung dynamischer und statischer Analysen sowie um Testrichtlinien handeln. Ziel ist, dass die Entwickler im Rahmen ihrer täglichen Arbeit auf eine sicherere Software hinarbeiten. Automatisierung trägt dazu bei, diese Zielsetzung in die Tat umzusetzen.

Mithilfe der Automatisierung gelingt es, das Security-Konzept zeitlich vorzuverlegen („shift left”) und eine SecDevOps-Strategie zu realisieren, die etwa wie folgt aussieht (siehe Bild 3).

Iterative Verbesserungen der Policys bewirken, dass es zu weniger disruptiven Eskalationen in späten Phasen des Zyklus kommt (siehe auch Bild 4). Dieses inkrementelle, integrierte Konzept bewährt sich wesentlich besser als der Versuch, am Ende des Projekts ein Security-Audit nachzuschieben.

Wie lässt sich das Konzept umsetzen?

Dass das Thema Security die Entwickler zusätzlich fordert, lässt sich nicht abstreiten. Die Art und Weise aber, wie man damit umgeht, macht den Unterschied zwischen einem rechtzeitig abgelieferten, sicheren Produkt und einem verspätet abgelieferten, unsicheren Produkt aus. Entscheidend ist die Einbindung des Security-Aspekts in den bestehenden Entwicklungsprozess. Dies wiederum ist mit der Integration von CWE-kompatiblen Testwerkzeugen, wie sie Parasoft anbietet, möglich, mit denen das Thema Security zu einem Bestandteil der Qualität und des allgemeinen Arbeitsablaufs wird.

Ein auf Security fokussierter Arbeitsablauf verwandelt Security in ein Element der Qualität

Am Beginn des Arbeitsablaufs steht die sichere Codier-Policy. Der Entwicklungsleiter stellt für das übrige Team eine Konfiguration (möglicherweise auf der Basis von Codierrichtlinien wie CERT, CWE, OWASP, UL-2900 oder PCI-DSS) zusammen, die dann direkt in der IDE verwendet werden kann. Hierdurch erhält jeder Entwickler die Gelegenheit, den Code lokal auf seinem System zu testen, bevor die Übergabe an die Versionsverwaltung erfolgt. So lassen sich Security-Verletzungen unmittelbar am Ort des Entstehens aufdecken und beseitigen – zu geringeren Kosten und mit weniger Aufwand.

Bild 5: Der komplette SecDevOps-Arbeitsablauf.
Bild 5: Der komplette SecDevOps-Arbeitsablauf. (Bild: Parasoft)

Die gleiche Konfiguration wird dann von der Analyse genutzt, die im Zuge des Build-Prozesses erfolgt. Diese umfassende Analyse geht über den Umfang des lokal modifizierten Codes des Entwicklers hinaus und bildet für die Ablieferungs-Pipeline gleichsam ein Sicherheitsnetz, welches verhindert, dass unsicherer Code in die nachfolgenden Phasen gelangt.

Zum Abschluss werden die Ergebnisse der Analyse über das zentrale Report- und Analyse-Dashboard an die IDE des Entwicklers zurückgeführt. Damit ist es möglich, den Fortschritt zu verfolgen, Kurskorrekturen vorzunehmen und Audit-Reports zu erstellen – und zwar alles in Echtzeit.

Manager und Sicherheitsverantwortliche können Projekte nunmehr mit dem folgenden Dashboard auf der Grundlage von Security-Standards wie etwa CWE bewerten (siehe auch Bild 6). Mit diesen Dashboards lassen sich Trends visualisieren und Fragen beantworten wie zum Beispiel „Verbessert sich das Projekt oder verschlechtert es sich?“ oder „Welche Bereiche des Codes verursachen die meisten Probleme?“.

Die Fähigkeit, diese und weitere Fragen zu beantworten und entsprechend aktiv zu werden, bewirkt eine Transformation des Entwicklungs-Teams von DevSecOps zu SecDevOps.

Zusammenfassung: DevSecOps und SecDevOps – Die Reihenfolge macht den Unterschied

Auch wenn DevSecOps und SecDevOps oft wie Synonyme behandelt werden, ist die Reihenfolge der Begriffe ebenso wichtig wie die Folgewirkungen der Tools, Techniken und Prozesse, die das jeweilige Wort impliziert. Security wird häufig nur als Anhängsel oder ein finaler Arbeitsgang vor der Herausgabe eines Produkts behandelt, aber das Reparieren von Security-Problemen gestaltet sich schwierig, wenn ein Produkt kurz vor der Auslieferung steht. Es ist also erfolgsentscheidend die Berücksichtigung des Security-Aspekts zeitlich vorzuverlegen. Security muss ein Bestandteil der täglichen Arbeit eines jeden Entwicklers und in die Software-Pipeline integriert sein. Anbieter wie Parasoft automatisieren die zeitliche Vorverlegung der Security-Maßnahmen und der entsprechenden Policys, damit Security zu einem festen Element der Pipeline wird und die Auswirkungen und Risiken von SecDevOps (und auch DevSecOps!) reduziert werden.

‚Shift Left‘: Wie man Performance-Tests in der Software-Entwicklung vorverlegt

‚Shift Left‘: Wie man Performance-Tests in der Software-Entwicklung vorverlegt

14.02.19 - Tests werden immer früher in die unterschiedlichen Stadien der Software-Entwicklung eingebunden. Im Vergleich mit den Stufen klassischer Methoden findet eine „Linksverschiebung” statt. Wie aber verlegt man Tests sinnvoll vor, wenn man traditionelle Modelle gewohnt ist? lesen

5 häufige DevOps-Fehler und wie man sie vermeidet

5 häufige DevOps-Fehler und wie man sie vermeidet

15.03.19 - Continuous Integration und Continuous Deployment helfen dabei, die Softwareentwicklung effizienter zu gestalten. Im Zuge von DevOps-Strategien werden die beiden Prinzipien kombiniert. Fünf gängige Fehler lassen sich dabei von Vornherein vermeiden. lesen

* Mark Lambert ist Vice President Products bei Parasoft Inc.

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 45832904 / Agilität)