DevSecOps – 101

Ich musste über ein Thema nachdenken, das mich Kunden oder Teilnehmer von Konferenzen seit längerer Zeit wiederholt fragen.

Die Frage ist fast immer:

Was sind die “quick wins” oder “low hanging fruits”, wenn Sie sich mehr mit dem Thema Sicherheit in der Softwareentwicklung befassen möchten?

Und genau diese Frage möchte ich jetzt aus meiner Sicht heraus beantworten und beginnen mit einem Ausdruck, der in der Geschäftswelt häufig verwendet wird.

Diesen Artikel gibt es auch als Youtube Video auf meinem Kanal und ist zu finden unter

https://bit.ly/DevSecOps-QuickWins-DE

Make or Buy

Selbst als Softwareentwickler werden Sie diesen Satz häufig bei Besprechungen mit dem Management und Vertrieb des Unternehmens hören.

Der Ausdruck heißt; “Make or Buy”. In der Regel müssen wir uns entscheiden, ob wir etwas selbst erstellen oder Geld ausgeben möchten, um die angeforderte Funktionalität zu erhalten. Wenn man sich für den Kauf entscheidet kann es sein, dass es letztendlich weniger, mehr oder andere Funktionen sein werden die man erhalten wird, so dass evtl sogar wir uns selbst anpassen müssen, um es in unserem Kontext zu verwenden.

Aber als Softwareentwickler müssen wir uns jeden Tag mit der gleichen Frage befassen. Ich spreche von Abhängigkeiten. Sollten wir den Quellcode selbst schreiben oder nur die nächsten Abhängigkeiten hinzufügen? Wer ist für die Beseitigung von Fehlern verantwortlich und wie hoch sind die Gesamtkosten dieser Entscheidung? Aber zuerst werfen wir einen Blick auf die Make-or-Buy-Verhältnisse innerhalb des gesamten Tech-Stacks.

Unterschied zwischen Make / Buy auf den jeweiligen Ebenen.

Wenn wir alle Ebenen eines Cloud-nativen Stacks betrachten, um den Anteil von “make” und “buy” zu vergleichen, werden wir feststellen, dass die Komponente “buy” in allen Ebenen die größere ist.  Aber – first things first.

Der erste Schritt ist die Entwicklung der Anwendung selbst.

Unter der Annahme, dass wir mit Java arbeiten und maven als Dependency Manager verwenden, fügen wir höchstwahrscheinlich indirekt mehr Codezeilen als Abhängigkeit hinzu als die Anzahl der Zeilen, die wir selbst schreiben. Die Abhängigkeiten spielen eine größere Rolle, und Dritte entwickeln sie. Wir müssen vorsichtig sein, und es ist ein guter Ansatz, diese externen Binärdateien auf bekannte Schwachstellen hin zu überprüfen.

Wir sollten das gleiche Verhalten in Bezug auf Compliance und Lizenznutzung haben und auch diese Punkte im Auge behalten. Die nächste Schicht in unserem Beispiel wird das Betriebssystem sein, in unserem Fall Linux. Und wieder fügen wir einige Konfigurationsdateien hinzu und der Rest sind vorhandene Binärdateien. Die beiden nachfolgenden Ebenen, Docker und Kubernetes, führen uns zu derselben Erkenntnis. Das finale Ergebnis ist eine Komposition von Binärdateien, die größtenteils auf unserer Konfiguration basieren. Die Anteile die wir selber erzeugt haben ist eher gering.

Bisher betrachten wir jedoch nicht die Werkzeuge für die Produktionslinie selbst.

Alle Programme und Dienstprogramme, die direkt oder indirekt unter der Haube “DevSecOps” verwendet werden, sind ebenfalls Abhängigkeiten. Die Abhängigkeiten über alle Ebenen sind damit in allen Bereichen bei weitem der größte Anteil. Das Überprüfen dieser Binärdateien auf bekannte Sicherheitslücken hin, ist der erste logische Schritt.

einmalige und wiederkehrende Aufwände – Compliance / Sicherheitslücken

Beim Vergleich des Aufwands beim Scannen auf bekannte Sicherheitslücken und bei der Erkennung von Compliance-Problemen sehen wir einige Unterschiede. Beginnen wir mit den Compliance-Problemen.

Compliance-Probleme:

Der erste Schritt besteht darin, zu definieren, welche Lizenzen in welchem ​​Teil der Produktionslinie zulässig sind. Diese Definition der zulässigen Lizenz umfasst die Abhängigkeiten während der Entwicklungszeit und die Verwendung von Tools und Laufzeitumgebungen. Die Definition der nicht kritischen Lizenztypen sollte von einem spezialisierten Anwalt überprüft werden. Mit dieser Liste als zulässig gekennzeichneten Lizenztypen können wir beginnen, um regelmäßig den gesamten Bestand an Binärdateien zu scannen. Nachdem der Computer einen Verstoß festgestellt hat, müssen wir dieses Element entfernen und es muss durch ein anderes ersetzt werden, das unter einer für diesen Einsatz freigeschalteten Lizenz verfügbar ist.

Sicherheitslücken:

Der initiale Aufwand auf dieser Seite ist im Vergleich zum Arbeitsaufwand, den Compliance-Verstöße verursachen, gering. Es kann sofort mit der Untersuchung der Binaries begonnen werden. Für den Umgang mit gefundenen Schwachstellen ist jedoch ein etwas anderer Workflow erforderlich. Das Erkennen einer Sicherheitsanfälligkeit löst den Workflow aus, der die menschliche Interaktion umfasst. Die Vulnerability muss intern klassifiziert werden, was nachfolgend zu den Entscheidungen über die notwendige Aktion führt.

Compliance-Probleme: Nur einzelne Punkte in Ihrem Full-Stack

Es gibt einen weiteren Unterschied zwischen Compliance-Problemen und Sicherheitslücken. Wenn es ein Compliance-Problem gibt, handelt es sich um einen einzelnen Punkt innerhalb der gesamten Umgebung. Nur dieses einzelne Teil ist ein Defekt und beeinflusst andere Elemente der Umgebung nicht.

Sicherheitslücken: können zu verschiedenen Angriffsmethoden kombiniert werden.

Sicherheitslücken sind in dem Punkt etwas anders. Sie existieren nicht nur an dem Punkt, an dem sie sich befinden sondern darüber hinaus können sie mit anderen vorhandenen Schwachstellen in jeder zusätzlichen Umgebungsebene kombiniert werden. Das bedeutet, Sicherheitslücken können zu verschiedenen Angriffsmethoden kombiniert werden. Jeder mögliche Angriffsvektor muss erkannt und bewertet werden. Eine Reihe kleinerer Schwachstellen in verschiedenen Ebenen der Anwendung kann zu einem äußerst kritischen Risiko kombiniert werden.

Sicherheitslücken: Zeitleiste von “gefunden” bis “aktiv in der Produktion”

Als nächsten Punkt sehen wir uns an, wie der zeitliche Verlauf von dem Ereignis “Sicherheitslücke wurde gefunden” ist, bis hin zu dem Punkt an dem die Behebung in Produktion verfügbar ist. Nachdem eine Sicherheitslücke in einer Binärdatei vorhanden ist, haben wir fast keine Kontrolle über die Zeit, bis diese gefunden wird. Zudem hängt es von der Person selbst ab, ob die Sicherheitsanfälligkeit dem Erzeuger der Binärdatei gemeldet wird, ein kommerzieller Sicherheitsdienst informiert wird, eine Regierung Interesse daran zeigt oder auf einem Darknet-Marktplatz verkauft wird. Unter der Annahme, dass die Informationen an den ursprünglichen Ersteller der Datei selbst gemeldet werden, dauert es einige Zeit, bis die Daten öffentlich verfügbar sind. Wir haben keine Kontrolle über die Dauer vom Auffinden der Sicherheitsanfälligkeit bis zum Zeitpunkt, zu dem die Informationen öffentlich verfügbar sind. Der nächste Zeitabschnitt basiert auf dem kommerziellen Aspekt dieser Sicherheitslücke.

Als Verbraucher können wir die Informationen nur so schnell wie möglich erhalten, wenn wir Geld ausgeben.

Dieser Zustand ist nicht schön, aber meistens die Wahrheit.

Trotzdem sind die Informationen irgendwann für uns konsumierbar.

Wenn Sie JFrog Xray verwenden, beispielsweise von dem Free-Tier, erhalten Sie die Informationen sehr schnell. JFrog verwendet verschiedene (kommerzielle und freie) Informationsquellen und führt alle Informationen in einer einzigen Schwachstellen-Datenbank zusammen. Nachdem diese Datenbank mit neuen Inhalten versorgt wurde, werden alle JFrog Xray-Instanzen aktualisiert.

Nachdem dieser Zeitpunkt erreicht ist, können Sie handeln.

Test Coverage ist Ihr Sicherheitsgurt. Versuchen Sie es mit MutationTesting.

Bis jetzt können Sie den Informationsfluss nur beschleunigen, indem Sie Geld für einen professionellen Aggregator von Sicherheitsinformationen ausgeben. Sobald die Informationen für Sie konsumierbar sind, läuft allerdings der Timer. Es hängt ausschließlich von Ihrer Umgebung ab, wie schnell diese Sicherheitsupdates in der Produktion ausgeführt werden. Um die Zeit zu minimieren, ist eine vollautomatische CI-Pipeline einer der kritischen Faktoren. Noch kritischer ist jedoch eine hervorragende und robuste Testabdeckung. Durch eine gute Testabdeckung können Sie die Versionen der Dependencies sofort wechseln und diese Änderung nach einem grünen Testlauf in die Produktion übertragen. Ich empfehle die Verwendung einer “härteren” Testabdeckung als reine LineCoverage. Die als “MutationTest-Coverage” bezeichnete Technik ist sehr leistungsstark und einfach umzusetzen.

Sehen Sie in meinem YouTube-Kanal vorbei. Ich habe dort ein Video,

das Mutation-Testing für Java und Kotlin erklärt.

Die Notwendigkeit eines einzigen logischen Punktes, der alle Repo-Typen versteht

Um ein Bild des vollständigen Wirkungsdiagramms zu erhalten, das auf allen bekannten Schwachstellen basiert, ist es wichtig, alle Paketmanager zu verstehen, die in den Abhängigkeiten eingesetzt werden. Es reicht bei weitem nicht aus, sich nur auf eine Ebene im Tech-Stack zu konzentrieren. Repositorymanager wie zum Beispiel JFrog Artifactory enthalten Informationen, einschließlich der herstellerspezifischen Metadaten, die Teil der Paketmanager sind. Werkzeuge wie JFrog Xray können dann dieses Wissen nutzen und alle Binärdateien scannen, die in den von JFrog Artifactory verwalteten Repositories gehostet werden.

Sicherheitslücken – IDE-Plugin

“Shift Left” bedeutet, dass Sicherheitslücken so früh wie möglich innerhalb der Produktionspipeline beseitigt werden sollten. Ein recht frühes Stadium nach der Konzeptphase ist die Codierung selbst. Im dem Moment indem Sie ihrem Projekt Abhängigkeiten hinzufügen, fügen Sie womöglich auch Sicherheitslücken hinzu. Einer der schnellsten Wege, um Feedback zu den von Ihnen eingesetzten Abhängigkeiten zu erhalten, ist das JFrog IDE Plugin. Dieses Plugin verbindet Ihre IDE mit Ihrer JFrog Xray-Instanz. Mit der kostenlos verwendbaren JFrog Platform (jfrog.com/start-free) erhalten Sie Zugriff auf das Scannen nach Sicherheitslücken.

Das Plugin ist OpenSource und verfügbar für IntelliJ, VS-Code, Eclipse, …

Wie benutze ich das IDE Plugin?

Wenn Sie Ihrem Projekt eine Abhängigkeit hinzufügen, kann das IDE-Plugin diese Informationen basierend auf dem verwendeten Paketmanager verstehen. Das IDE-Plugin ist mit Ihrer JFrog Xray-Instanz verbunden und analysiert das Projekt wenn sich die Dependencies Ihres Projekts verändert. Die von JFrog Xray bereitgestellten Informationen enthalten die bekannten Schwachstellen der hinzugefügten Abhängigkeit.

Sollte es eine Version dieser Abhängigkeit geben, die schon über einen Securityfix verfügt, so wird diese Versionsnummer ebenfalls angezeigt.

Fazit

Mit dem JFrog Free Tier haben Sie die Werkzeuge in der Hand um “Shif Left” bis in die IDE hinein durchzuführen.

Erstellen Sie Repositories für alle enthaltenen Technologien, verwenden Sie JFrog Artifactory als Proxy für Ihre Binärdateien und lassen Sie JFrog Xray alle Binaries scannen. Damit haben Sie ein vollständiges Wirkungsdiagramm, das auf den von Ihnen eingesetzten Technologien basiert. 

Wenn Sie mehr zu dem Thema DevSecOps oder Java und Kotlin erfahren möchten, werfen Sie doch einen Blick auf meinen Youtube Kanal. youtube.com/svenruppert. Ich würde mich freuen Sie als meinen neuen Abonnenten begrüßen zu dürfen.

Cheers

Sven Ruppert