Sichere Anwendungsentwicklung Security – ein Bremsklotz für DevOps?

DevOps verspricht Kostenreduktion, Geschwindigkeit und Agilität, Sicherheit gilt da eher als Hindernis. Mit DevSecOps rückt Security im Software Development Lifecycle aber buchstäblich mehr in den Mittelpunkt.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Windhoff Group

Windhoff Group

Security hat für Entwicklungsteams traditionell eine eher niedrigere Priorität. Angesichts der gravierenden Zunahme an Sicherheitslücken ist dies jedoch zu einer unhaltbaren Situation geworden. Die „2017 DevSecOps Community Survey“ von Sonatype beleuchtet, wie sich die Entwickler diesem Problem stellen.

Mit der Umfrage fühlte Sonatype mehr als 2.200 IT-Profis den Puls, um deren Perspektiven hinsichtlich der Entwicklungs-und Sicherheitsprozesse in ihren Unternehmen und Organisationen einzuschätzen. Die Ergebnisse offenbaren eine größere Bereitschaft zur Security-Implementierung während des gesamten Software Development Lifecycle (SDLC). Traditionelle Wasserfall-Entwicklungsmethoden, bei denen die Sicherheit erst spät im Software-Liefer-Lebenszyklus eingebaut wird, werden durch ausgereiftere DevOps-Praktiken und Automatisierung früh und überall ersetzt.

In der Vergangenheit, als Entwickler die Bedeutung sicherer Programmierungspraktiken erkannten, erzeugte Software-Sicherheit oftmals einen negativen Beigeschmack; war diese doch oft mit Nacharbeit verbunden, die von Sicherheitsteams erst spät im Entwicklungszyklus angeordnet oder von Operations-Teams gefordert wurde, die sich mit dringenden Sanierungsanforderungen an die Entwickler wandten.

Sicherheitsprotokolle und Checkpoints behinderten deren Fähigkeit, Innovationen und damit auch die Anwendungen schneller zu liefern. Dieser Ansatz führt eindeutig zu erhöhten Risiken für die Produkte und die Unternehmen, die diese Produkte einsetzen.

Zusammenarbeit

Eines der grundlegenden Prinzipien in Bezug auf DevOps ist eine bessere und schnellere Entwicklung durch Zusammenarbeit, indem ein Unternehmen unterschiedliche, funktionsübergreifende Teams zusammenbringt. Die Idee dahinter war, dass dies zu einer größeren Agilität durch kontinuierliche Software-Entwicklung und einer schnelleren Lösung von Problemen führen würde. Eine rechtzeitige Zusammenarbeit zwischen DevOps, Sicherheits-, Audit- und Compliance-Teams findet jedoch nicht immer statt.

Unternehmen mit weniger ausgereiften DevOps-Praktiken neigen zu einem eher reaktiven Ansatz, was die DevOps-Sicherheit anbelangt. Sie arbeiten mit den Sicherheitsteams nur bei Prüfungsaufträgen oder bei auftretenden Sicherheitsverletzungen zusammen. Unsere Umfrage ergab, dass 47 Prozent der Befragten, die in Umgebungen mit wenig ausgereiften oder fehlenden DevOps-Prozessen arbeiten, den Eindruck haben, dass Security ihre Prozesse verlangsamt. Allerdings ist dieses Empfinden in Organisationen mit ausgereiften DevOps-Prozessen weit weniger ausgeprägt: in dieser Kategorie schrumpft die Anzahl auf 28 Prozent der Befragten.

Alle Teams, die am SDLC beteiligt sind, haben entscheidende Ziele: Entwickler wollen Anwendungen möglichst optimal herstellen, Operations-Profis möchten, dass die Anwendung hochverfügbar und stabil ist und Sicherheitsexperten wollen Schwachstellen und Risiken für das Unternehmen ausschalten. Unternehmen mit ausgereifteren Praktiken fördern die Zusammenarbeit zwischen diesen Teams und ermöglichen es ihnen, Software sorgfältig, kontinuierlich und schnell zu beurteilen und freizugeben.

Automatisierung

Organisationen mit ausgereiften DevOps-Praktiken erleben eine Applikationssicherheit, die die Entwicklungs- und Betriebsprozesse nicht verlangsamt, sondern diese unterstützt und ergänzt, indem sie sicherstellt, dass die Entwicklung jederzeit sicher und zuverlässig ist. Unsere Umfrage offenbarte durchweg, dass automatisierte Sicherheitspraktiken während des gesamten SDLC an Traktion gewinnen. 58 Prozent der Befragten, die ausgereiften DevOps-Praktiken anwenden, gaben an, bereits automatisierte Sicherheitstests eingeführt zu haben.

Traditionelle Entwicklungs-, Test- und Sicherheitspraktiken können Stunden bis Tage dauern, um Feedback zu liefern und sind nicht in der Lage, mit der Geschwindigkeit von DevOps-nativen Entwicklungsprozessen Schritt zu halten. Da DevOps immer ausgereifter wird, wird die Zahl der Unternehmen und Organisationen, die sich die grundlegenden Vorteile der Automatisierung zunutze machen, zweifellos weiter wachsen.

Open-Source-Risiken

Open-Source-Komponenten bilden 80 Prozent einer typischen Anwendung und der „State of the Software Supply Chain Report“ von Sonatype offenbart, dass eine von 15 Open-Source-Software-Komponenten, die zur Assemblierung moderner Anwendungen verwendet werden, mindestens eine bekannte Sicherheitslücke enthält. Diese Komponenten mögen vielleicht ein wahrer Segen für die Produktivität sein, aber es ist wichtig für Entwickler, sich einen guten Einblick in deren Qualität zu verschaffen oder andernfalls das Risiko einzugehen, unerwünschte Schwachstellen in ihre Software-Lieferketten einzuschleusen.

Unsere Umfrageergebnisse deuten darauf hin, dass Governance- und Sicherheitspraktiken rund um Open-Source-Komponenten für viele Organisationen immer noch ein gutes Stück Arbeit sind. Trotz der zunehmenden Nutzung von Open-Source-Softwarekomponenten in den vergangenen Jahren liegt der Anteil der Befragten, die angaben, ihre Organisation habe eine Open-Source-Governance-Richtlinie, seit der vorangegangenen Sonatype-Umfrage von 2014 unverändert bei 57 Prozent.

Eine wachsende Zahl von Unternehmen hat Kontrollen implementiert, über die Open-Source- und Drittanbieter-Tools verwendet werden. Jedoch wäre eine größere Annahme der automatisierten Analyse von Code erforderlich, um regelmäßige Kontrollen von Open-Source-Komponenten und benutzerdefiniertem Code zu gewährleisten.

Container-Sicherheit

Für Linux-Container gilt dasselbe. Die Verwendung von frei verfügbaren Containern in der Entwicklung ist quasi explodiert und es gibt mehr als 100.000 kostenlose Anwendungen auf Docker Hub. Leider können viele Organisationen diese Anwendungen nicht ordnungsgemäß überprüfen, bevor sie sie in ihre DevOps-Toolchains und -Infrastrukturen einbinden und so möglicherweise Schwachstellen in ihre Software-Lieferketten einschleppen.

Tatsächlich sorgen Container bei den DevSecOps-Teams für die ein oder andere schlaflose Nacht. In unserer Umfrage konnten wir feststellen, dass eine große Mehrheit der Befragten - mehr als 88 Prozent - entweder „absolut“ oder „in gewisser Weise“ der Meinung war, dass die Container-Sicherheit zu den wichtigsten Anliegen zählt. Einige dieser Teams haben Schritte unternommen, um diese Sorgen etwas abzufedern. 53 Prozent der Befragten erklärten, dass sie „Sicherheitsprodukte nutzen, um gefährdete Anwendungen, Betriebssysteme und Konfigurationen in Containern zu identifizieren“.

Verhinderung von Sicherheitslücken

Schließlich bestätigte unsere Umfrage, was jeder Software-Entwickler, Security-Manager und Versuchsprofi bereits sicher weiß: Sicherheitslücken sind auf dem Vormarsch. Viele davon beruhen auf Schwachstellen innerhalb der Software. Ein Fünftel der Befragten der Umfrage gab an, ihre Organisation habe eine Sicherheitslücke innerhalb der letzten 12 Monate gehabt, die einer Schwachstelle in einer Open-Source-Komponente oder -Abhängigkeit zugeschrieben werden kann. Das ist ein deutlicher Anstieg gegenüber den 14 Prozent im Jahr 2014. Die gleiche Anteil der Befragten hatte oder vermutet eine Sicherheitslücke innerhalb einer Webanwendung im zurückliegenden Zeitraum eines Jahres.

Während diese Erkenntnisse mit einem Anstieg der Nutzung von Open-Source-Komponenten einhergehen, sind sie auch ein Anzeichen für eine erhöhte Zahl von Angriffen. Hacker haben sich sehr bemüht, bekannte Schwachstellen in Open-Source-Komponenten (z. B. OpenSSL, Struts2, Commons Collection) zu verwenden, um diese Angriffe auszuführen.

Die Lösung zur Bekämpfung dieser Bedrohungen ist die Umsetzung einer Open-Source-Governance-Praxis innerhalb des DevOps-Entwicklungszyklus, also die Einführung eines Prozesses, der es Entwicklern, Versuchsfachleuten und Security-Managern ermöglicht, den Fluss von Open-Source-Komponenten in jeder Phase der Software Supply Chain automatisch zu verwalten. Dieser Prozess kann dazu verwendet werden, gute Komponenten von schlechten zu trennen und Letztere insgesamt aus der Software Supply Chain auszuschließen. Er kann dazu beitragen, die Qualität der produzierten Anwendungen zu verbessern, die angreifbaren Sicherheitslöcher zu reduzieren und die Verwendung von Komponenten mit riskanten Lizenztypen zu eliminieren.

Vom Bremsklotz zum Wegbereiter

Ursprünglich gab es immer einen Kompromiss, bei dem die Organisationen bestenfalls zwei der drei Ziele hinsichtlich Kosten, Geschwindigkeit und Agilität erreichen konnten. Zum Beispiel konnten sie Geschwindigkeit und Qualität haben, aber nur zu sehr hohen Kosten.

Inzwischen reicht das nicht mehr. Wie unsere Umfrage gezeigt hat, schöpfen Organisationen mit ausgereiften DevOps-Praktiken alle drei Vorteile aus, und diejenigen, die auf dem Weg sind, ihren DevOps-Betrieb auszubauen, werden sich bald anschließen. Dies ist das Ergebnis einer von Beginn an nahtlosen Integration von Anwendungssicherheits-Tools in DevOps-Prozesse, um sicherzustellen, dass Sicherheit früh und überall beginnt – von der Auswahl und Sicherheitsüberprüfung von Open-Source-Komponenten bis hin zur Wartung und Verwaltung von Containern und weiter, bis eine Anwendung vollständig implementiert ist.

Sicherheit muss nicht mehr als Hemmschuh für DevOps gesehen werden. Stattdessen ist sie ein Wegbereiter für eine höhere Qualität und eine beschleunigte Software-Entwicklung.

* Derek Weeks ist Vizepräsident bei Sonatype, einem Anbieter von DevOps-nativen Tools, um moderne Software Supply Chains zu automatisieren.

(ID:44768570)