Interview mit Derek Weeks von Sonatype „Bis aufs Schreiben von Code kann alles automatisiert werden“

Sicherheit und agile Entwicklung in DevOps-Umgebungen scheinen auf den ersten Blick nicht zusammenzupassen. Genau hier soll DevSecOps ansetzen. Dev-Insider hat sich mit Derek Weeks, Vice President Sonatype, über die vermeintlichen Widersprüche unterhalten.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

FIS Informationssysteme und Consulting GmbH

Dev-Insider: Herr Weeks, schon vor Jahren haben sich IT-Spezialisten für mehr Sicherheit in der Software-Entwicklung ausgesprochen. Ist diese Forderung mittlerweile in den Köpfen der Entwickler angekommen?

Derek Weeks: Natürlich ist sie das, denn eigentlich möchte niemand mangelhaften Code absichtlich verbauen. Es bedarf jedoch nicht nur des richtigen Mindsets, um Code zu generieren, der sicher ist. Das haben wir auch in unserer DevSecOps-Umfrage von 2017 gesehen. Darin konnten wir ermitteln, dass Entwicklungsteams sowie QA- und Tech-Teams innerhalb eines Zeitraumes von drei Jahren immer mehr automatisierte Sicherheit, in ihre Entwicklungs- und Testverfahren einbauen.

Wir konnten feststellen, dass sich von 2014 bis 2017 der Anteil der von uns untersuchten Unternehmen, die automatisierte Sicherheitsverfahren einsetzen, von 20 Prozent auf 43 Prozent erhöht hat. Im selben Zeitraum stieg der Anteil der befragten QA- und Test-Organisationen, die automatisierte Sicherheitstests integrieren von 21 Prozent auf 60 Prozent.

Es liegt also nahe, dass sich die Lücke zwischen dem Wissen, dass die Sicherheit in Software eingebaut werden muss und der Praxis, Sicherheit in Software-Entwicklung einzubauen, dadurch zu schließen beginnt, dass es besseren Zugang zu automatisierten Informationen gibt, die bessere Entscheidungen möglich machen.

Dev-Insider: Was glauben Sie, welchen Stellenwert hat die Sicherheit aktuell in der Software-Entwicklung auf Seiten der Anbieter und der Kunden?

Weeks: Nun, erst kürzlich sahen wir bei Equifax die Sicherheitslücke in einer Web-Applikation, wodurch Personendaten von 143 Millionen Menschen betroffen waren. Sicherheit ist also sowohl für die Anbieter von Software als auch für deren Kunden von entscheidender Bedeutung.

Im Juli dieses Jahres berichteten wir in unserem „2017 State of the Software Supply Chain Report“ über eine Gruppe von Sicherheitsexperten, die in Herzschrittmachern über 8.000 bekannte Sicherheitslücken gefunden hatten. Wenn personenbezogene Daten gestohlen werden, ist das höchst unangenehm. Aber wenn es unmittelbar um die Gesundheit, das Leben und den Tod der Patienten geht, also wo Bits und Bytes auf Fleisch und Blut der Verbraucher treffen, erhöht sich die Bedeutung des Ganzen geradezu dramatisch. Wir können keine Software mit bekannten Sicherheitslücken entwickeln, wenn Menschenleben auf dem Spiel stehen.

Sonatype-Studie zur Applikationssicherheit

DevSecOps-Automatisierung hilft Development-Teams

Dev-Insider: Wenn wir also auf die zunehmende Einführung und Umsetzung von DevOps-Verfahren blicken, wie denken Sie haben sich Sicherheitskonzepte und der Stellenwert der Sicherheit innerhalb des Software-Entwicklungszyklus geändert?

Weeks: Innerhalb der vergangenen drei Jahre gab es eine massive Veränderung dahingehend, wie Sicherheits- und DevOps-Verfahren den Entwicklungszyklus verändern. Also, wenn ich beispielsweise die Heartbleed-Sicherheitslücke betrachte, die vor über drei Jahren publik gemacht wurde, glich die Reaktion auf die Bekanntgabe dieser Schwachstelle einer Schnitzeljagd. Unternehmen wussten nicht, ob sie diese besonders anfällige Komponente in ihrer Infrastruktur einsetzten. Und bei einigen mir bekannten Unternehmen dauerte es sechs bis acht Wochen, um herauszufinden, ob sie diese gefährdete Komponente benutzten, bevor sie überhaupt anfingen, dieses spezielle Sicherheitsloch in ihrer Umgebung zu stopfen.

Erst kürzlich wurde wieder eine kritische Sicherheitslücke in Struts2 bekannt. Dabei konnte Unternehmen wie Apple beobachten, deren Online-Entwickler-Plattform vermutlich von der Struts2-Schwachstelle betroffen war. Es dauerte allerdings nur ein paar Stunden, bis man diese spezielle Sicherheitslücke in der Entwicklungsumgebung behoben hatte.

Ich habe einen Freund, der bei einer der größten Banken in den USA arbeitet und auf meine Frage „Hey, wisst ihr über diese neue Struts-Sicherheitslücke, die bekannt wurde, Bescheid?“ sagte er, „Ja, wir sind uns dessen bewusst. Wir haben sichergestellt, dass keiner unserer Systeme in unserem Hauptsitz diese Sicherheitslücke aufwies. Und wir haben auch alle unseren großen Filialen überprüft, um uns zu vergewissern, dass keine von dieser anfälligen Open-Source-Komponente betroffen ist.“

Dies geschah nur wenige Stunden nach Bekanntwerden. Also von der Zeit, in der wir sechs bis acht Wochen brauchten, nur um festzustellen, ob eine anfällige Open-Source-Komponente in der Infrastruktur existiert, bis zu der Zeit, in der Unternehmen binnen Minuten oder Stunden reagieren, gab es aus meiner Sicht eine gewaltige Veränderung. Allerdings hat sich dieser Wandel noch nicht über die gesamte Branche verbreitet. Führende Unternehmen haben jedoch den Übergang von Wochen zu Minuten gemeistert.

Dev-Insider: Welchen Stellenwert sollte Sicherheit Ihrer Meinung nach genießen?

Weeks: Sicherheit ist kein zeitlich begrenztes Anliegen. Sie muss persistent sein. Und wir müssen die Sicherheit ständig mit einem wachsamen Auge betrachten. Unternehmen müssen den Wandel von einem reaktiven „Oh mein Gott, da ist eine Sicherheitslücke. Wir müssen sehen, ob wir betroffen sind,“ oder „Wir haben ein Sicherheitsproblem und müssen reagieren, um unsere Systeme zu reparieren,“ zu einem proaktiven Verhalten schaffen, in dem sie Sicherheit in ihre Software und Infrastruktur einbauen. Und zwar nicht nur so früh wie möglich im Entwicklungszyklus, sondern konsequent und ohne Unterbrechung innerhalb der gesamten Entwicklungs- sowie Produktions-Software-Umgebung.

Dev-Insider: Ist es einfacher für ein Unternehmen, bei der Automatisierung von Sicherheitsverfahren quasi bei Null anzufangen? Was würden Sie einem alteingesessenen Unternehmen mit einem klassischen Software-Entwicklungszyklus empfehlen, das sich bezüglich des Wandels unsicher ist?

Weeks: Diejenigen, die sich nicht schneller bewegen und innovativer werden, werden von denen, die sich schneller bewegen und die innovativer sind, überholt. Ich denke, am ehesten sollte man auf Technologie-Teams setzen, die kontinuierlich innovieren.

Sichere Anwendungsentwicklung

Security – ein Bremsklotz für DevOps?

Dev-Insider: Welche Schritte und Prozesse in der Software-Entwicklung lassen sich automatisieren - und in welchen Fällen ist das auch tatsächlich sinnvoll? Und woran lässt sich der Wert dessen so früh wie möglich erkennen?

Weeks: Ich denke, das ist eine sehr gute Frage. Wenn es um die Automatisierung geht, meine ich, dass mit Ausnahme des Schreibens von Code alles automatisiert werden kann. Sehen Sie, Builds, Integration, Unit-Tests, Performance-Tests, Sicherheitstests, Konfigurationen, Bereitstellungen, Rollbacks, all dies wird bereits automatisiert. Wenn es um die Automatisierung geht, glauben viele Leute intuitiv, Automatisierung mache die Dinge einfach schneller. Aber in Wirklichkeit macht sie vieles auch konsistenter und messbarer.

Also, wenn wir die Verfahren automatisieren, die wir in unserer Umgebung haben, können wir auch anfangen, sie zu messen. Es gibt ein altes Sprichwort, dass einer meiner College-Professoren benutzt hat: „Keeping score improves the score", was in etwa so viel bedeutet, das wenn man die Ergebnisse aufzeichnet, sich diese verbessern. In Bezug auf Ihre messbare Leistung oder Automatisierung, die gemessen werden kann, bedeutet dies, wenn Sie die die Ergebnisse aufzeichnen und wissen, wie gut Sie sind, können Sie Mittel und Wege finden, wie sie diese Ergebnisse sogar noch verbessern können.

Dev-Insider: Gilt das auch für Software-Anbieter jeder Größe? Welche Möglichkeiten haben kleinere Software-Schmieden?

Weeks: Wenn es um die Automatisierung innerhalb von DevOps-Verfahren geht, spielt die Größe eine wichtige Rolle. Sie ist wichtig in kleineren Unternehmen, die gerade dabei sind zu wachsen, in Start-ups oder Organisationen, in denen nur ein paar Leute an Ihren End-to-End-Business-Verfahren beteiligt sind. Es ist manchmal viel einfacher, diese neueren, schnelleren, eher automatisierten, konsistenteren Prozesse innerhalb nur einer Umgebung umzusetzen.

In größeren Unternehmen können diese Änderungen in kleinen Geschäftseinheiten erreicht werden. Aber sobald Sie anfangen, diese Verfahren über die gesamte Wertschöpfungskette zu erweitern, wird es manchmal schwierig für größere Unternehmen, diese Änderungen umzusetzen, weil sie Prozesse betreffen, die schon lange Zeit bestehen. Sie betreffen die Kultur oder eine Gruppe von Menschen, die es gewohnt ist, Dinge auf eine bestimmte Art und Weise zu tun, die bestimmte Methoden in ihre Organisationen übernommen haben.

Die Denkweise vieler Leute ist, dass es einfacher sei, so weiterzumachen wie bisher, als Veränderungen zu bewältigen. Also ist der Wandel für größere Unternehmen zwar erforderlich aber schwer, und ich glaube, das darf man nicht unterschätzen.

Aber wie gesagt, am ehesten sollte man auf Tech-Teams setzen, die kontinuierlich innovieren und die beständig dazulernen. Diejenigen, die überholt werden, werden von denen überholt, die gelernt haben, zu innovieren und zu automatisieren und deren Unternehmen sich schneller bewegen, um Mehrwerte für ihre Kunden schneller zu liefern.

* Derek Weeks ist Vice President bei Sonatype.

(ID:44892968)