The Secure Developer: Rückblick auf 2021

Wenn die vergangenen Jahre eine Übung in Anpassungsfähigkeit waren, gab uns 2021 Zeit, unsere Leistungen zu reflektieren. Der Pandemieschock, der 2020 dominierte, wich einer geerdeteren Perspektive auf die Herausforderungen, die wir in unserem Privat- und Berufsleben gemeistert haben.

Als Moderator von The Secure Developer gab Guy Podjarny (Gründer und Präsident von Snyk) uns einen Einblick in die Entwicklung der Anwendungssicherheit. In den 22 Folgen dieses Jahres teilten 23 Gäste aus unterschiedlichen Branchen ihre einzigartigen Erkenntnisse. In der Jahresabschlussfolge sprach Guy mit Simon Maple, Field CTO bei Snyk, über die Themen, Ratschläge und Zukunftserwartungen, die in den diesjährigen Folgen zur Sprache kamen.

Gemeinsame Branchenthemen

Im Laufe des Jahres brachten die Gäste von The Secure Developer unzählige interessante Punkte zur Sprache. Bei ihrem Rückblick stellten Guy und Simon drei spannende Themen fest, die sich durch die meisten Podcast-Folgen zogen.

Entwickler für Sicherheitsteams gewinnen

Das erste Thema war der Trend, beim Aufbau eines Sicherheitsteams Entwickler (oder Personen mit Erfahrung im Software-Engineering) einzustellen. Traditionell bestanden Sicherheitsteams aus spezialisierten Sicherheitsexperten, die trotz ihres umfassenden Wissens von der täglichen Entwicklungsarbeit getrennt waren. Sicherheit war ein zusätzlicher Kontrollpunkt für Entwickler und kein integrierter Bestandteil ihrer Arbeit.

Entwickler in das Sicherheitsteam einzubinden, bringt einen großen Vorteil. Daniel Bryant (Director of DevRel bei Ambassador Labs) erklärte: „Entwickler übernehmen zunehmend Verantwortung von Anfang bis Ende. Sie erwähnten Tests und Observability. Und Entwickler arbeiten gern auf bestimmte Weise mit Tools. Sie müssen [...] dort abgeholt werden, wo die Engineers stehen.“ (Folge 90)

Sicherheitsteams Empathie nahezubringen und ihnen die Perspektive der Entwickler sowie deren Herausforderungen zu vermitteln, ist das eine. Wenn Sie von Anfang an einen Entwickler einstellen, ist diese Perspektive bereits vorhanden. Schulungen oder Übersetzungen sind nicht nötig, denn das Sicherheitsteam versteht die Sicht der Entwickler ganz selbstverständlich. Das steigert die Beteiligung und eröffnet Entwicklungs- und Sicherheitsteams neue Möglichkeiten, effektiver zusammenzuarbeiten.

Entwicklerorientierte Sicherheit

Ein weiteres zentrales Thema 2021 war die Notwendigkeit, dass sich Sicherheitsteams an die Entwicklung anpassen – nicht umgekehrt. Noch vor wenigen Jahren beheben Sicherheitsteams Schwachstellen, indem sie am Ende des Entwicklungszyklus eine Liste mit Problemen vorlegten. Die Trennung zwischen Entwicklungs- und Sicherheitsteams ließ Entwickler das Gefühl haben, dass man ihnen am Ende jedes Zyklus die Probleme vor die Füße warf, und drängte Sicherheitsexperten in eine regulatorische (und oft kritische) Rolle.

In den vergangenen Jahren haben Unternehmen erkannt, dass Sicherheit in bestehende SDLC-Praktiken eingebettet und an die Bedürfnisse von Entwicklern angepasst werden muss. Wieder zeigt sich, wie wichtig Empathie und eine gute Zusammenarbeit zwischen Entwicklern und Sicherheitsexperten sind. Dev Akhawe (Head of Security bei Figma) verdeutlichte dies anhand seines Umgangs mit Entwicklern bei Sicherheitsfragen. Als er bei Figma die Einführung von Sicherheitsschlüsseln leitete, „entschuldigte ich mich immer und sagte: ‚Es tut mir leid. Wir haben Sicherheitsschlüssel noch nicht eingeführt.‘ Sie müssen beim Thema Phishing vorsichtig sein. [Der] Trick, der sich wahrscheinlich als sehr wirksam erwiesen hat, ist die Erinnerung daran, dass es wirklich Aufgabe des Sicherheitsteams ist, dafür zu sorgen, dass sich die Systeme, die wir verwenden und entwickeln, nicht falsch verhalten. Statt Entwicklern zu sagen, dass sie diese hundert Dinge tun müssen.“ (Folge 88)

Dieser Wandel verlief nicht einseitig. Auch in der Welt der Entwickler-Tools wird zunehmend anerkannt: „Sicherheit ist nichts, was abseits stattfindet. Jedes Entwickler-Tool trägt eine gewisse Verantwortung dafür, Sicherheit in die Workflows zu integrieren.“ Je stärker Entwicklung und Sicherheit miteinander verwoben werden, desto deutlicher wird: „Sicherheit passt sich an Entwicklungstools und Entwicklungspraktiken an […] und Führungskräfte in der Entwicklung nehmen Sicherheit wirklich an und denken über ihre Verantwortung dafür nach.“

Sicherheit im großen Maßstab

Das dritte Thema war die Bedeutung von Sicherheitshygiene im großen Maßstab. Systeme mit dem Tempo der Branche abzusichern, ist entscheidend für den Erfolg eines Unternehmens. Das bedeutet, die Grundlagen richtig umzusetzen – und sich nicht auf Cyberangriffe wie im Kino vorzubereiten. Das AppSec-Pendant zum Abschließen von Türen und Fenstern reicht oft aus, um ein Unternehmen gegen einfache Angriffe zu wappnen und es auf ein effizientes Vorgehen bei einer schwerwiegenden Schwachstelle vorzubereiten. „Die Grundlagen im großen Maßstab und mit hoher Geschwindigkeit umzusetzen, ist sehr schwierig. Fast alle Programme und Initiativen ... haben sich dieses Jahr darauf konzentriert, die Kernaufgaben im großen Maßstab und mit hohem Tempo richtig zu erledigen.“

Wenn Entwickler die Grundlagen kennen, mit denen sie ihre Systeme schützen, können sie Strategien für größere Probleme entwickeln – etwa für die jüngste Log4Shell-Schwachstelle. Während einige Unternehmen fieberhaft herauszufinden versuchten, was passiert war und welche Auswirkungen es für sie hatte, konnten andere dank umfassender Sicherheitshygiene und klarer Strukturen weitgehend wie gewohnt weiterarbeiten. „Bei Snyk haben wir [...] einen starken Anstieg von Personen beobachtet, die Projekte hinzugefügt haben. Ich denke, dadurch ist auch [...] ein gewisser Handlungsdruck entstanden. Selbst diejenigen, die bereits auf einem guten Weg waren, wurden daran erinnert, dass sie [...] alle ihre Projekte im Blick haben müssen. Man kann das nicht einfach nach und nach umsetzen – das ist einer der wesentlichen Unterschiede zwischen Entwicklung und Sicherheit.“ (Folge 106) Entwickler-Tools werden oft lokal eingesetzt und Fall für Fall erweitert. Sicherheitslösungen müssen dagegen sofort eine breite Abdeckung bieten, um wirksam zu sein. Keine der beiden Vorgehensweisen ist falsch, doch Log4Shell und ähnliche Vorfälle haben uns gezeigt, dass es riskant ist, Sicherheitstools wie eine Entwicklungslösung einzuführen.

Höhepunkte der Folgen aus 2021

Log4Shell war vielleicht unsere jüngste Lektion, aber längst nicht das Einzige, was uns 2021 gelehrt hat. Hier sind einige Folgen, die Sie nicht verpassen sollten.

Der Codecov-Angriff (#1022)

Guy sprach mit CodeCov-CEO Jerrod Engelberg und CTO Eli Hooten darüber, wie sie mit dem Sicherheitsvorfall von 2021 umgingen. In der Folge ging es um viele Erkenntnisse zum Umgang mit den konkurrierenden Prioritäten während eines Sicherheitsvorfalls. Engelberg und Hooten schilderten zunächst Guys die interne Reaktion. Engelberg sagte: „Wenn auch nur ein Kunde nichts von uns erfährt […] und nicht die geeigneten Maßnahmen ergreifen kann, ist das ein Kunde zu viel.“ Von dort aus entwickelte sich das Gespräch von der Ethik der Offenlegung hin zu den impliziten Risiken, mit denen wir als Branche umgehen müssen. „Es gibt immer diesen Handschlag, richtig? Wir können ihn immer ausgefeilter gestalten, aber ich denke, darüber mache ich mir viele Gedanken“, sagte Engelberg.

Container, Prozesse und die Zukunft der Sicherheit (#103)

Liz Rice, Chief Open Source Officer bei Isovalent, gab uns eine Einführung in eBPF und teilte ihre Gedanken zur Bedeutung von Cloud-Native-Netzwerken. „Wir erleben eine sehr schnelle Verbreitung von Cloud-Technologien. Ich denke, die Nutzung der Cloud wird für jedes Unternehmen selbstverständlich sein. Von Early Adopters werden wir dann sicher nicht mehr sprechen“, sagte Rice.

Anwendungssicherheit im öffentlichen Sektor (#86, #95):

In mehreren Folgen ging es um die zunehmende Einführung von DevSecOps durch Behörden und die Parallelen zu privaten Softwareunternehmen. Robert Wood von CMS for Medicare & Medicaid war in Folge 95 zu Gast; Nicolas Chaillan, CSO der US Air Force, in Folge 86. Beide Gäste standen vor der Herausforderung, traditionell unabhängige Organisationen auf die für DevOps erforderliche Plattformorientierung umzustellen. Für Wood bedeutet das, „diese riesigen Datenmengen, die uns vorliegen, sinnvoll zu erschließen, denn üblicherweise haben wir all diese Sicherheitsaktivitäten, die in Silos voneinander getrennt sind. Sie funktionieren alle irgendwie eigenständig oder ... liefern Erkenntnisse, aber keine Daten, die sich mit anderen verknüpfen lassen, um noch wertvollere Erkenntnisse zu gewinnen.“

Das Gespräch zwischen Chaillan und Guy verdeutlichte einen der klaren Unterschiede zwischen DevOps im öffentlichen und im privaten Sektor. Für Behörden sind die Nachteile einer Vorreiterrolle deutlicher erkennbar als deren Vorteile. Das führt zu einer geringeren Risikobereitschaft und einer langsamen Einführung, wie sie für Behörden typisch sind. Chaillain glaubt: „Die Cybersicherheit wird sich weiterentwickeln. Ich denke, dabei wird es vor allem um die Fähigkeit zur kontinuierlichen Überwachung gehen. Das große Risiko liegt meiner Meinung nach in Abhängigkeiten oder Produkten, die Sie verwenden, über die Sie aber nur wenig wissen.“

Spannende Themen für 2022

Während wir die Erkenntnisse dieses Jahres verarbeiten, werfen wir auch einen Blick in die Kristallkugel und darauf, was 2022 bereithält. Zum Abschluss jeder Folge bittet Guy seine Gäste, genau das zu tun und über die Zukunft unserer Branche zu spekulieren. Zum Jahresausklang konnte Simon den Spieß umdrehen und Guy nach seinen wichtigsten Themen und Erwartungen fragen. Auf Branchenebene werden drei Bereiche entscheidend sein: Supply-Chain-Sicherheit, Cloud und neue Methoden zur Messung von Sicherheit, während diese zunehmend dezentral organisiert wird.

Supply-Chain-Sicherheit

Die Notwendigkeit von Supply-Chain-Sicherheit wurde durch SolarWinds, CodeCov, Log4Shell und weitere Vorfälle deutlich. „Wir haben ein Netz aus Abhängigkeiten zwischen Diensten, Komponenten und Personen geschaffen, das wir in den Griff bekommen müssen.“ Da Unternehmen immer stärker miteinander verflochten sind, müssen wir als Branche zusammenarbeiten, um Supply-Chain-Risiken zu definieren und anzugehen.

Cloud-Sicherheit

Cloud-Sicherheit wurde traditionell als Erweiterung der IT-Sicherheit betrachtet. Wahrscheinlich werden wir jedoch zunehmend anerkennen, dass die Cloud Software ist und Software-Sicherheitstools benötigt, um sensible Informationen zu schützen.

AppSec messbar machen

Sicherheit zu messen ist wichtig, denn wir brauchen eine Möglichkeit, Codeaktivitäten direkt mit Risiken in Beziehung zu setzen. Während sich DevOps weiterentwickelt, werden diese Daten ein wesentlicher Bestandteil der Geschäftsstrategie sein. Wenn sich Kennzahlen zur Verfügbarkeit mit Kennzahlen zum Geschäftserfolg verknüpfen lassen, kann Sicherheit in immer mehr Anwendungsbereichen an Bedeutung gewinnen.

Allgemein hofft Guy, dass wir wieder stärker die Anwendung als Ganzes betrachten – als eine einzelne Einheit mit vielen beweglichen Teilen. Wir nähern uns rasch einem Punkt, an dem es unmöglich sein wird, jede einzelne lokale Schwachstelle zu beheben. Die übliche segmentierte Sicht auf Sicherheit wird daher nicht funktionieren. Wir müssen Anwendungen und die Supply Chain als Ganzes betrachten und eine Taxonomie sowie geeignete Tools schaffen, um über Sicherheit auf einer höheren Ebene zu sprechen.

Unser Ziel bei Snyk ist es, Tools zu entwickeln, die Sicherheit selbstverständlich machen. Wir entlasten Entwickler, indem wir ihnen ermöglichen, Schwachstellen in nur 5 Minuten zu finden und zu beheben. Lassen Sie uns Ihr Anwendungssicherheitsteam unterstützen und gemeinsam herausfinden, was Sie heute erreichen können.