Rückblick auf Q2 2020 – Bericht zum Stand der Open-Source-Sicherheit, DevSecOps Hub und mehr

Gestern haben wir auf einige der Blogbeiträge zurückgeblickt, die wir im Januar, Februar und März 2020 veröffentlicht haben. Sie erinnern sich: Damals konnten wir noch reisen und uns umarmen, uns unbeschwert in Bars und Büros treffen und ganz ohne Zoom zusammenkommen! In diesem Beitrag schauen wir uns die Artikel an, die im April, Mai und Juni erschienen sind. Wir beginnen mit einem Spickzettel, den alle Entwickler lesen und als Referenz nutzen sollten.

EBENFALLS LESENSWERT: Rückblick auf Q1 2020 – JVM-Ökosystembericht, DevSecOps-Einblicke und mehr

April 2020: Sichere Code-Reviews: 8 Best Practices für Sicherheits-Code-Reviews

In diesem Spickzettel stellen Brian Vermeer und Trisha Gee acht hilfreiche Tipps vor, die Sie beim Überprüfen des Codes anderer berücksichtigen sollten. Diese Tipps sind übrigens auch beim Schreiben von Code sehr nützlich. Wenden Sie die Maßstäbe also auch auf Ihren eigenen Code an, bevor Sie den Pull Request abschicken!

Drei Best Practices aus dem Spickzettel möchte ich besonders hervorheben: Eingaben bereinigen, Open-Source-Abhängigkeiten testen und natürlich den eigenen Quellcode auf bekannte Sicherheitsprobleme prüfen. Eingaben im eigenen Code zu bereinigen ist enorm wichtig. Trotzdem überlassen wir Entwickler das oft anderen oder gehen davon aus, dass niemand böse Absichten hat, weil wir nur den Happy Path zum Laufen bringen wollen. Viele Entwickler müssen ihre Denkweise ändern und davon ausgehen, dass Nutzer versuchen werden, über ihre Eingaben auf jede erdenkliche Weise schädlichen Code einzuschleusen oder unsere Anwendung anzugreifen.

Es ist äußerst wichtig, sowohl die eigene Anwendung als auch Drittanbieter-Abhängigkeiten statisch zu testen. So erkennen Sie, an welchen Stellen bekannte Schwachstellen in vorhandenen Bibliotheken und Frameworks über unsere Anwendung ausgenutzt werden können und wo unser eigener Code Sicherheitslücken verursacht. Mit Tools wie Snyk, das kostenlos verfügbar ist und Ihre Anwendung schnell testet – direkt in Ihrer IDE, in Repositories und an vielen weiteren Stellen –, gibt es wirklich keine Ausrede mehr, darauf zu verzichten.

Mai 2020: Snyk startet den DevSecOps Hub

Im Mai rief Alyssa Miller den DevSecOps Hub ins Leben, eine Sammlung von Artikeln und Wissen, die Alyssa, Patrick Debois und Francois Raynaud zu einigen zentralen Konzepten der DevSecOps-Bewegung zusammengetragen haben. Die Konzepte werden anhand des vertrauten Ansatzes „People, Process, Technology“ vorgestellt. So soll vermieden werden, dass die Diskussion über DevSecOps zu stark von Tools bestimmt wird.

People – Viele Expertinnen und Experten bei Snyk könnten ihre eigene Meinung teilen. Uns war jedoch wichtig, auch zahlreiche Erfahrungen aus der DevSecOps-Community einzubeziehen. Gäste des Podcasts The Secure Developer Podcast erzählen unserem Gründer Guy Podjarny von ihren Erfolgen und Erkenntnissen beim Start oder Ausbau ihres DevSecOps-Ansatzes. Damit Sie diese wertvollen Informationen im DevSecOps Hub finden, haben wir den Bereich Share the journey aufgenommen.

Process – Es ist immer wichtig, Prozesse klar zu definieren, damit alle wissen, was zu tun ist, wann es zu tun ist und wer dafür zuständig ist. Gemeinsame Verantwortung und Verantwortlichkeit sind zentrale Themen, die in diesem Abschnitt behandelt werden.

Technology – In diesem Abschnitt geht es um zentrale Funktionen, die Teil jeder Pipeline sein sollten, und darum, wie Unternehmen bewährte Ansätze an ihre individuellen Strukturen anpassen können. Dazu stellt der Hub bestimmte Technologien genauer vor. Jede dieser Vorstellungen beleuchtet ein konkretes Tool oder eine Technologie, die die DevSecOps-Pipeline unterstützen kann. Außerdem bieten wir eine Liste mit Best Practices für diese Tools, um praktische Hinweise zur Implementierung der Technologien zu geben.

Juni 2020: Der Stand der Open-Source-Sicherheit 2020

Im Juni verfasste Alyssa Miller unseren jährlichen Bericht zum Stand der Open-Source-Sicherheit. Wie immer lieferte er interessante Einblicke in die heutige Verbreitung und Nutzung von Open Source. Die erste Kennzahl im Bericht zeigt, wer für die Sicherheit verantwortlich ist: 85 % der Befragten sind der Meinung, dass Entwickler für die Open-Source-Sicherheit zuständig sind. Das bestätigt Snyks Ansatz, Sicherheitstools in erster Linie für Entwickler zu konzipieren. Diese Kennzahl ist besonders wichtig mit Blick auf 2021: Immer mehr Entwickler schreiben nicht nur Anwendungscode, sondern müssen auch Containerdateien und Infrastrukturkonfigurationen als Code pflegen und warten. All diese Artefakte müssen nicht nur geschrieben und gepflegt, sondern auch sicher gestaltet werden, damit Sie nicht als Nächstes mit einem gehackten, unzureichend gesicherten Amazon-S3-Bucket in den Nachrichten landen. Später im Bericht zeigt sich, dass über 30 % der Umfrageteilnehmer Kubernetes-Manifeste nicht auf unsichere Konfigurationen überprüfen. Entwickler, die Verantwortung für moderne Cloud-Native-Anwendungen übernehmen, müssen die Bedrohungen an all diesen Stellen berücksichtigen und benötigen eine Cloud-Native-Anwendungssicherheitsplattform, die sie dabei unterstützt.

Interessanterweise setzen nur 15 % der Befragten Programme für Security Champions um. In solchen Programmen werden Mitarbeitende in Engineering-Teams zu Security Champions weitergebildet. Ihre Schulung erfolgt in der Regel durch das Sicherheitsteam sowie über weitere interne und externe Schulungsprogramme. Wenn Entwickler ihre Kompetenzen ausbauen, lässt sich viel Sicherheitswissen in die Teams tragen. Das kann zahlreiche Best Practices in der Entwicklung und bei Code-Reviews verbessern und sorgt außerdem dafür, dass Sicherheit auf natürliche Weise einen größeren Stellenwert in der Designphase erhält. Menschen und Unternehmenskultur lassen sich bei Veränderungen wie DevOps oder DevSecOps am schwersten verändern. Deshalb ist es wichtig, das Problem direkt anzugehen. Aus Gesprächen mit vielen Snyk-Kunden und -Nutzern wissen wir: Unternehmen, die Sicherheitsprogramme in Engineering-Teams einführen, erzielen große Erfolge bei der Einführung und Umsetzung von Sicherheitspraktiken. Ziehen Sie das also unbedingt in Betracht!

Auch dieses Mal gab es einige weitere Beiträge, die es nicht ganz in die Liste geschafft haben, aber dennoch eine besondere Erwähnung verdienen. Dazu gehört das Vuln Cost-Plugin, ein wirklich nützliches und kostenloses Sicherheitstest-Tool, das direkt in VS Code integriert ist. Es sorgt für eine hervorragende Developer Experience, indem es Schwachstellen direkt im Code sichtbar macht, sobald wir sie einbinden! Außerdem berichteten wir über die Offenlegung einer Schwachstelle in der beliebten npm-Bibliothek is-promise und veröffentlichten eine Nachbetrachtung dazu, wie es dazu kam und was wir daraus lernen können. Und schließlich haben wir im Mai Snyk in das beliebte WebPageTest integriert! Durch diese Integration werden die hervorragenden Performance-Ergebnisse von WebPageTest um Sicherheitstests ergänzt.

Vielen Dank fürs Lesen! Beim nächsten Mal werfen wir einen Blick auf die Beiträge, die wir im dritten Quartal 2020 veröffentlicht haben.