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

Angesichts des derzeitigen Wirtschaftsklimas und der Bedrohungslage beneide ich den durchschnittlichen CISO sicher nicht. Sie haben die Aufgabe, für Sicherheit, Compliance, Innovation und Geschäftswert zu sorgen, während sie mit schrumpfenden Budgets und verstärkter Kontrolle zu kämpfen haben. Vielleicht noch dringlicher ist die Tatsache, dass sich jedes Unternehmen (und sein jeweiliges Entwicklungsteam) in unterschiedlichen Stadien der Sicherheitsreife befindet und nicht alle so ausgestattet sind, dass sie in Bezug auf die Cyberabwehr ihr Bestes geben können. 

In den letzten Jahren haben es die zunehmenden Vorfälle im Bereich der Cybersicherheit den Sicherheitsverantwortlichen ziemlich schwer gemacht, immer einen Schritt voraus zu sein. Ein Blick auf einige datengestützte Einblicke in unser wachsendes Dilemma offenbart so etwas wie ein Pulverfass: Allein im Jahr 2023 werden mehr als 33 Milliarden Datensätze von Cyberkriminellen gestohlen werden, ein Anstieg von 175 % gegenüber 2018. Die Kosten der Cyberkriminalität werden sich bis 2025 auf 10,5 Billionen US-Dollar belaufen, und die durchschnittlichen Kosten einer Datenschutzverletzung sind auf 4,24 Millionen US-Dollar in die Höhe geschnellt (obwohl wir uns nur Vorfälle wie Equifax oder Solar Winds ansehen müssen, um zu erkennen, dass es weitaus schlimmer sein kann). 

Als Branche haben wir lange auf einen Helden gewartet, der uns vor den Bösewichten im Bereich der Cybersicherheit rettet, die mehr Macht zu haben scheinen, als wir noch vor zehn Jahren für möglich hielten. Wir warten darauf, dass mehr Cybersicherheitsexperten an Bord kommen und uns auf einen höheren Standard von Sicherheitsprogrammen heben, aber diese Lücke können wir nicht schließen. Wir warten auf das Allheilmittel, das uns verspricht, das wachsende Risiko zu automatisieren, aber das gibt es nicht und es ist sehr unwahrscheinlich, dass es existiert. Wir warten auf unseren Luke Skywalker, der uns hilft, die dunkle Seite zu bekämpfen.

Wie sich herausstellt, ist Hilfe (und Hoffnung) auf dem Weg, und zwar in Form des Plans zur Mobilisierung der Open-Source-Software-Sicherheit. Allerdings müssen wir alle eine Bestandsaufnahme machen und ehrlich einschätzen, ob wir in unserer Organisation reif genug sind - und ob unsere Entwicklungsteams über das richtige Maß an Sicherheitsbewusstsein und Fähigkeiten verfügen -, um die neuesten und besten Verteidigungsstrategien zu implementieren, insbesondere wenn sie die Unterstützung und Ausführung durch das Entwicklungsteam erfordern.

Was ist der Plan zur Mobilisierung der Sicherheit von Open-Source-Software?

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 Führungskräften aus 37 privaten Technologieunternehmen entwickelt. Mit dieser kombinierten Unterstützung in Form von Maßnahmen und Finanzmitteln wird der Sicherheitsstandard von Open-Source-Software erheblich gestärkt werden. 

Besonders interessant ist ihr Fokus auf die grundlegende Ausbildung und Zertifizierung auf Entwicklerebene sowie auf Maßnahmen zur Rationalisierung interner Software Bill of Materials (SBOM) Aktivitäten. Beides ist notorisch schwierig in einer Weise zu implementieren, die eine dauerhafte Wirkung hat, was zum Teil auf Wachstumsschmerzen innerhalb der Sicherheitsprogramme des Unternehmens und einen allgemeinen Mangel an Sicherheitsreife bei den Entwicklern zurückzuführen ist, ohne dass diese selbst daran schuld sind. Sie befinden sich in einer Umgebung, in der der Druck auf ihnen lastet, in der Codevolumen und Geschwindigkeit die Oberhand haben, und das angesichts immer unvernünftigerer Fristen. Noch mehr Aufgaben in Form von Sicherheitsfragen 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 ist es häufiger, als wir vielleicht erwarten.

Werfen wir also einen Blick unter die Haube.

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

Wenn wir eines mit Sicherheit wissen, dann ist es, dass sicherheitskompetente Entwickler immer noch ein rares Gut sind. Dafür gibt es eine Reihe von Gründen, insbesondere die Tatsache, dass Entwickler bis vor kurzem nicht Teil der Gleichung waren, wenn es um Software-Sicherheitsstrategien in Unternehmen ging. In Verbindung mit der Tatsache, dass Entwickler wenig Grund haben, der Sicherheit Priorität einzuräumen (ihre Ausbildung ist unzureichend oder nicht vorhanden, es dauert länger, es ist nicht Teil ihrer KPIs, und ihr Hauptanliegen ist das, was sie am besten können: die Erstellung von Funktionen), haben Sie Entwicklungsteams, die schlecht darauf vorbereitet sind, sich wirklich mit der Sicherheit auf Code-Ebene zu befassen und ihre Rolle in einem modernisierten, DevSecOps-zentrierten Softwareentwicklungslebenszyklus (SDLC) zu spielen. 

Ein Blick auf den Open Source Software Security Mobilization Plan zeigt, dass der erste Teil des Zehn-Punkte-Plans sich mit den Sicherheitskompetenzen von Entwicklern befasst, nämlich mit der "Bereitstellung einer grundlegenden sicheren Softwareentwicklungsausbildung und -zertifizierung für alle", die für den Aufbau der Sicherheitsreife in Entwicklungsteams unerlässlich ist. Sie heben die Probleme hervor, die wir schon seit einiger Zeit diskutiert haben, einschließlich der Tatsache, dass sichere Kodierung in den meisten Studiengängen der Softwareentwicklung courses nicht vorkommt. Es ist unglaublich ermutigend zu sehen, dass dies von Einzelpersonen und Abteilungen unterstützt wird, die den Status quo in der Branche verändern können, und da 99 % der weltweiten Software zumindest einen Teil des Open-Source-Codes enthält, ist dieser Bereich der Entwicklung ein großartiger Ort, um sich auf die Ausbildung von Entwicklern im Bereich Sicherheit zu konzentrieren.

Der Plan verweist auf bewährte Ressourcen wie die OpenSSF Secure Software Fundamentals courses und die umfangreichen, langjährigen Ressourcen der OWASP Foundation. Diese Informationsdrehscheiben sind von unschätzbarem Wert. Die vorgeschlagene Einführung dieser Materialien für die Weiterbildung von Entwicklern 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 wichtigen Bestandteil des Lehrplans zu machen. 

Der Plan sieht eine Belohnungs- und Anerkennungsstrategie vor, die sich sowohl an Entwickler richtet, die Open-Source-Bibliotheken pflegen, als auch an berufstätige Ingenieure, die den Wert von Sicherheitszertifizierungen erkennen müssen, um die Herzen und Köpfe von Softwareingenieuren auf der ganzen Welt zu gewinnen, von denen viele die Sicherheit als etwas betrachtet haben, das nicht ihre Aufgabe oder Priorität ist. 

Wir wissen aus Erfahrung, dass Entwickler gut auf Anreize reagieren und dass abgestufte Abzeichensysteme, die den Fortschritt und die Fähigkeiten anzeigen, in einer Lernumgebung genauso gut funktionieren wie bei Steam oder Xbox.

Besorgniserregend ist jedoch, dass wir eines der Kernprobleme nicht angehen, nämlich die Bereitstellung von Lernmodulen im Rahmen des Sicherheitsprogramms eines Unternehmens. Da ich während eines Großteils meiner beruflichen Laufbahn eng mit Entwicklern zusammengearbeitet habe, weiß ich, wie skeptisch sie sind, wenn es um Tools und Schulungen geht, ganz zu schweigen von allem, was so aussieht, als könnte es die Arbeit unterbrechen, die Priorität Nummer eins ist. Die Befähigung von Entwicklern setzt voraus, dass sie sich kontinuierlich mit dem Kursmaterial auseinandersetzen, und damit dies erfolgreich ist, muss es im Kontext ihrer täglichen Arbeit einen Sinn ergeben.

Betrachtet man ein etabliertes Reifegradmodell wie das Software Assurance Maturity Model (SAMM), so ist "Education & Guidance" eine Kernkomponente der Governace-Schicht, und der Schwerpunkt liegt auf der Entwicklerschulung. Das Modell ist in seiner Gesamtheit sehr umfangreich, und es gibt progressive Stufen, um höhere Reifegrade zu erreichen. In den ersten Stufen werden jedoch nur 1 bis 2 Tage formale Schulung für Entwickler empfohlen, was kaum ausreicht, um das Sicherheitsbewusstsein an der Oberfläche anzukratzen. Ein kürzlich veröffentlichter Bericht der Enterprise Strategy Group (ESG) zeigt, dass weniger als die Hälfte der Unternehmen von ihren Entwicklern verlangen, dass sie mehr als einmal im Jahr an einer formellen Sicherheitsschulung teilnehmen. Unsere eigene Untersuchung in Zusammenarbeit mit Evans Data ergab, dass nur 29 % der Entwickler der Meinung sind, dass das aktive Schreiben von Code, der frei von Sicherheitslücken ist, Priorität haben sollte. Es besteht eine deutliche Diskrepanz zwischen der Art und Weise, wie Schulungen angeboten und angenommen werden, und dem tatsächlichen Nutzen für die Entwicklung der Sicherheitsreife, vor allem, wenn die Entwickler keinen Nutzen darin sehen.

Software-Stückliste: Werden mit diesem Plan die Barrieren für die Einführung abgebaut?

Ein weiterer Bereich, der im Rahmen des Plans angegangen werden soll, ist das Problem der Erstellung und Pflege von Software-Bill-of-Materials (SBOM). Im Rahmen des Projekts "SBOM Everywhere - Improve SBOM Tooling and Training to Drive Adoption" wird untersucht, wie Entwickler und ihre Organisationen SBOMs leichter erstellen, aktualisieren und nutzen können, um bessere Sicherheitsergebnisse zu erzielen.

Gegenwärtig werden SBOMs in den meisten vertikalen Branchen noch nicht in großem Umfang eingesetzt, was es schwierig macht, ihr Potenzial zur Verringerung von Sicherheitsrisiken zu nutzen. Der Plan enthält eine brillante Strategie zur Festlegung von Schlüsselstandards für die Formulierung von SBOMs sowie von Werkzeugen zur einfachen Erstellung, die sich an die Arbeitsweise der Entwickler anpassen. Dies allein würde die Belastung durch eine weitere SDLC-Aufgabe für Entwickler, die ohnehin schon viel zu tun haben, um Software mit der Geschwindigkeit der Nachfrage zu erstellen, erheblich verringern. 

Ich befürchte jedoch, dass die Zuständigkeiten für die Sicherheit in einem durchschnittlichen Unternehmen eine echte Grauzone für Entwickler sein können. Wer ist für die Sicherheit verantwortlich? Letztendlich ist es das Sicherheitsteam, aber die Entwickler müssen mit auf den Weg gebracht werden, wenn wir ihre Hilfe wollen. Aufgaben und Erwartungen müssen klar definiert werden, und sie brauchen Zeit, um diese zusätzlichen Maßnahmen für ihren Erfolg zu übernehmen. 

Von OSS zum Rest der Software-Welt

Der Open Source Software Security Mobilization Plan ist ehrgeizig, kühn und genau das, was nötig ist, um die Verantwortung der Entwickler für die Sicherheit zu stärken. Es bedurfte einer "Rebellen-Allianz" aus einigen mächtigen Akteuren, die sich zusammenfanden, aber dies ist ein Beweis dafür, dass wir uns in die richtige Richtung bewegen und die Vorstellung hinter uns lassen, dass sich die Lücke bei den Cybersicherheitskenntnissen auf magische Weise selbst beheben wird. 

Das ist unsere neue Hoffnung, und es wird uns alle brauchen, um diese Struktur über OSS hinaus voranzutreiben. Sicherheitsexperten müssen jedoch in sich gehen und die Entwicklungsteams analysieren, die an dem Code arbeiten, den sie zu schützen haben. Sie müssen eine ehrliche assessment ihrer aktuellen Fähigkeiten erstellen, wo die Lücken sind, und daran arbeiten, einen ausgereiften Spätstadium-Zustand zu schaffen, der luftdicht und proaktiv ist und ein Programm beinhaltet, das den Entwicklern echte Sicherheitsfähigkeiten vermittelt. Solange sie nicht sinnvoll aktiviert sind, sind wir vielleicht noch ein wenig unausgereift in unserer Herangehensweise an Schwachstellen auf Code-Ebene.

‍

>> Testen Sie die Sicherheit Ihres Teams mit unserer praktischen, interaktiven XSS-Herausforderung!