Anmerkung der Redaktion: Dies ist der letzte Teil des vierteiligen Gesprächs mit Bryan Batty, Director of Product and Infrastructure Security bei der Bloomberg Industry Group. In Teil 3 sprach Bryan darüber, wie man Erfolg messen kann. In diesem Teil erläutert er, wieso er sich für Sonatype entschieden hat.
"Wenn Sie einen Notfall haben, bei dem ein Upgrade erforderlich ist, dann sollten zwischen Ihrer Version und der neuesten Version nicht 15 Jahre liegen. Wenn Sie eine neue Anwendung entwickeln oder bestehende Anwendungen aktualisieren, sollten Sie möglichst ganz nahe an der aktuellsten Version dran sein." -- Bryan Batty
Die Auswahl von Sonatype
Mark Miller:
Was hat Sie dazu veranlasst, mit Sonatype zu arbeiten?
Bryan Batty:
Ich habe einen Blick auf die Software Composition Analysis geworfen. Ich wusste, dass wir mit vielen Open-Source-Bibliotheken von Drittanbietern arbeiteten, die wir in unseren Anwendungen nutzten. Wir hatten ein Tool, das zumindest in der Lage war, sie abzuzählen. Ob das der Zweck dieses Tools war, ist eine andere Frage, aber es zählte die Open-Source-Bibliotheken, die wir verwendeten.
In den wenigen Dutzend Anwendungen, die ich überwachte, gab es ungefähr 10.000 Open-Source-Bibliotheksversionen, die genutzt wurden. Das hat mir einen großen Schrecken eingejagt. Immerhin ist das wohl eher 90/10 als 80/20. Mir wurde klar, dass wir die Sache in den Griff bekommen mussten.
Also habe ich mir einige Komponenten manuell angesehen und erkannt, dass es da einige Versionen gab, die schon ca. 15 Jahre alt waren. Das war schlecht. Wenn Sie einen Notfall haben, bei dem ein Upgrade erforderlich ist, dann sollten zwischen Ihrer Version und der neuesten Version nicht 15 Jahre liegen. Wenn Sie eine neue Anwendung entwickeln oder bestehende Anwendungen aktualisieren, sollten Sie möglichst ganz nahe an der aktuellsten Version dran sein.
Wir wären sicher nicht in der Lage gewesen, manuell Aktualisierungen vorzunehmen, die über einen Zeitraum von 15 Jahren durchgeführt hätten werden müssen. Wir hatten nicht einmal einen manuellen Prozess. Als ich anfing, haben die Leute diskutiert, wie wir ein Open-Source-Kommittee einbringen könnten, das sich jede Open-Source-Software manuell ansieht. Dann kam ich und sagte: "Das ist doch verrückt! So werdet ihr jeden Tag 20 Stunden lang arbeiten müssen."
Mark Miller:
-Und das für die nächsten tausend Tage!
Bryan Batty:
… und niemand wird es schaffen, das zu Ende zu führen. Also meinte ich: „Das ist also die Anzahl an Open-Source-Bibliotheken, die wir aktuell nutzen. Gleichzeitig kommen immer neue dazu. Das ist kein manueller Prozess. Das schafft ihr so nicht.“
Ich habe mich dazu entschlossen, mich bei den größeren Playern umzusehen. Dazu gehörte Sonatype, und dann Black Duck.
Die Bedeutung der Open-Source-Governance
Mark Miller:
Es überrascht mich, dass viele Menschen immer noch nicht wissen, wie sehr Open-Source tatsächlich genutzt wird.
In unserer jährlichen Befragung, der DecSecOps-Community-Umfrage, fragen wir: „Verfügen Sie über Richtlinien zur Open-Source-Governance und wenn ja, befolgen Sie diese?“ Seit Jahren haben etwa 57 % der Unternehmen Richtlinien zur Open-Source-Governance, und das ist eine konstante Zahl.
Bryan Batty:
Sie haben solche Richtlinien?
Mark Miller:
Ja. Entweder auf Papier oder automatisiert oder wie auch immer. 57 %. Und es sind vor allem Entwickler, die angeben, dass sie solche Richtlinien haben. Sind sich die Leute einfach nicht bewusst, dass sie Open-Source verwenden? Wir sprechen da über eine Gruppe, die sich zusammensetzt und meint: "Wir sollten diese Open-Source-Lösung, die wir nutzen, einmal genauer unter die Lupe nehmen."
Bryan Batty:
Nun, es war genau diese Gruppe, die mir dann die Genehmigung dazu erteilt hat, die Sonatype-Plattform einzusetzen. Es ist mir gelungen, direkt mit den richtigen Leuten zu sprechen, die an eine Lizenzgenehmigung kommen konnten. Wir hatten nur einen einjährigen Vertrag, den wir dann verlängert haben.
Als ich erwähnt habe, dass wir 10.000 Open-Source-Komponenten nutzen, sind sie allesamt vom Hocker gefallen. Drei Monate später waren es schon 12.000. Also 2.000 mehr, und das nur innerhalb von wenigen Monaten! Das hat ihnen gezeigt, dass unser Bedarf an Nexus Lifecycle sehr groß ist. Glücklicherweise haben wir Techniker, die sich damit eingehend beschäftigen.
Mark Miller:
Jemand hat uns einmal gesagt, dass es 25 Tage dauern würde, 800 Komponenten auf die beschriebene Art und Weise manuell zu überprüfen. Bei der ersten Nutzung von Nexus Lifecycle hat diese Person an einem Freitagnachmittag einen Scan gestartet, sich einen Kaffee zum Mitnehmen zubereitet und war dann drauf und dran, das Büro zu verlassen, weil sie davon ausging, dass dieser Vorgang das ganze Wochenende dauern würde. In der Tat dauerte der Scan aber nur fünf Minuten! Es konnten sofort 600 Komponenten eliminiert werden, die so nicht überprüft werden mussten. Im Endeffekt blieben zur Überprüfung dann nur mehr 200 übrig. Das entsprach einer Reduktion von 75 % und hat mich natürlich sehr gefreut.
Bryan Batty:
Ja, das Proof of Concept hat auch sehr geholfen. Wir waren in der Lage, den Server zu starten, und voilà – schon war es erledigt. Ich habe ein Dutzend Lead Developer eingeladen, einen Blick darauf zu werden. Zunächst kamen nur vier oder fünf von ihnen. Da ich die Präsentation aber absichtlich in einem offenen Bereich abhielt, gingen auch andere Entwickler daran vorbei und wollten gleich wissen, was es damit auf sich hatte.
Es hat sie wirklich interessiert. Ich habe versucht, ihren Zuspruch zu erhalten, aber es handelt sich hier um einen kulturellen Sinneswandel innerhalb der gesamten Branche. Die Menschen fragen, ob DevOps schwierig ist. Nein, DevOps ist nicht schwierig. Ein allgemeiner Sinneswandel ist schwierig. Der DevOps-Teil ist leicht. Es ist wichtig, geduldig zu sein und Zuspruch von verschiedenen Ebenen zu erhalten.
Wenn man Entwickler dafür begeistern kann, aber die Führungsspitze den Mehrwert nicht erkennt, dann ist alles umsonst. Wenn die Führungsspitze schon den Wert darin seht, werde ich es auch den Entwicklern unter die Nase reiben – ob sie es wollen oder nicht. Ich denke, jeder weiß, wie so etwas abläuft. Glücklicherweise konnte ich sowohl das Interesse wichtiger Entwickler als auch leitender Führungskräfte wecken.
Ein großes Dankeschön an Bryan Batty, der seine Sichtweise zu einer Vielzahl von DevSecOps-Themen geschildert hat und uns erklärte, wieso seine Wahl auf die Sonatype-Plattform fiel. Lesen Sie mehr von Bryan in Teil 1, Teil 2 und Teil 3. Wir würden uns auch darüber freuen, wenn Sie uns mitteilen, wie Ihr Unternehmen von Sonatype profitieren würde. Kontaktieren Sie uns.
