Sicherheitsverantwortung in großem Maßstab: Twilios Perspektive

Während Unternehmen zunehmend DevSecOps-Praktiken einsetzen, um sichere Software bereitzustellen, wird die Sicherheitsverantwortung immer wichtiger. Snyk veranstaltete kürzlich gemeinsam mit Twilio einen Roundtable, um über Sicherheitsverantwortung im Jahr 2021 zu sprechen.

In diesem Beitrag fassen wir das Gespräch zwischen Guy Podjarny, President & Co-Founder von Snyk, und Yashvier Kosaraju, Senior Manager of Product Security bei Twilio, zusammen. Twilios Product-Security-Teams nutzen Snyk Open Source, um sicherzustellen, dass Code in allen Phasen des Designs und der Bereitstellung sicher ist.

Wer wofür verantwortlich sein sollte: Development oder Security

Wenn Unternehmen auf einen DevSecOps-Ansatz umsteigen, müssen sie zunächst eine zentrale Frage beantworten: Wofür sollten unsere Entwickler- und Security-Teams im Hinblick auf Praktiken und Prozesse verantwortlich sein?

Security-Teams sollten für sämtliche Sicherheitsfunktionen verantwortlich sein, etwa für Scans, Threat-Modelle und Penetrationstests sowie für die Prozesse rund um einen sicheren Softwareentwicklungszyklus (SSDLC) und die Unternehmenssicherheit. Entwicklungsteams hingegen sollten das Risiko verantworten und dafür sorgen, dass Schwachstellen zeitnah behoben werden.

Kosaraju ist jedoch der Ansicht, dass das Security-Team die Tools so bereitstellen sollte, dass sie einfach zu nutzen sind und sich Ergebnisse leichter erzielen lassen.

„Bei der Einstellung von Entwicklern achten Sie auf Dinge wie: Können sie programmieren, können sie entwerfen und kennen sie Algorithmen?“, sagt Kosaraju. „Das ist kein Nachteil, aber Security-Know-how hat im Einstellungsprozess selten höchste Priorität. Deshalb ist ein zentrales Team, das sich auf Security konzentriert und diese Entscheidungen für Ihr Unternehmen trifft, entscheidend.“

Letztlich müssen Führungskräfte entscheiden, wer wofür verantwortlich ist. Das Security-Team muss jedoch als „Kompetenzzentrum“ für Entwickler dienen, denn Praktiken und Kontrollen müssen direkt in Anwendungen integriert werden.

Außerdem müssen bestimmte Prozesse einer Organisationsstruktur zugeordnet werden. Andernfalls erhalten Unternehmen eine Risikobewertung mit unzähligen Schwachstellen, ohne dass eine Geschäftseinheit eingebunden ist, um sie zu beheben. Eine von Anfang an klar definierte Sicherheitsverantwortung führt zu konkreten Maßnahmen.

Das Mindset „Wir sind Entwickler, keine Security-Leute“ überwinden

Entwickler dazu zu bewegen, Sicherheit zu übernehmen, kann für Unternehmen schwierig sein. Häufig gibt es zwei große Hürden beim Einstieg: Transparenz und Benutzerfreundlichkeit.

Zunächst gibt es bei Security keinen natürlichen Feedback-Kreislauf. Dadurch häufen sich Schwachstellen oft an und bleiben ungelöst, bis es so viele sind, dass sie sich auf das Geschäft auswirken. Unternehmen müssen Sicherheitsanforderungen klar formulieren und allen Entwicklern sichtbar machen.

Tatsächlich ist Security einfach zu kompliziert. Damit Entwickler sie annehmen, muss sie einfacher werden. Ein häufiger Fehler von Unternehmen ist, zu viel zu früh in Angriff zu nehmen. Suchen Sie beim Einstieg nach einem schnellen Erfolg, etwa durch die Einführung von Open-Source-Sicherheit und Software Composition Analysis (SCA).

„Ich halte es für wichtig, sichtbar zu machen, wo Sie heute stehen und wohin Sie sich im Rahmen einer kontinuierlichen Verbesserung entwickeln müssen. Transparenz ist daher entscheidend“, sagt Kosaraju. „Außerdem sollten Sie klare Grenzen festlegen. Wenn Sie beispielsweise sagen, das Security-Team sichert das Unternehmen ab: Bedeutet das, dass es Sicherheitsprobleme findet, die behoben werden müssen, oder dass es diese Probleme selbst behebt? Eine klare Aufteilung der Zuständigkeiten ist entscheidend.“

Auf Code-Ebene führte Twilio ein Verantwortungsmodell ein, bei dem alle Entwickler gebeten wurden, jedem Code-Repository eine YAML-Datei hinzuzufügen. Jede Datei enthält die nötigen Informationen, um die Verantwortlichen für das jeweilige Repository zu ermitteln. Das Security-Team kann dann Tickets in der richtigen Warteschlange erstellen und die zuständigen Personen bei einem Vorfall oder einer Schwachstelle kontaktieren. So konnte das Unternehmen davon wegkommen, Verantwortliche manuell ausfindig zu machen, und stattdessen sofort das richtige Team finden und das Schwachstellenmanagement automatisieren.

Sicherheit messen – einen Entwickler nach dem anderen

Ein Bug-Bounty-Programm ist ein guter Ausgangspunkt, um den ROI von Security-Tools zu ermitteln. Sobald das Programm eingerichtet ist, können Tools in verschiedene Phasen des SDLC integriert und die Zahl der Bug-Bounty-Meldungen gesenkt werden. Weniger Meldungen ermöglichen es Teams, sich verstärkt auf Shift-Left-Security-Praktiken zu konzentrieren.

„Denken Sie daran: Wird ein neues Tool eingeführt, steigt die Zahl der gefundenen Bugs immer zunächst stark an“, sagt Kosaraju. „Wichtig ist, Mängel bei Security-Tools und -Funktionen klar zu benennen. Security-Teams sind nicht perfekt. Doch wenn Sie diese Realität anerkennen, zeigen Sie, dass alle gemeinsam daran arbeiten, das Unternehmen sicherer zu machen und ein Security-Mindset zu etablieren.“

Am besten können Entwickler Schwachstellen in den Gesamtkontext einordnen, wenn sie betrachten, wie lange kritische Schwachstellen in einer Warteschlange offen bleiben. Dieser Messwert zeigt besonders gut, wie schnell Teams Schwachstellen beheben. Wenn das Security-Team beispielsweise Tool X einsetzt, das 30 kritische Schwachstellen meldet, und ein Engineering-Team innerhalb von zwei Wochen 29 davon behebt, ist das ein hervorragender Messwert, den Sie im Zeitverlauf verfolgen sollten.

Da sich die Sicherheitsverantwortung jedes Jahr weiterentwickelt, veranstaltet Snyk regelmäßig Webinare, um unterschiedliche Perspektiven von Security-Fachleuten aus der Branche einzuholen. Diese Roundtables bieten Snyk die Gelegenheit, die Anforderungen von Application-Security-Teams und Entwicklern besser zu verstehen. So können Unternehmen ihre Produkte weiterhin auf die Sicherheitsanforderungen von Organisationen wie Twilio abstimmen.