Sind wir reif genug für den Open Source Software Security Mobilization Plan?

Im aktuellen wirtschaftlichen Klima und angesichts der Bedrohungslage beneide ich den durchschnittlichen CISO wahrlich nicht. Er hat die Aufgabe, Sicherheit, Compliance, Innovation und geschäftlichen Mehrwert zu liefern, während er gleichzeitig gegen schrumpfende Budgets und eine zunehmende Kontrolle ankämpfen muss. Noch dringlicher ist vielleicht die Tatsache, dass sich jede Organisation (und ihr jeweiliges Entwicklungsteam) in unterschiedlichen Stadien der Sicherheitsreife befindet und nicht alle in der Lage sind, in Sachen Cyberabwehr ihr Bestes zu geben.

Die eskalierenden Cybersicherheitsvorfälle der letzten Jahre haben es für Sicherheitsverantwortliche ziemlich schwierig gemacht, einen Schritt voraus zu bleiben. Ein Blick auf einige datengestützte Erkenntnisse zu unserer wachsenden Notlage offenbart ein Pulverfass: Allein im Jahr 2023 werden 33 Milliarden Datensätze von Cyberkriminellen gestohlen, ein Anstieg von 175 % gegenüber 2018. Die Kosten durch Cyberkriminalität werden bis 2025 voraussichtlich 10,5 Billionen US-Dollar erreichen, und die durchschnittlichen Kosten einer Datenschutzverletzung sind auf 4,24 Millionen US-Dollar in die Höhe geschossen (obwohl wir nur auf Vorfälle wie Equifax oder SolarWinds schauen müssen, um zu sehen, dass es weitaus schlimmer kommen kann).

Als Branche haben wir lange darauf gewartet, dass ein Held auftaucht und uns vor den Cyber-Bösewichten rettet, die scheinbar mehr Macht haben, als wir uns noch vor zehn Jahren vorstellen konnten. Wir warten darauf, dass mehr Cybersicherheitsexperten an Bord kommen und uns auf ein höheres Niveau bei Sicherheitsprogrammen heben, aber diese Lücke können wir nicht schließen. Wir warten auf das „Wundermittel“-Tool, das uns verspricht, die wachsende Gefahr durch Automatisierung verschwinden zu lassen, aber das gibt es nicht und wird es höchstwahrscheinlich auch nie geben. Wir warten auf unseren Luke Skywalker, der uns im Kampf gegen die dunkle Seite unterstützt.

Wie sich herausstellt, ist Hilfe (und Hoffnung) in Form des Open Source Software Security Mobilization Plan auf dem Weg. Wir müssen jedoch alle innehalten und ehrlich beurteilen, ob unsere Organisation bereits reif genug ist – und ob unsere Entwicklungsteams über das nötige Sicherheitsbewusstsein und die entsprechenden Fähigkeiten verfügen –, um die neuesten und besten Verteidigungsstrategien umzusetzen, insbesondere wenn diese die Unterstützung und Ausführung durch das Entwicklungsteam erfordern.

Was ist der Open Source Software Security Mobilization Plan?

Dieser Zehn-Punkte-Plan wurde von der Open Source Software Foundation (OpenSSF) und der Linux Foundation in Zusammenarbeit mit Vertretern des Weißen Hauses, führenden CISOs und anderen hochrangigen Führungskräften von 37 privaten Technologieunternehmen initiiert. Mit dieser gemeinsamen Unterstützung in Form von Maßnahmen und Finanzmitteln soll der Sicherheitsstandard von Open-Source-Software deutlich gestärkt werden.

Besonders interessant ist der Fokus auf grundlegende Bildung und Zertifizierung auf Entwicklerebene sowie auf Maßnahmen zur Optimierung interner Software Bill of Materials (SBOM)-Aktivitäten. Beides ist bekanntermaßen schwer so umzusetzen, dass es eine nachhaltige Wirkung erzielt. Dies lässt sich teilweise auf Wachstumsschmerzen innerhalb der organisatorischen Sicherheitsprogramme und einen allgemeinen Mangel an Sicherheitsreife bei den Entwicklern zurückführen – ohne dass dies deren Schuld wäre. Sie befinden sich in einem Umfeld, das unter hohem Druck steht, in dem Code-Volumen und Geschwindigkeit bei immer unvernünftigeren Fristen an erster Stelle stehen. Das Hinzufügen weiterer Aufgaben in Form von Sicherheitsanforderungen und SBOM-Wartung, ohne die dafür verfügbare Zeit zu erhöhen, ist ein Rezept, das zum Scheitern verurteilt ist, bevor es überhaupt begonnen hat – und leider ist das häufiger der Fall, als wir vielleicht erwarten.

Werfen wir also einen Blick unter die Motorhaube.

Sicherheitszertifizierung für Entwickler: Sind wir schon so weit?

Wenn wir eines sicher wissen, dann, dass sicherheitskompetente Entwickler immer noch Mangelware sind. Das ist aus mehreren Gründen Realität: Bis vor Kurzem waren Entwickler bei Software-Sicherheitsstrategien in Unternehmen schlichtweg nicht Teil der Gleichung. Hinzu kommt, dass Entwickler kaum einen Grund haben, Sicherheit zu priorisieren (ihre Ausbildung ist unzureichend oder nicht vorhanden, es dauert länger, es ist nicht Teil ihrer KPIs, und ihr Hauptanliegen ist es, das zu tun, was sie am besten können: Funktionen zu entwickeln). Das Ergebnis sind Entwicklungsteams, die schlecht darauf vorbereitet sind, Sicherheit auf Code-Ebene wirklich zu handhaben oder ihre Rolle in einem modernisierten, DevSecOps-zentrierten Softwareentwicklungslebenszyklus (SDLC) zu spielen.

Wenn wir uns den Open Source Software Security Mobilization Plan ansehen, befasst sich der allererste Punkt des Zehn-Punkte-Plans mit den Sicherheitskompetenzen der Entwickler, um „grundlegende sichere Softwareentwicklungsbildung und -zertifizierung für alle bereitzustellen“, was für den Aufbau von Sicherheitsreife in Entwicklungsteams unerlässlich ist. Sie heben die Probleme hervor, die wir schon seit einiger Zeit diskutieren, einschließlich der Tatsache, dass sicheres Programmieren in den meisten Software-Engineering-Studiengängen an Hochschulen fehlt. Es ist unglaublich ermutigend zu sehen, dass dies von Einzelpersonen und Abteilungen unterstützt wird, die den Status quo der Branche verändern können. Da 99 % der weltweiten Software mindestens etwas Open-Source-Code enthalten, ist dieser Entwicklungsbereich ein hervorragender Ausgangspunkt, um sich auf die Sicherheitsausbildung von Entwicklern zu konzentrieren.

Der Plan verweist auf bewährte Ressourcen wie die OpenSSF Secure Software Fundamentals-Kurse und die umfangreichen, langjährigen Ressourcen der OWASP Foundation. Diese Informationszentren sind von unschätzbarem Wert. Die geplante Einführung, um diese Materialien zur Weiterbildung von Entwicklern bereitzustellen, beinhaltet die Zusammenführung eines breiten Netzwerks von Partnern aus dem öffentlichen und privaten Sektor sowie die Zusammenarbeit mit Bildungseinrichtungen, um die sichere Open-Source-Entwicklung zu einem festen Bestandteil der Lehrpläne zu machen.

Was die Frage betrifft, wie sie die Herzen und Köpfe von Softwareentwicklern weltweit gewinnen wollen – von denen viele verinnerlicht haben, dass Sicherheit nicht ihre Aufgabe oder Priorität ist –, so sieht der Plan eine Strategie zur Belohnung und Anerkennung vor. Diese richtet sich sowohl an Entwickler, die Open-Source-Bibliotheken pflegen, als auch an berufstätige Ingenieure, die den Wert von Sicherheitszertifizierungen erkennen müssen.

Wir wissen aus Erfahrung, dass Entwickler gut auf Anreize reagieren und dass gestaffelte Abzeichen-Systeme, die Fortschritt und Fähigkeiten zeigen, in einer Lernumgebung genauso gut funktionieren wie bei Steam oder Xbox.

Besorgniserregend ist jedoch, dass wir eines der Kernprobleme nicht angehen: die Bereitstellung von Lernmodulen innerhalb des Sicherheitsprogramms einer Organisation. Da ich einen Großteil meiner Karriere eng mit Entwicklern zusammengearbeitet habe, weiß ich, wie skeptisch sie gegenüber Tools und Schulungen sind – ganz zu schweigen von allem, was ihre Arbeit stören könnte, die für sie Priorität Nummer eins hat. Die Befähigung von Entwicklern erfordert, dass sie sich kontinuierlich mit Kursmaterial auseinandersetzen. Damit dies erfolgreich ist, muss es im Kontext ihrer täglichen Arbeit Sinn ergeben.

Wenn wir ein etabliertes Reifegradmodell wie das Software Assurance Maturity Model (SAMM) betrachten, ist „Bildung & Anleitung“ eine Kernkomponente der Governance-Ebene, mit einem klaren Fokus auf die Ausbildung von Entwicklern. Das Modell ist in seiner Gesamtheit umfangreich, und es gibt progressive Schritte, um höhere Reifegrade zu erreichen. Die Anfangsphasen empfehlen jedoch nur 1-2 Tage formale Schulung für Entwickler, was kaum ausreicht, um das Sicherheitsbewusstsein auch nur oberflächlich zu kratzen. Selbst dann ergab ein aktueller Bericht der Enterprise Strategy Group (ESG), dass weniger als die Hälfte der Unternehmen von Entwicklern verlangt, mehr als einmal im Jahr an einer formalen Sicherheitsschulung teilzunehmen. Unsere eigene Forschung in Zusammenarbeit mit Evans Data ergab, dass nur 29 % der Entwickler glauben, dass die aktive Praxis, Code frei von Schwachstellen zu schreiben, priorisiert werden sollte. Es gibt eine klare Diskrepanz zwischen der Art und Weise, wie Bildung vermittelt und aufgenommen wird, und ihrem tatsächlichen Nutzen für die Sicherheitsreife, insbesondere wenn Entwickler keinen Mehrwert darin sehen.

Software Bill of Materials: Baut dieser Plan die Hürden für die Einführung ab?

Ein weiterer Punkt, den der Plan adressieren möchte, ist das Chaos, das häufig bei der Erstellung und Pflege von Software Bill of Materials (SBOM) herrscht. Der Arbeitsbereich „SBOM Everywhere — Improve SBOM Tooling and Training to Drive Adoption“ untersucht Möglichkeiten, wie Entwickler und ihre Unternehmen SBOMs einfacher erstellen, aktualisieren und nutzen können, um die Sicherheit nachhaltig zu verbessern.

Derzeit sind SBOMs in den meisten Branchen noch nicht weit verbreitet, was es schwierig macht, ihr Potenzial zur Risikominimierung voll auszuschöpfen. Der Plan verfolgt eine hervorragende Strategie: Er definiert wichtige Standards für die SBOM-Erstellung und setzt auf Tools, die sich nahtlos in den Arbeitsalltag von Entwicklern integrieren lassen. Allein das würde die Arbeitslast für Entwickler, die bereits unter hohem Zeitdruck stehen, um eine weitere Aufgabe im SDLC-Prozess deutlich reduzieren.

Ich befürchte jedoch, dass Sicherheitsverantwortlichkeiten in vielen Unternehmen für Entwickler ein Graubereich bleiben. Wer ist für die Sicherheit zuständig? Letztlich das Sicherheitsteam, aber wir müssen die Entwickler mit ins Boot holen, wenn wir ihre Unterstützung wollen. Aufgaben und Erwartungen müssen klar definiert sein, und die Entwickler benötigen die nötige Zeit, um diese zusätzlichen Sicherheitsmaßnahmen erfolgreich umzusetzen.

Von Open Source auf die gesamte Softwarewelt übertragen

Der Open Source Software Security Mobilization Plan ist ambitioniert, mutig und genau das, was wir brauchen, um Entwickler stärker in die Sicherheitsverantwortung zu nehmen. Es bedurfte einer „Rebellen-Allianz“ aus einflussreichen Akteuren, um dies auf den Weg zu bringen. Es ist der Beweis, dass wir in die richtige Richtung gehen und uns von der Vorstellung verabschieden, dass sich die Fachkräftelücke in der Cybersicherheit von allein schließen wird.

Es ist unsere neue Hoffnung, und wir alle sind gefordert, diese Struktur über den Open-Source-Bereich hinaus voranzutreiben. Sicherheitsexperten müssen jedoch in sich gehen und die Entwicklungsteams analysieren, deren Code sie schützen sollen. Sie müssen ihre aktuellen Fähigkeiten ehrlich bewerten, Lücken identifizieren und auf einen ausgereiften Zustand hinarbeiten, der lückenlos, proaktiv und in ein Programm eingebettet ist, das Entwicklern echte Sicherheitskompetenzen vermittelt. Solange sie nicht sinnvoll befähigt werden, bleibt unser Ansatz bei Schwachstellen auf Code-Ebene möglicherweise noch etwas unausgereift.

‍

>> Testen Sie die Sicherheitsreife Ihres Teams mit unserer interaktiven XSS-Challenge!