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

Angesichts des aktuellen Wirtschaftsklimas und der Bedrohungslandschaft beneide ich den durchschnittlichen CISO sicherlich nicht. Sie haben die Aufgabe, Sicherheit, Compliance, Innovation und Geschäftswert zu gewährleisten. Gleichzeitig stehen sie vor einem harten Kampf mit schrumpfenden Budgets und verstärkter Kontrolle. Vielleicht noch dringlicher ist die Tatsache, dass sich jedes Unternehmen (und das jeweilige Entwicklungsteam) in unterschiedlichen Reifegraden der Sicherheit befindet und nicht alle in der Lage sind, im Bereich Cyberabwehr ihr Bestes zu geben.

Die eskalierenden Cybersicherheitsvorfälle in den letzten Jahren haben es für Sicherheitsverantwortliche ziemlich schwierig gemacht, immer einen Schritt voraus zu sein. Ein Blick auf einige der datengestützten Erkenntnisse über unsere wachsende Situation zeigt etwas wie ein Pulverfass: mehr als 33 Milliarden Datensätze werden allein 2023 von Cyberkriminellen gestohlen, ein Anstieg von 175% gegenüber 2018. Das Die Kosten der Cyberkriminalität werden sich bis 2025 voraussichtlich auf 10,5 Billionen US-Dollar belaufen, und die durchschnittlichen Kosten einer Datenschutzverletzung sind sprunghaft angestiegen 4,24 Millionen USD (obwohl wir uns nur Vorfälle wie Equifax oder Solar Winds ansehen müssen, um zu sehen, dass dies der Fall sein kann viel schlimmer).

Als Branche haben wir lange darauf gewartet, dass ein Held kommt und uns vor den Cybersicherheits-Bösewichten rettet, die mehr Macht zu haben scheinen, als wir es noch vor zehn Jahren für möglich gehalten hätten. Wir warten darauf, dass mehr Cybersicherheitsexperten an Bord kommen und uns zu einem höheren Sicherheitsstandard führen, aber diese Lücke können wir nicht schließen. Wir warten auf die Wunderwaffe, die verspricht, uns zu automatisieren, um das wachsende Risiko zu vermeiden, aber das ist nicht der Fall und es ist sehr unwahrscheinlich, dass sie existiert. Wir warten darauf, dass unser Luke Skywalker uns hilft, die Dunkle Seite zu bekämpfen.

Wie sich herausstellt, ist Hilfe (und Hoffnung) auf dem Weg, in Form von Der Mobilisierungsplan für Open-Source-Softwaresicherheit. Wir müssen jedoch alle Bilanz ziehen und ehrlich beurteilen, ob wir in unserer Organisation ausgereift genug sind — und ob unsere Entwicklungsteams über das richtige Maß an Sicherheitsbewusstsein und Fähigkeiten verfügen —, um die neuesten und besten Abwehrstrategien umzusetzen, insbesondere wenn sie die Unterstützung und Umsetzung durch das Entwicklungsteam benötigen.

Was ist der Plan zur Mobilisierung der Open-Source-Softwaresicherheit?

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 angeführt. Mit dieser kombinierten Unterstützung sowohl in Bezug auf Maßnahmen als auch auf finanzielle Unterstützung wird der Sicherheitsstandard von Open-Source-Software deutlich steigen.

Besonders interessant ist, dass sie sich auf die Grundausbildung und Zertifizierung auf Entwicklerebene sowie auf Maßnahmen zur Rationalisierung interner Aktivitäten mit der Softwareliste (SBOM) konzentrieren. Beides ist bekanntermaßen schwierig in einer Weise umzusetzen, die eine nachhaltige Wirkung hat. Dies ist zum Teil auf die wachsenden Probleme innerhalb der Sicherheitsprogramme der Unternehmen und auf einen allgemeinen Mangel an Sicherheitsreife innerhalb der Entwicklungskohorte zurückzuführen, der nicht von ihnen selbst verschuldet wurde. Sie befinden sich in einer Schnellkochtopf-Umgebung, in der die Geschwindigkeit des Codevolumens angesichts der immer unzumutbareren Fristen an oberster Stelle steht. Noch mehr Aufgaben in Form von Sicherheitsanfragen und SBOM-Wartung hinzuzufügen, ohne die dafür zur Verfügung stehende Zeit zu erhöhen, ist ein Rezept, das schon gescheitert ist, bevor es überhaupt begonnen hat, und leider kommt es häufiger vor, als wir vielleicht erwarten.

Werfen wir also einen Blick unter die Motorhaube.

Sicherheitszertifizierung für Entwickler: Sind wir schon da?

Wenn es eine Sache gibt, die wir mit Sicherheit wissen, dann ist es das Entwickler mit Sicherheitskenntnissen sind immer noch ein seltenes Gut. Dies ist aus einer Reihe von Gründen die Realität, nämlich weil Entwickler bis vor Kurzem nicht Teil der Gleichung waren, wenn es um Softwaresicherheitsstrategien innerhalb von Organisationen ging. Hinzu kommt, dass Entwickler nicht viel Grund haben, der Sicherheit Priorität einzuräumen (ihre Schulung ist unzureichend oder nicht vorhanden, es dauert länger, es ist nicht Teil ihrer KPIs und ihr Hauptanliegen ist, das zu tun, was sie am besten können: Funktionen zu entwickeln), und Sie haben Entwicklungsteams, die schlecht darauf vorbereitet sind, sich wirklich mit Sicherheit auf Codeebene zu befassen und ihre Rolle in einem modernisierten, DevSecOps-zentrierten Softwareentwicklungszyklus (SDLC) zu spielen.

Wenn wir uns den Open Source Software Security Mobilization Plan ansehen, geht es in der allerersten Phase des Zehn-Punkte-Plans um Sicherheitskompetenzen von Entwicklern, um „allen eine grundlegende Ausbildung und Zertifizierung zur sicheren Softwareentwicklung zu bieten“, was für den Ausbau der Sicherheitsreife in Entwicklungsteams unerlässlich ist. Sie heben die Themen hervor, die wir seit einiger Zeit erörtern, einschließlich der Tatsache, dass sichere Codierung in den meisten Softwaretechnikkursen im Tertiärbereich nicht berücksichtigt wird. 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, und 99% der weltweiten Software enthalten mindestens einige Open-Source-Code, dieser Entwicklungsbereich ist ein großartiger Ausgangspunkt, um sich auf die Schulung von Entwicklern im Bereich Sicherheit zu konzentrieren.

Der Plan zitiert verehrte Ressourcen wie die Grundlagen der sicheren OpenSSF-Software Kurse und die umfangreichen, langjährigen Ressourcen der OWASP-Stiftung. Diese Informationszentren sind von unschätzbarem Wert. Die vorgeschlagene Einführung, um diese Materialien für die Weiterbildung von Entwicklern zur Verfügung zu stellen, 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 zentralen Bestandteil des Lehrplans zu machen.

Was die Art und Weise angeht, wie sie die Herzen und Köpfe von Softwareingenieuren auf der ganzen Welt für sich gewinnen können, von denen viele die Sicherheit als etwas, das nicht ihre Aufgabe oder Priorität ist, verstärken lassen, beschreibt der Plan eine Strategie zur Belohnung und Anerkennung, die sich sowohl an Entwickler richtet, die Open-Source-Bibliotheken verwalten, 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 abgestufte Badging-Systeme, die Fortschritte und Fähigkeiten anzeigen, in einer Lernumgebung genauso gut funktionieren wie auf Steam oder Xbox.

Besorgniserregend ist jedoch, dass wir uns nicht mit einem der Kernprobleme befassen, nämlich der Bereitstellung von Lernmodulen im Rahmen des Sicherheitsprogramms einer Organisation. Da ich die meiste Zeit meiner Karriere eng mit Entwicklern zusammengearbeitet habe, weiß ich, wie skeptisch sie sind, wenn es um Tools und Schulungen geht, ganz zu schweigen von allem, was aussieht, als ob es die Arbeit stören könnte, die oberste Priorität hat. Um Entwickler zu unterstützen, müssen sie sich kontinuierlich mit dem Kursmaterial auseinandersetzen, und damit dies erfolgreich ist, muss es im Kontext ihrer täglichen Arbeit Sinn machen.

Wenn wir ein etabliertes Reifegradmodell wie das betrachten Reifegradmodell für Softwaresicherheit (SAMM), „Education & Guidance“ ist ein Kernbestandteil der Governance-Ebene, und ein Schwerpunkt liegt auf der Ausbildung von Entwicklern. Das Modell in seiner Gesamtheit ist umfangreich, und es gibt schrittweise Schritte, um einen höheren Reifegrad zu erreichen. In der Anfangsphase wird jedoch eine formelle Schulung der Entwickler von nur 1—2 Tagen empfohlen, was kaum ausreicht, um das Sicherheitsbewusstsein zu stärken. Selbst dann ein aktueller Bericht Eine Studie der Enterprise Strategy Group (ESG) ergab, dass weniger als die Hälfte der Unternehmen von Entwicklern verlangt, dass sie mehr als einmal im Jahr an formellen Sicherheitsschulungen teilnehmen. Unser eigene Recherchen in Zusammenarbeit mit Evans Data ergab, dass nur 29% der Entwickler die aktive Praxis des Schreibens von Code ohne Schwachstellen sollte priorisiert werden. Es besteht ein klarer Unterschied zwischen der Art und Weise, wie Bildung vermittelt und angenommen wird, und der Frage, wie nützlich sie wirklich ist, um die Sicherheitsreife zu erreichen, insbesondere wenn Entwickler keinen Nutzen darin sehen.

Softwareliste: Überwindet dieser Plan die Hindernisse bei der Einführung?

Ein weiterer Bereich, der mit dem Plan angegangen werden soll, ist das Problem, das häufig im Zusammenhang mit der Erstellung und Wartung von Software-Stücklisten (SBOM) auftritt. Der Stream „SBOM Everywhere — Improve SBOM Tooling and Training to Drive Adoption“ untersucht, wie Entwickler und ihre Organisationen die Erstellung, Aktualisierung und Verwendung von SBOMs erleichtern können, um bessere Sicherheitsergebnisse zu erzielen.

Derzeit sind SBOMs in den meisten Branchen nicht weit verbreitet, was es schwierig macht, ihr Potenzial zur Reduzierung von Sicherheitsrisiken auszuschöpfen. Der Plan beinhaltet eine hervorragende Strategie zur Definition wichtiger Standards für die SBOM-Formulierung sowie von Tools, die die Erstellung vereinfachen und zur Arbeitsweise der Entwickler passen. Diese allein würden einen großen Beitrag dazu leisten, den Aufwand einer weiteren SDLC-Aufgabe für Entwickler zu verringern, die bereits viele Platten drehen, um Software mit der Geschwindigkeit der Nachfrage zu entwickeln.

Was ich jedoch befürchte, ist, dass Sicherheitsaufgaben in einer durchschnittlichen Organisation für Entwickler eine echte Grauzone sein können. Wer ist für die Sicherheit verantwortlich? Letztlich ist es das Sicherheitsteam, aber Entwickler müssen mit auf die Reise genommen werden, wenn wir ihre Hilfe benötigen. Aufgaben und Erwartungen müssen klar definiert sein, und sie brauchen Zeit, um diese zusätzlichen Maßnahmen für ihren Erfolg zu ergreifen.

Von OSS zum Rest der Softwarewelt

Der Open Source Software Security Mobilization Plan ist ehrgeizig, mutig und genau das, was benötigt wird, um die Verantwortung der Entwickler für Sicherheit zu stärken. Es bedurfte einer „Rebellenallianz“ einiger mächtiger Akteure, die sich zusammenschließen, aber das ist ein Beweis dafür, dass wir auf dem richtigen Weg sind und die Vorstellung hinter uns lassen, dass sich die Qualifikationslücke im Bereich Cybersicherheit auf magische Weise von selbst beheben wird.

Das ist unsere neue Hoffnung, und wir werden uns alle brauchen, um diese Struktur über OSS hinaus voranzutreiben. Sicherheitsexperten müssen jedoch in sich selbst schauen und die Entwicklungsteams analysieren, die an dem Code arbeiten, den sie schützen sollen. Sie müssen ihre aktuellen Fähigkeiten ehrlich einschätzen, wo die Lücken liegen, und daran arbeiten, einen ausgereiften Staat in der Spätphase zu schaffen, der luftdicht, proaktiv und inklusiv ist und ein Programm beinhaltet, das der Entwicklungskohorte echte Sicherheitskompetenzen vermittelt. Solange sie nicht sinnvoll aktiviert sind, sind wir möglicherweise noch etwas unausgereift in unserem Umgang mit Sicherheitslücken auf Codeebene.

‍

>> Testen Sie die Sicherheitsreife Ihres Teams mit unseren praktischen, interaktiven XSS-Herausforderung!