Die Entwicklung der OSPO-Sicherheit: das Kübler-Ross-Modell für Open Source

Was gehört zu einer OSPO? Open-Source-Programmbüros entstehen überall – als Reaktion auf die Realität: Open-Source-Software (und meiner Ansicht nach auch offene Standards) spielt eine enorme Rolle bei der Entwicklung und Wartung der Software, die unseren Planeten zunehmend antreibt. Der Bericht der Linux Foundation Die Entwicklung des Open-Source-Programmbüros (OSPO) beschreibt fünf Entwicklungsstufen einer OSPO:

• Stufe 0: Open Source ad hoc einsetzen

• Stufe 1: OSS-Compliance, Bestandsaufnahme und Entwicklerschulungen bereitstellen

• Stufe 2: Den Einsatz von OSS und die Beteiligung am Ökosystem fördern

• Stufe 3: OSS-Projekte betreiben und Communities aufbauen

• Stufe 4: Strategischer Partner für die Entscheidungsfindung werden

Doch wenn es um Sicherheit geht, kann es aufschlussreicher sein, an die fünf verschiedenen Phasen zu denken (à la Kübler-Ross-Modell):

• Verleugnung: Unternehmen verleugnen, in welchem Umfang sie von Open Source abhängig sind. Vielleicht glauben sie, es zu wissen. Doch wenn sie sich tatsächlich damit befassen, stellen sie fest, wie stark sie auf eine Reihe von Open-Source-Code und Open-Source-Tools angewiesen sind – insbesondere in der Build-Pipeline. Im Open-Source-Sicherheitsbericht 2022 von Snyk Open Source finden Sie weitere Informationen dazu. 

• Wut: Weil sie sich bisher nicht damit beschäftigt haben, wissen Unternehmen nicht einmal, wie viel Open-Source-Code sie einsetzen. Diese Wut führt sie (hoffentlich) dazu, sich intensiv weiterzubilden und Open-Source-Projekte zu erfassen. So wird ihnen klarer, wie zentral OSS für ihr Unternehmen ist.

• Verhandeln: In dieser Phase beginnen Unternehmen, mit der OSS-Community in den Dialog zu treten und Kontakt aufzunehmen. Oft nutzen sie dabei das Wissen, das durch die bisherige Ad-hoc-Beteiligung entstanden ist, und richten diese Beteiligung zunehmend an einer einheitlichen Strategie aus.

• Depression: In dieser Phase wird es ernst: Andere Bereiche des Unternehmens erkennen nun den Wert der OSPO. Das sollte doch großartig sein, oder? Leider wird auch in dieser Phase klar, dass OSS-Abhängigkeiten ein Risiko für das gesamte Unternehmen darstellen – insbesondere, wenn man Sicherheitslücken berücksichtigt.

• Akzeptanz: Wer vollständig akzeptiert, dass wir in einem Open-Source-Ökosystem leben, muss lernen, darin eine Führungsrolle zu übernehmen und die OSPO nicht nur als Kompetenzzentrum für offene Ökosysteme, sondern auch als Kompetenzzentrum für Sicherheit zu begreifen.

Gut, das ist vielleicht etwas weit hergeholt. Doch der Punkt ist: Open Source ist gekommen, um zu bleiben. Open Source spielt eine sehr wichtige Rolle bei der Entwicklung und Wartung der überwiegenden Mehrheit aller Software – insbesondere jener, die wir alle tagtäglich nutzen. Open Source bedeutet, der Community einen Teil der Kontrolle zu überlassen – im Gegenzug für höhere Qualität und geringere Betriebskosten. Unternehmen, die diese Tatsache akzeptieren und beginnen, in dieser Community eine Führungsrolle zu übernehmen, werden zu Marktführern. Und Sicherheit ist dabei ein zentraler Faktor.

Wie können OSPOs ihre Rolle also wirksam ausfüllen – nicht nur als Fürsprecher für Offenheit, sondern auch als Sicherheitsbotschafter? Zunächst, indem sie Sicherheitsexpertise in ihr Team holen. Stellen Sie eine Sicherheitsfachkraft ein, die mit den Herausforderungen der Software-Lieferkette vertraut ist. Die Beteiligung an der „End User“-Arbeitsgruppe der Open Source Security Foundation kann eine Möglichkeit sein, sich in einem geschützten Rahmen mit ähnlichen Unternehmen auszutauschen.

Ein guter Einstieg sind einige kürzlich von der Open Source Security Foundation (OpenSSF) veröffentlichte Materialien.

• Kompakter Leitfaden zur Entwicklung sicherer Software

• Kompakter Leitfaden zur Bewertung von Open-Source-Software

• Leitfaden zu Best Practices für NPM

Alle diese OpenSSF-Ressourcen helfen dabei, sich mit schwierigen Fragen rund um Open-Source-Sicherheit auseinanderzusetzen. Wenn Sie eine OSPO oder eine ähnliche Funktion in einem Unternehmen beliebiger Größe aufbauen, werden Ihnen einige der in diesen Leitfäden behandelten Themen sofort vertraut sein. Ihr Unternehmen verwendet wahrscheinlich npm. Ihr Code liegt in Systemen zur Quellcodeverwaltung wie GitHub. Sie verwenden Open-Source-Software aus verschiedenen Quellen mit unterschiedlichen Lizenzen und Herkunftsgeschichten. All diese Themen werden in den Leitfäden behandelt; weiterführende Informationen sind verlinkt.

Anschließend sollten OSPOs Sicherheitsexpertinnen und -experten einstellen oder hinzuziehen, um diese Herausforderungen proaktiv anzugehen. Denken Sie im Entwicklungs-, Build- und Bereitstellungsprozess an eine Software-Stückliste (SBOM). Liran Tal hat einen hervorragenden Blogbeitrag zu SBOMs, der Ihnen den Einstieg erleichtert.

Nebenbei bemerkt: Es ist interessant und erfreulich, US-Gesetze zu sehen, die Open-Source-Software sichern sollen, die bei der Entwicklung und beim Betrieb staatlicher Dienste eingesetzt wird und die die Einrichtung von OSPOs in Regierungsbehörden vorsehen.

Auf ein sicheres (und offenes) Jahr 2023