Time to Production: DevSecOps – die Deployment-Pipeline für sichere Software

Ähnlich wie DevOps ist auch DevSecOps eine Zusammensetzung von Begriffen – Development, Security und Operations – und ist als Modell zu verstehen, nicht als Rolle. Gemeint ist in diesem Kontext somit nicht der Entwickler, der Zugriff auf die Produktionssysteme hat und dabei auch noch für die Sicherheit zuständig ist. Die Verantwortungsbereiche von Systemadministratoren, Entwicklern, Testern, Produktverantwortlichen und Sicherheitsexperten (z.B.  Informationssicherheitsbeauftragte, ISMS-Beauftragte, Risikomanager, Datenschutzbeauftragte oder Auditoren) werden stets ein der Unternehmensgröße zumutbares Maß an Trennung erfordern. Ähnlich DevOps verfolgt auch DevSecOps das Ideal einer ständigen engen Zusammenarbeit dieser Bereiche (nicht ihre Zusammenlegung) und das gegenseitige Lernen an bewährten Vorgehensweisen und Technologien.

Sicherheit als Qualitätskriterium

DevSecOps ist nichts anderes als die praktische Umsetzung eines ganzheitlichen IT-Sicherheitskonzepts, wie ich es in meinem Beitrag “4 zentrale Bausteine für mehr IT-Sicherheit” bereits beschrieben habe. Dabei geht es im Prinzip darum, dass Sicherheit von allen am Software-Lebenszyklus Beteiligten als Qualitätsmerkmal verstanden, der Grundstein für Qualität jedoch stets am Anfang gelegt wird.

Sichere Entwicklung ist nur der erste Schritt

Das Rezept, um qualitativ hochwertige Software zu entwickeln, ist bekannt und bewährt: Es werden Entwickler mit einem guten Qualitätsbewusstsein sowie Teams mit kollektiver Verantwortung für die Gesamtqualität benötigt. Des Weiteren stabile und bewährte Vorgehensmodelle, Basissysteme, Werkzeuge und Komponenten sowie eine Lösung, um Entwicklern benötigtes Wissen zur richtigen Zeit zugänglich zu machen. Bewährt haben sich z.B. projektbezogene Trainings über Best und Bad Practices. In Bezug auf die Sicherheit sollten sich Entwickler regelmäßig in die Rolle eines Angreifers versetzen und darüber nachdenken, wodurch ihre Software angegriffen werden kann. Bei der kontinuierlichen Integration hilft auch ein Werkzeug zur automatisierten Codeanalyse wie SonarQube, das den Prozess unterbrechen und sehr zeitnah zurückmelden kann, wenn der Code gegen bestimmte Regeln verstößt. Hinsichtlich der Entwicklung sicherer Software ist es sehr vorteilhaft, dass dabei Regelwerke wie OWASP (Open Web Application Security Project) oder CWE (Common Weakness Enumeration) berücksichtigt werden.

Bereichsübergreifendes Lernen und Kollaboration

Die Sensibilisierung in Sachen Sicherheit sollte über die Entwicklung hinaus alle am Software-Lebenszyklus Beteiligten betreffen. Besonders zielführend sind dabei – wie schon beim DevOps-Modell festgestellt – die bereichsübergreifenden Lektionen: Entwickler, Qualitätsverantwortliche, Produktverantwortliche und Systemadministratoren können viele Praktiken voneinander lernen, die sie in ihrem Bereich nutzbringend einsetzen können. Der Entwickler sollte beispielsweise verstehen, wie eine Produktionsumgebung gegen externe Angriffe geschützt wird und wo deren Schwachstellen sind. Der Systemadministrator wiederum sollte wissen, wo die Schwachstellen im “Innenleben” einer Anwendung liegen, um diese systemseitig, sozusagen “von außen”, noch besser abzusichern.

Integration von Sicherheitsprüfungen in die Continuous Delivery

Wird eine Deployment-Pipeline betrieben, die Codeänderungen der Entwickler den Anwendern in nahezu Echtzeit in einer Ablaufumgebung bereitstellt, so enthält der Prozess in der Regel mehrere Teststufen, die im Fehlerfall dazu führen können, dass der Code verworfen und automatisch eine Meldung an den Entwickler zurückgegeben wird. Entsprechend ist auch mit dem Qualitätsmerkmal Sicherheit zu verfahren. Möglich sind automatisierte Codeanalysen mit, wie oben bereits erwähnt, sicherheitsrelevanten Regelwerken, aber auch automatisierte Penetrationstests auf Anwendungsebene (vor dem Deployment) und auf Systemebene (nach dem Deployment in einer Ablaufumgebung). Auch diese Tests können so konfiguriert werden, dass die Pipeline bei entsprechend schwerwiegenden Sicherheitsverletzungen kein neues Anwendungsrelease bereitstellt, sondern eine entsprechende Meldung ausgibt und idealerweise gleich Hilfestellungen liefert, um die Schwachstellen zu beseitigen.

Das Modell DevOps ist in der Lage, die Time to Production signifikant zu reduzieren: Neue Anforderungen werden im Idealfall sofort umgesetzt und stehen dem Anwender in nahezu Echtzeit zur Verfügung. Hat eine Organisation dieses Modell umgesetzt, kann sie für einen verhältnismäßig geringen Mehraufwand mit DevSecOps einen entscheidenden Zusatznutzen erzielen, um sich vom Wettbewerb zu differenzieren: sichere Systeme, sensible Mitarbeiter in allen Bereichen, eine hohe Frequenz an Sicherheitstests und eine kurze Durchlaufzeit für Verbesserungen.

Welche Erfahrungen haben Sie mit der IT-Sicherheit in Verbindung mit automatisierter Softwarebereitstellung gemacht?

Bildquelle: Shutterstock