Software-Entwicklung mit Open-Source-Komponenten – aber sicher!

Software-Entwicklung und dessen Deployment haben sich unter dem Druck einer zunehmenden Business-Relevanz und dem Siegeszug von Cloud-Computing dramatisch verändert. Heute werden Automatisierung, Microservices und Container genutzt, um neue Software-Features schneller bereitzustellen. Laut IDC wollen 89 Prozent der deutschen Unternehmen ihre Applikationen durch Cloud-Migration, den Einsatz von Containern, Microservices und Serverless-Architekturen modernisieren.

Das bedeutet aber auch, dass neue Methoden bei der Code-Analyse, dem Testen und insbesondere bei der Sicherheit implementiert werden müssen, denn vielfach bremsen veraltete Security-Praktiken eine zügige Software-Entwicklung aus. "Penetrationstests und Codeanalysen finden häufig erst am Ende des Entwicklungsprozesses statt; dann aber sind sie aufwendig und es ist zeitintensiv und teuer, die entdeckten Schwachstellen zu beheben. Damit ist dieser Teil oft der Flaschenhals des gesamten DevOps-Zyklus", sagt Karsten Kempe, Solution Architect bei Microsoft Deutschland.

Die IDC-Untersuchung bestätigt das: 39 Prozent der befragten IT-Manager gaben an, dass der größte Bottleneck in der App-Delivery-Pipeline die Sicherheit sei. Sie liegt hinter der mangelhaften Datenqualität (41 Prozent) auf dem zweiten Platz.

Bei der Überlegung, wie hier Abhilfe geschaffen werden kann, darf es natürlich keine Kompromisse geben - auch dann nicht, wenn die entwickelten Software-Komponenten im Zuge einer steigenden Agilität immer kleiner und die Update-Zyklen immer kürzer werden.

Wie DevSecOps hilft, die Entwicklung mit Open-Source-Komponenten zu sichern

Die Lösungen für dieses Problem werden unter dem Begriff DevSecOps zusammengefasst, eine Kurzform von Development Security Operation. Diese Methodik steht erst am Anfang ihrer Nutzung. Laut IDC wird derzeit erst bei 35 Prozent der Unternehmen Security in die DevOps-Prozesse integriert. Was aber bedeutet es, wenn im DevOps-Zyklus ein weiterer Zwischenschritt hinzukommt?

Dazu Kempe: "Das Ziel von DevSecOps ist eine Art 'Security by Design', bei dem Security von Anfang an zum festen Bestandteil des gesamten Entwicklungs- und Deployment-Prozesses wird." Der DevOps-Zyklus beginnt zunächst mit der Auswahl geeigneter Open Source-Komponenten, denn praktisch werden heute in jede neue Software eine Vielzahl an Open Source-Komponenten eingebunden. Das bedeutet aber Kontrollverlust. "Open Source-Komponenten sind in der Regel Kettenbausteine, deren Sicherheit kein Entwickler mit einem überschaubaren Aufwand selbst nachprüfen kann", weiß Kempe aus seiner Praxis zu berichten.

Die Lösung ist eine öffentliche Datenbank, die alle bekannten Open-Source-Schwachstellen dokumentiert. Wollen Entwickler also Open Source in ihre Software einbinden, so müssen sie die gewünschten Komponenten anhand dieser Datenbank prüfen - und zwar jeweils sofort, nicht erst am Projektende. So lautet die Vorgabe. "Das ist eigentlich ein simpler Vorgang, der wenig Zeit in Anspruch nimmt. Doch leider haben viele Entwickler immer noch ein zu geringes Bedrohungsbewusstsein", beklagt Kempe die aktuelle Situation.

Zu solchen Prüfungen kommen weitere Programmiervorgaben hinzu, wie die Regel, dass Passwörter und Datenzugangspfade nicht im Klartext gespeichert sein dürfen. Das hört sich zwar einfach an, wird aber immer noch vielfach missachtet. Im vorigen Jahr haben Forscher der North Carolina State University mehr als 100.000 Projekte auf GitHub gefunden, bei denen über eine halbe Million Passwörter, Token, kryptographische Schlüssel und andere vertrauliche Daten in offener Form gespeichert waren. Die Daten gehörten zu vielen großen Unternehmen - auch aus der IT-Industrie.

Eine elegante Lösung für diese Problem bietet Azure Key Vault. In diesem Vault können alle Passwörter und Zugriffspfade abgelegt werden, womit sie sehr gut vor einem unerlaubten Zugriff geschützt sind.

Auch DevSecOps erfordert Zeit und Aufwand

Im Entwicklungszyklus sind an dieser Stelle weitere Test erforderlich, um zu prüfen, ob alle Sicherheitsvorgaben eingehalten wurden. "Die Tests müssen so automatisch wie irgend möglich ablaufen, sonst finden die Entwickler schnell einen Workaround und begründen das mit dem permanenten Termindruck", berichtet Kempe. Sinnvoll ist es daher, in regelmäßigen Abständen die bekannten Maßnahmen hinzuzunehmen wie Penetrationstest, Code-Analyse und das Überprüfen der Dependencies. So erzielt man einen optimalen Kompromiss zwischen Geschwindigkeit und Qualität. Die dabei erkannten Schwachstellen führen zu einer Code-Anpassung - womit sich der DevSecOps-Kreis wieder schließt.

Weitere Ratschläge und Erfahrungen, wie sich Softwarequalität nachhaltig steigern lässt, gibt Kempe in diesem Video:

Auch wenn schon so früh wie möglich alle erdenklichen Sicherheits-Checks und -Maßnahmen durchgeführt werden: Security bedeutet in jedem Fall zusätzliche Zeit und Aufwand. "DevSecOps gibt es nicht zum Nulltarif - das ist klar. Aber es geht schneller und es ist billiger, als bis zum Ende zu warten oder gar eine unsichere Anwendung freizuschalten", warnt Kempe.

Aller Anfang ist schwer - aber das Ziel lohnt sich

Bleibt die Frage: Wie lässt sich der Wechsel vom althergebrachten Security-Flaschenhals zu einem modernen agilen Security-Workflow gestalten? Dazu führt GitHub in seinem Whitepaper "The enterprise architect's guide to DevSecOps" drei Schritte aus:

1. Verwenden Sie eine gemeinsame, sichere Plattform für die Zusammenarbeit

DevSecOps hängt von der Kollaboration ab. Mit einer gemeinsamen Plattform können Entwicklungs-, Operations- und Sicherheitsteams eng zusammenarbeiten und ihre Arbeitsweise standardisieren. Priorisieren Sie Plattformen mit einer Built-in-Security, damit Ihr gesamtes Unternehmen sicher zusammenarbeiten kann.

2. Sichern Sie Ihre Systems Development Lifecycle (SDLC) End-to-End

Eine Analyse aller kürzlich veröffentlichten Anwendungen zeigt, dass bis zu 99 Prozent davon Open Source enthalten. Also sind Open Source-Abhängigkeiten bereits Teil Ihrer Codebasis. Integrieren Sie in Ihre CI/CD-Pipeline die entsprechenden Open Source Sicherheitstools, damit Sicherheitslücken sowohl im offenen als auch im internen Quellcode proaktiv identifiziert werden können.

3. Beobachten Sie die Systemsicherheit auch nach der Produktionsfreigabe

Sicherheit endet nicht, wenn der Code genehmigt ist - und Ihre DevSecOps-Pipeline sollte es auch nicht. Beobachten Sie nach dem Deployment den Code und dessen Nutzung, um gegebenenfalls neue Schwachstellen zu entdecken. Suchen Sie nach Tools, mit denen sich neue Abhängigkeiten verfolgen und aktualisieren lassen, bevor potenzielle Hacker davon profitieren.

IDC weist in seinem Bericht noch darauf hin, dass die Einführung von DevSecOps - genauso wie bei DevOps - ein verändertes Mindset erfordert. "Unterschätzen Sie nicht die Anstrengung und Beharrlichkeit, die für eine Einführung erforderlich sind. Hier ist die Unterstützung sowohl der Mitarbeiter als auch des Top-Managements gefordert. Starten Sie mit kleinen Projekten, in denen es um sichtbare Erfolge für alle Beteiligen geht. Hierbei sollten Sie bereits alle Stakeholder wie Entwicklung, Operations, Security, Business-Nutzer und das Management einbeziehen", lautet deren eindringlicher Ratschlag.