„Automatisierte Codeprüfung“
Frank Fischer von Snyk stellt im Interview neue Tools und Strategien für Codeanalyse und Cloud-Sicherheit vor.
Herr Fischer, Sicherheitslücken, Datensilos und Fehlkonfigurationen kosten Unternehmen bares Geld – von der Reputation ganz abgesehen. Wie kann Ihre Lösung helfen? Was kann man sich unter Ihrer Plattform vorstellen?
Aus unseren Studien wissen wir, dass weit über 60 Prozent der befragten Organisationen in den letzten 12 Monaten einen wesentlichen Sicherheitsvorfall hatten. Snyk hat sich auf das Thema Absichern von Cloud Applikationen spezialisiert und bietet führende Werkzeuge. Unsere Plattform ist Developer-First und integriert sich nahtlos in den Software-Entwicklungsprozess. Wir bieten von statischer Code Analyse über Open Source Abhängigkeit, Container und Cloud Konfiguration alles auf einer Plattform.
Security by Design: Wie kann Ihre Sicherheitsplattform Unternehmen bei diesem Konzept effektiv unterstützen?
Wird eine Lösung auf der Cloud entwickelt, ist praktisch alles Software, bis hin zur Definition der Umgebung. Heutzutage verfolgen Teams einen iterativen Ansatz und Experimentieren wird explizit gewünscht. Unsere Werkzeuge ermöglichen es, bereits beim Experimentieren teilweise hochkomplexe Cloud-Designs direkt auf ihre Sicherheit zu überprüfen. Ein weiterer Aspekt ist, dass Security by Design auch den Entwurf und die Automatisierung der Software-Produktionslinie enthalten muss. Snyk stellt hier wesentliche Werkzeuge zur Verfügung.
Inwieweit können sich Ihre Lösungen in diverse Entwicklungsumgebungen integrieren?
Dem Entwickler Zugriff auf direkt umsetzbare Sicherheitshinweise ohne Medienbruch zu geben, ist der entscheidende Schlüssel, dass Sicherheit umgesetzt wird. Wir bieten für eine Vielzahl von Entwicklungsumgebungen eigene Plug-ins an, mit denen unsere Werkzeuge Ergebnisse direkt in die Werkbank des Entwicklers liefern. Neu ist eine Schnittstelle namens Language Server Protocol. Sie ermöglicht die Integration von Entwicklungsumgebungen und Diensten wie unsere in praktisch jeder Umgebung.
Laut Ihrer aktuellen Studie ist die Cloud einerseits ein „kollektives Sicherheitsrisiko“, andererseits aber für die Zusammenarbeit unverzichtbar. Mit welchen Tools können Sie Unternehmen insbesondere in Cloud-Umgebungen unterstützen, damit Fehlkonfigurationen vermieden werden und die Entwicklungsgeschwindigkeit nicht abnimmt?
Fehlkonfiguration ist eine Achillesferse der Cloud und laut einer unserer Studien für etwa die Hälfte aller Vorfälle mit verantwortlich. Für über 40 Prozent der Unternehmen ist die gestiegene Größe und Komplexität von Cloud-Konfigurationen ein Sicherheitsproblem, da Teams entsprechend mit Ausbildung oder Werkzeugen befähigt werden müssen. Unser Tool Snyk IaC (Infrastructure as Code) ermöglicht Teams einen gemeinsamen Blick auf die Sicherheit einer Cloud-Konfiguration und pro-aktives Handeln.
Vereinfacht gesagt, prüft Ihre Plattform den Code und weist auf Sicherheitslücken und Misskonfigurationen hin. Welche Basis liegt dem zugrunde und wie kommen Sie auf Ihre hohe Performance?
Unsere statistische Analyse „Snyk Code“ basiert auf jahrelanger Forschung an der ETH in Zürich und ermöglicht uns, vom enormen Wissen der globalen Open Source Entwicklergemeinschaft zu lernen. Für die sehr aufwändige semantische Code-Analyse haben wir einen super-schnellen Logic-Solver entwickelt und nutzen bis zu 150.000 Open Source Projekte als Trainingsdaten. Unsere Analyse lernt Funktionen von Bibliotheken selbstständig und wird mit dieser Masse an realem Code auf Genauigkeit optimiert.
Sie bieten eine Plattform für die Sicherheit im gesamten Softwareentwicklungslebenszyklus. Vom Code zur Software zum Code: Können Sie uns Ihre Strategie erläutern? Inwieweit begleiten Sie den Softwareentwicklungslebenszyklus?
Traditionell wird Sicherheit als ein Gateway in den Softwarelebenszyklus eingebracht. Dies hat den Nachteil, dass man alle Probleme bis zu diesem Zeitpunkt aufsammelt und dann den Prozess brechen muss. Alle Beteiligten sind unzufrieden und Software geht nicht in Produktion. Daher glauben wir an DevSecOps und wollen Sicherheitsprobleme so früh wie möglich im Lebenszyklus von Software adressieren, am besten gleich beim Entwickler, der den Code schreibt. Statt Sicherheit an einem Punkt im Prozess, wollen wir das Thema in jeden Schritt integrieren. Das gibt die Möglichkeit, mit wenig Aufwand große Verbesserungen im Bereich Sicherheit zu erreichen.
Ein weiterer Aspekt ist, dass Sicherheitstests nicht wirklich Sicherheit verbessern, wenn nicht ein Entwickler am Schluss den Code anfasst. Daher ist es wichtig, Developer First zu denken.
Wie schaffen es Unternehmen, auch in Multi-Cloud-Umgebungen den Vendor Lock-in mit Ihrer Lösung zu umgehen und zuverlässig zu deployen?
Unsere Tools unterstützen neben den großen Anbietern AWS, GCP und Azure auch eigene Cloud Umgebungen mit Kubernetes. Von unserer Seite aus sind Multi-Cloud- oder Hybrid-Cloud-Ansätze direkt realisierbar und wir können das Thema Sicherheit adressieren.
Was sind Best Practices im Umgang mit Software Security und Ihrer Plattform?
Wir sehen, dass der Ansatz, Entwickler frühestmöglich möglich einzubringen, funktioniert. Unser Kunde Citrix hat uns gesagt, dass für die 2.000 Entwickler, die Snyk derzeit nutzen, in den ersten 90 Tagen mit Snyk über 200% mehr Akzeptanz als mit der vorherigen Lösung sehen und dies ihre Risk Exposure um 50% gesenkt hat. Eine wichtige erste Erfahrung ist also, dass man Entwickler mit einbinden muss.
Mehr als 3.500 Entwickler bei Atlassian nutzen Snyk. Über 5,5 Million Open Source Tests wurden durchgeführt und 100% aller Container werden gescannt. Atlassian konnte damit 65% der kritischen Container Probleme innerhalb weniger Monate beheben. Für mich zeigt das deutlich, wie wichtig der Einsatz und die Automatisierung von Sicherheitswerkzeugen ist.
Häufig hören wir, dass die Einführung von Sicherheitswerkzeugen ein enormes Projekt ist, dass Monate oder Jahre dauert. Unser Kunde Visma hat 140 Teams mit unseren Tools ohne Probleme ausgerollt und die Snyk Plattform in über 20.000 Projekte integriert. Nicht nur haben sie ihre hohen und kritischen Sicherheitsrisiken um 65% bzw 39% reduziert, sie zeigen auch deutlich, wie schnell und einfach das heutzutage gehen kann.
Open Source-Bibliotheken erfreuen sich großer Beliebtheit. Aber am Beispiel von Log4j wurde klar, dass auch hier Risiken bestehen. Welche Auswirkungen hatte dieses Beispiel auf Ihre Plattform?
Unser Security Team hat CVE-2021-44228, wie die Registriernummer für den Log4J Vorfall heißt, sehr früh erkannt und verfolgt. Wir wissen aus unserer Datenbank, wie weit verbreitet Log4J als Abhängigkeit ist. Im Moment, als ein Proof of Concept in der Security Community bekannt wurde, haben wir innerhalb von Minuten unsere Datenbank aktualisiert und Kunden gewarnt. Eine amerikanische Großbank gab uns das Feedback, dass sie mit Hilfe von Snyk innerhalb von 26 Minuten eine klare Sicht auf ihren Status und einen Plan hatte. Heutzutage muss man davon ausgehen, dass man nur wenige Minuten Reaktionszeit hat, daher sind solche Werkzeuge extrem wichtig. Wir wissen das und bieten daher unsere Werkzeuge frei zum Ausprobieren und Nutzen an.
Wir haben durch Log4J eine Vervierfachung der Zugriffe auf unsere Tools gesehen. Viele haben die Möglichkeit zum freien Scan genutzt. Seither ist die Anzahl übrigens nicht mehr zurückgegangen, sondern sogar gestiegen. Das macht uns stolz, dass wir einen Beitrag zur Sicherheit des Internets erbringen.
Welche wichtigen Erkenntnisse brachte in diesem Zusammenhang Ihr State of Open Source Security Report zutage?
Nur 46% der Developer verwenden eine Software Composition Analysis (SCA) und 36% eine statische Code-Analyse. Und dies sind die meist verwendeten Werkzeuge. Dabei haben wir einen Anstieg der durchschnittlichen Zeit bis zur Behebung von Open Source Problemen gesehen, von 49 Tagen in 2018 auf 114 in 2021 (kritische Probleme brauchen sogar 118 Tage). Dabei sagen etwa 88% der Befragten, sie sehen ihre Organisation von akzeptabel bis sehr sicher. Wir sehen hier einen enormen Unterschied und es scheint viele wiegen sich in falscher Sicherheit. Nur 49% der Organisationen haben im Schnitt eine Sicherheits-Policy für Open Source. Große Organisationen offensichtlich mehr, aber immer noch nur um die 56%. Dies zeigt wieder, dass Unternehmen die Gefahr aus der Open Source Lieferkette nicht ernst nehmen. Dabei hat gerade Log4J auf das Thema aufmerksam gemacht. 79% aller Projekte, die die Log4J-Schwachstelle hatten, hatten mehr als einmal eine angreifbare Version von Log4J eingebunden. Mehr als 60% der gefundenen Probleme waren in sogenannten transitiven Abhängigkeiten, also Abhängigkeiten von Abhängigkeiten. Aber: Noch heute finden wir in etwa 2% aller Java Projekte, die wir scannen, angreifbare Log4J Versionen. Zusammenfassend kann man sagen, dass hier noch viel Arbeit vor uns liegt.
Unsere Erfahrung ist: Unternehmen die DevSecOps umsetzen, in ihre Teams und Werkzeuge investieren sowie einen hohen Grad an Automatisierung haben, können am schnellsten auf Probleme reagieren. Dabei braucht es kein hohes Budget, aber einen klaren Willen in Richtung der Cloud.
Frank Fischer
Was raten Sie Unternehmen im Sinne „digitaler Resilienz“?
Gerade für kleine und mittelständische Unternehmen bietet die Cloud enorme Möglichkeiten. Man kann Lösungen entwickeln ohne teure und risikoreiche Investitionen. Viele Dienstleistungen wie Zahlungen oder Kommunikation können direkt über vorhandene Dienste eingebunden werden. Und man zahlt nur, was man auch benutzt. Aber man muss die Philosophie der Cloud verstehen und umsetzen: Anstatt eines großen, ausfallsicheren Dinosauriers hat man einen Schwarm von lose gekoppelten Containern, die dynamisch mehr oder weniger werden. Software-Produktion in kleinen iterativen Schritten ermöglicht ein minimieren des Risikos und gleichzeitig stets ein Produkt beim Kunden zu haben. Das bringt Komplexität, die ein gut ausgebildetes und ausgerüstetes Team braucht. Unsere Erfahrung ist daher, Unternehmen die DevSecOps umsetzen, in ihre Teams und Werkzeuge investieren sowie einen hohen Grad an Automatisierung haben, können am schnellsten auf Probleme reagieren. Dabei braucht es kein hohes Budget, aber einen klaren Willen in Richtung der Cloud.
Inwieweit können Ihre Lösungen auch in Low-Code und No-Code-Umgebungen zum Einsatz kommen?
Die bekannteste No-Code Lösung ist wohl Salesforce und sie sind Kunde bei Snyk. Unserer Erfahrung nach, reden wir mehr von Low als von No-Code. Nehmen wir Salesforce als Beispiel, dann sehen wir sehr häufig, dass die reichhaltigen Möglichkeiten der Plattform durch Elemente in einer Programmiersprache namens APEX ergänzt werden. Der Vorteil ist, dass die Plattform schon viel bietet und man nicht das Rad neu erfinden muss. Aber sobald man eigene Elemente integriert, sollte man sich über Sicherheit speziell Gedanken machen. Und ja, wir können APEX scannen.
Weitere Informationen unter:
www.snyk.io
