Manifest für die Nutzung von Open Source

Angelehnt an das vor über 20 Jahren begründete Agile Manifest, das trotz seiner Einfachheit einen tief greifenden Einfluss auf jeden Aspekt der Softwareentwicklung hat, wurde jetzt das Open Source Consumption Manifesto (OSCM) vorgestellt. Es zielt darauf ab, die Lücken im Agilen Manifest zu schließen. Es soll aber auch ein lebendiges Dokument sein; eine gemeinsame Basis um viele verschiedene Ansätze zu vereinen. Wie das Agile Manifest umfasst auch das OSCM eine Reihe von Grundwerten. In Partnerschaft mit diesen Werten wurden fünfzehn Leitprinzipien aufgestellt. Das Ziel: die Nutzung von Open Source in jeder Softwareorganisation zu verbessern.

Den ersten Vorschlag zum Open Source Consumption Manifesto (OSCM) (Version 0.0, public draft) finden Sie auf dieser GitHub-Seite. Im Aufruf sich dem OSCM anzuschließen sind die Hintergründe und Ziele des Manifests genauer erläutert. Auch die vier Autoren - Brian Fox, Jeff Wayman, Jonathan Meadows und Christopher Robinson - stellen sich dort vor.

Hier der von deepL ins deutsche übersetzte erste Vorschlag (public draft) zum OSCM (Quelle):

Das Manifest für den Open-Source-Konsum

v 0.0 (öffentlicher Entwurf)

Open Source ist gleichzeitig ein öffentliches Gut und ein Gut der Allgemeinheit.

Open Source ist keiner Person oder Organisation etwas schuldig.

Die Verfügbarkeit, der Wert und die Qualität von Open Source sind nicht garantiert.

Als Nutzer von Open Source sind wir dafür verantwortlich, welche Open Source wir nutzen, wie wir sie nutzen und wie wir mit dem Risiko umgehen, das mit dieser Nutzung verbunden ist.

Wir bemühen uns...

die sichere Nutzung von Open-Source-Komponenten zu priorisieren
die Erfahrung der Entwickler zu berücksichtigen und auf sie Rücksicht zu nehmen
auf iterativen, richtlinienbasierten Grundlagen und bewährten Verfahren aufzubauen.

Wir rufen kommerzielle und nicht-kommerzielle Entwicklungsorganisationen auf,...

Die Nutzung von Open-Source-Software als entscheidend für den Aufbau einer sicheren Software-Lieferkette zu akzeptieren.
Sicherzustellen, dass die Nutzung von Open-Source-Software gegen ein definiertes Risikoprofil abgewogen wird, das von der Risikotoleranz, dem regulatorischen Kontext usw. abhängen kann.
Erkennen Sie potenzielle Risiken im Zusammenhang mit der Nutzung von Open-Source-Software, einschließlich Schwachstellen, bösartiger Software und der Auswahl von Komponenten.
Anerkennen, dass nicht alle Schwachstellen aktiv kuratiert werden und dass die Bewertungssysteme (wie CVSS für CVEs) ein nachlaufender Indikator sein können.
Verbessern Sie die Nutzung von Open Source durch Prüf- und Quarantänefunktionen für Komponenten, die mit bekannten Sicherheitslücken und bösartigen Paketen übereinstimmen.
Konzentrieren Sie sich auf Tools und Prozesse, die die Fähigkeiten von Entwicklungsteams/Entwicklern unterstützen und erweitern, um eine fundierte Bewertung von verbrauchter Open-Source-Software vorzunehmen.
Schutz von Softwareunternehmen und Entwicklungsteams vor bösartiger Software durch Unterstützung etablierter Sicherheitsmodelle (z. B. SLSA, S2C2F usw.) und anschließende Anwendung dieser Modelle auf die Nutzung von Open Source.
Festlegung einer Richtlinie für die Nutzung von Open Source und regelmäßige Überprüfung der Risikotoleranz, der Auswirkungen auf die Entwicklungsteams und anderer Ziele.
Zusammenarbeit mit Teams, um sinnvolle Kontrollpunkte für die Nutzung von Open Source während des SDLC zu entwerfen und zu implementieren.
Sicherstellen, dass der Lebenszyklus der genutzten Open-Source-Komponenten angemessen verwaltet wird und dass die nutzenden Entwicklerteams die neuesten, LTS- oder anderweitig "unterstützten" Versionen verwenden, sofern dies möglich ist.
Engagieren Sie sich mit den Upstream-Entwicklern der genutzten Komponenten, insbesondere bei Komponenten, die einen kritischen Teil Ihres Projekts bilden, um Probleme zu melden, Fehler zu beheben, die Entwicklung zu unterstützen usw.
Einführung von Werkzeugen, bewährten Praktiken und Prozessen, um (1) die Sicherheit der genutzten Open-Source-Software kontinuierlich zu verfolgen, zu überwachen und zu verbessern, (2) effektiver auf Sicherheitsprobleme zu reagieren und (3) die Risikokommunikation mit Kunden/Partnern über bestehende Kanäle zu erleichtern (z. B. CVD der CISA, VEX usw.).

Unterschriften:

Brian Fox, Sonatype

Jon Meadows, Vorsitzender der OpenSSF-Arbeitsgruppe für Endbenutzer

Christopher "Crob" Robinson, Vorsitzender des OpenSSF TAC