Anmerkung der Redaktion: Dies ist Teil 2 des vierteiligen Gesprächs mit Bryan Batty, Director of Product and Infrastructure Security bei der Bloomberg Industry Group. In Teil 1 haben wir über die Nutzung von Open-Source-Komponenten gesprochen. Batty erklärte, wie diese mit Software Composition Analysis (SCA) Tools verwaltet werden können. In diesem Teil spricht Bryan über Möglichkeiten, die Sicherheit zu einem integralen Bestandteil der Software Supply Chain zu machen.
"Wenn Sie sonst nichts haben, dann wissen Sie wenigstens, dass Sie Ihre Software versionieren können und dass zwei verschiedene Personen gleichzeitig daran arbeiten können, ohne sich dabei in den Weg zu kommen." -- Bryan Batty
Entwicklung einer sicheren Pipeline
Mark Miller:
Wo setzt man am besten an, wenn man eine DevOps-Pipeline schaffen und Sicherheit in Form von DevSecOps integrieren möchte?
Bryan Batty:
Auf diese Frage gibt es sehr viele verschiedene Antworten. Es kommt auf die Größe des Unternehmens an, und auch darauf, wie ausgereift die Pipeline bereits ist. Wenn es noch keine Pipeline gibt, muss man zunächst eine erstellen.
Mark Miller:
Definieren Sie Pipeline. Worum handelt es sich dabei?
Bryan Batty:
Am besten beginnt man mit dem System für die Versionsverwaltung. Wenn Sie sonst nichts haben, dann wissen Sie wenigstens, dass Sie Ihre Software versionieren können, und dass zwei verschiedene Personen gleichzeitig daran arbeiten können, ohne sich dabei in den Weg zu kommen. Sogar bei modernen Pipelines passiert das manchmal. Bei GitHub z. B., wenn Sie vergessen, vor dem Push-Verfahren ein Pull-Verfahren durchzuführen. Es kommt zu Problemen, wenn Sie Veränderungen anderer Personen mit Ihrem Code zusammenführen wollen.
Beginnen Sie mit einem guten System zur Versionsverwaltung, aber auch mit Continuous Integration. Im Grunde genommen besteht eine gute Delivery Pipeline gleich von Anfang an aus Quality Gates, wenn Sie eine Software entwickeln. Diese Quality Gates sind normalerweise zum Testen da. Den Test führen Sie aus, um sicherzustellen, dass die Software auch das tut, was sie tun soll, und sonst nichts.
Entwickler und Entwicklungsteams beschäftigen sich damit bereits. Ja, sie wollen ihre Software testen, bevor sie sie veröffentlichen. Mit der Sicherheit verhält es sich genauso. Wir wollen, dass sie schon so früh wie möglich in die Pipeline integriert wird.
Die Entwickler sollen so schnell wie möglich Feedback erhalten, ohne dass sie zu viel Zeit verlieren. Einige der sehr schnellen Elemente, wie SCA, nehmen weniger Zeit in Anspruch als statische und dynamische Analysen oder Testverfahren, während die Software in Betrieb ist. SCA kann früh und während der gesamten Pipeline ausgeführt werden.
Statische Analysen können manchmal sehr langsam sein, je nachdem, wie groß die Quellcodebasis ist. Es geht aber darum, Tests so früh und so schnell wie möglich ausführen zu können. Manuelle Penetration-Tests sollten von Zeit zu Zeit durchgeführt werden. Es wird vielleicht nicht bei jedem einzelnen Sprint klappen. Sorgen Sie dafür, dass den Entwicklern ein Spezialist für Anwendungssicherheit zur Seite steht, wenn diese ihre Sprints ausführen, und versuchen Sie, Pen-Tests der Deltas zu machen.
Anstelle von umfassenden Penetration-Tests für die gesamte Anwendung können Sie einfach einzelne Pen-Tests für jene Änderungen durchführen, die während des Sprints vorgenommen wurden. Ich experimentiere selbst gerade damit. Ob das nachhaltig ist, weiß ich noch nicht genau. In jedem Fall ist es aber interessant, zu sehen, wie begeistert die Leute sind, wenn es funktioniert.
Ein vollständiger, umfassender Penetration-Test auf manueller Basis wird wahrscheinlich nur einmal jährlich durchgeführt. Das wird man wahrscheinlich nicht so früh im Pipeline-Entwicklungsprozess tun. Es gibt Dinge, die man vielleicht schon erkennen, beheben und wieder an den Entwickler zurückgeben kann, bevor man sich zwei Wochen lang damit beschäftigt.
Anpassen der Sicherheitsmodelle
Mark Miller:
Verändert sich das Sicherheitsmodell, das Sie anwenden, wenn Entwickler Container anstelle von regulären Pipelines nutzen?
Bryan Batty:
Ich glaube nicht, dass sich das Modell ändert, aber bestimmte Aufgaben ändern sich definitiv. Normalerweise ist der DevSec-Teil gemeint, wenn wir über Anwendungssicherheit sprechen. Container gehören zum Ops-Bereich bei DevSecOps. Ops ist normalerweise nicht relevant, wenn wir nur über Anwendungssicherheitsexperten sprechen.
Was machen die Entwickler? Was ist in der Pipeline? Jetzt aber stellen die Entwickler eine Infrastruktur bereit und sie stellen Container bereit, die über alle zur Ausführung einer Anwendung erforderlichen Ressourcen verfügen. Ein Container ist kein Amazon Machine Image, aber so etwas in der Art. Die Leute holen sich diese Container von verschiedenen Orten. Sie verwenden welche aus dem Internet, also müssen wir sicherstellen, dass diese Container aus dem Internet keine Sicherheitslücken aufweisen.
Software Bill of Materials (SBOM)
Mark Miller:
Die Regierung erwägt unter anderem eine Software Bill of Materials, die vorschriftsgemäß bei jeder verkauften Anwendung enthalten sein soll. Was halten Sie davon? Gut? Nicht gut? Würden Sie als Praxisanwender eine Software Bill of Materials befürworten?
Bryan Batty:
Ich denke, es wäre nett. Ich ärgere mich immer, wenn ich Wind davon bekomme, dass die Regierung unserer Industrie so etwas antun will. Oder irgendeiner Industrie, aber vor allem unserer. Ich denke dabei an Datenschutzverordnungen wie die DSGVO oder CCPA. Grundsätzlich bin ich kein Fan davon, aber in der Praxis ist es etwas anderes. Wir sehen ja, wie die Technikgiganten Datenschutzprobleme ausgenutzt haben. Sie trampeln auf unseren Rechten regelrecht herum.
Da muss sich etwas ändern. Manchmal erwische ich mich also dabei, wie ich mir denke: "Na gut, meine liberale Einstellung sollte ich vielleicht doch manchmal ein bisschen zurückschrauben." In diesem Sinne ist es für mich in Ordnung, wenn eine Software Bill of Materials eingeführt wird. Denn so weiß ich, was ich bekomme, wenn ich eine Software-Lösung kaufe.
Bei uns in der Firma verkaufen wir auch Software. Alle unsere Anbieter und sämtliche Kunden, die unsere Software erwerben, erhalten von uns einen Sicherheitsfragebogen. Ob es eine Software Bill of Materials geben soll oder nicht, wird in diesem Fragebogen nicht erfragt. Vielleicht wäre es eine gute Idee, eine entsprechende Frage hinzuzufügen.
Nun stellt sich noch die Frage, ob das die Regierung oder eher eine Drittpartei wie PCI-Compliance übernehmen sollte. Meiner Meinung nach sollte es so etwas geben. Jemand hat die Autorität, und alle anderen haben dieser Autorität zugestimmt. Diese Instanz ist es dann, die die Software oder Entwicklertools von Dritten überprüft.
Das war Teil 2 unseres Gesprächs mit Bryan Batty. Lesen Sie in Teil 1, wie er die Nutzung von Software Composition Analysis (SCA) Tools beschreibt. In Teil 3 spricht er über Experimente sowie über die Messung von Erfolg. In Teil 4 teilt er uns schließlich mit, wieso seine Wahl auf die Sonatype-Plattform fiel.
