Warum Open-Source-Governance entscheidend für die Sicherheit ist

Was ist Open-Source-Governance?

Open-Source-Governance umfasst die anerkannten Regeln und Gepflogenheiten, die ein Open-Source-Projekt leiten. Laut OpenSource.com müssen folgende Fragen beantwortet werden, um Governance-Richtlinien festzulegen: 

• Welche Rollen können Mitwirkende im Projekt übernehmen?

• Welche Qualifikationen, Pflichten, Privilegien und Befugnisse sind mit den jeweiligen Rollen verbunden?

• Wie werden Personen Rollen zugewiesen (und wieder aus ihnen entfernt)?

• Wie können Rollendefinitionen geändert werden?

• Welche gemeinsamen Richtlinien und Verfahren gelten für das Projekt?

Sobald die Rollen innerhalb des Projekts definiert sind, in der Regel auf Grundlage der Aktivitäten der einzelnen Entwicklerinnen und Entwickler, kann die Governance auf Open-Source-Projekte angewendet werden.

6 verschiedene Governance-Modelle

Die Regeln eines Open-Source-Projekts festzulegen und Rollen zuzuweisen, wird als Governance-Modell bezeichnet. Laut Red Hat gibt es sechs Governance-Modelle.

1. Do-ocracy: Dieses Governance-Modell folgt der Idee, dass die Entwicklerinnen und Entwickler, die die Arbeit erledigen, auch die Entscheidungen treffen sollten. In diesem Fall spielt Peer-Review eine wichtige Rolle bei der Governance. Für Entwicklerinnen und Entwickler, die mehr Anleitung benötigen, kann dieses Modell jedoch schwierig sein.

2. Founder-Leader: Dieses Open-Source-Governance-Modell kommt am häufigsten bei neuen Projekten oder Projekten mit nur wenigen Mitwirkenden zum Einsatz. In diesem Softwaremodell ist die Governance klar geregelt und liegt in der Regel bei der ursprünglichen Person oder dem Entwicklungsteam. Leider kann dieses Modell zu einer Open-Source-Diktatur führen, in der die Gründerin oder der Gründer die Governance während des gesamten Software-Lebenszyklus bestimmt.

3. Selbsternannter Rat oder Vorstand: Bei diesem Governance-Modell für Open-Source-Software wird ein Führungsgremium eingerichtet, das die Entwicklungsschritte des Projekts überwacht. Ein Nachteil dieses Modells ist, dass das Führungsgremium die Stimmen und die Mitwirkung des übrigen Teams ausschließen könnte.

4. Wahlmodell: Bei diesem Modell bestimmt die Community ihre Governance durch Wahlen. Es ist ein beliebtes Modell für Projekte, bei denen viele Entwicklerinnen und Entwickler mit ähnlichen Fähigkeiten und Rollen aus der Community mitwirken. Bei der Entscheidungsfindung ist es zwar das gerechteste Modell, doch kann es auch zusätzliche Verantwortungsebenen und Ablenkungen sowie interne Konflikte mit sich bringen, wenn Community-Mitglieder um Führungsrollen konkurrieren.

5. Unternehmensgestützt: Bei diesem Software-Governance-Modell übernehmen Unternehmen oder Branchen die Verbreitung der Software unter Open-Source-Lizenzvereinbarungen. Das bietet zwar Kontrolle über die Softwareentwicklung, schränkt aber externe Beiträge ein, die für Open-Source-Projekte typisch sind.

6. Stiftungsgetragen: Dieses Modell wird von einer gemeinnützigen Organisation verwaltet, und die Governance wird oft streng durch eine einzelne Struktur kontrolliert. Das liegt an den Anforderungen, die mit dem Status dieser Organisationen verbunden sind.

So werden Führungsrollen formalisiert

Open-Source-Softwareprojekte sind auf Zusammenarbeit ausgelegt, doch die Governance gibt die Richtung vor. Führungskräfte leiten das Projekt, sorgen dafür, dass Fristen eingehalten und Richtlinien und Leitlinien befolgt werden.

Jedes Governance-Modell hat eigene Verfahren zur Auswahl der Führung. Dazu gehören:

• Do-ocracy: Führung entsteht durch praktische Arbeit. Je mehr Beiträge einer Entwicklerin oder eines Entwicklers zu einem Projekt angenommen werden, desto größer wird ihr oder sein Einfluss in der Projekt-Community.

• Founder-Leader: Die Führung übernehmen meist ganz selbstverständlich diejenigen, die das Projekt ins Leben gerufen haben.

• Selbsternannt: Bei ausgereifteren und langfristig bestehenden Open-Source-Projekten gibt es oft bereits eine Dokumentation der Governance-Verfahren. Entwicklerinnen und Entwickler müssen selbst die Initiative ergreifen und herausfinden, wie ihre Beiträge zu Führungsrollen führen können.

• Wahlmodell: Bei einem Wahlverfahren gibt es klar definierte Abläufe, die regeln, wie und wann gewählt wird und für welche Rollen. Wahlergebnisse sind in den Online-Dokumentationen zum Projekt leicht zu finden. Kandidatinnen und Kandidaten haben sich in der Regel bereits einen guten Ruf innerhalb der Community erarbeitet, bevor sie sich um eine Führungsposition bewerben.

• Unternehmensgestützt: Die Governance geht vom Ursprungsunternehmen aus, daher besteht eine Verbindung zwischen der Führung und diesem Unternehmen.

• Stiftungsgetragen: Die Governance geht entweder direkt von der Stiftung oder von einem selbsternannten Rat aus.

Alle Projektmitwirkenden sollten die Möglichkeit haben, eine Governance-Rolle zu übernehmen, wenn sie das möchten. Zunächst müssen Entwicklerinnen und Entwickler jedoch dem Projekt beitreten. Interessierte sollten dafür eine Projekt-Mailingliste abonnieren, die auf GitHub und den offiziellen Projekt-Websites zu finden ist.

Sobald sie anfangen, zu einem Projekt beizutragen, müssen sie ihre Beiträge dokumentieren. Dafür eignen sich Tools wie das Open Source Contributions Log. Die Dokumentation der Beiträge belegt die geleistete Arbeit für alle, die innerhalb der Open-Source-Governance eine Führungsrolle übernehmen möchten.

Rollen in der Open-Source-Governance

In der Governance von Open-Source-Software gibt es formelle Rollen für Projektmitwirkende. Zu den bekanntesten gehören:

Maintainer: Das kann jemand sein, der viel Code für das Open-Source-Projekt geschrieben oder Dokumentation dazu erstellt hat – oder sogar eine Person, die sich für das Projekt einsetzt. Diese mitwirkende Person fühlt sich für die Gesamtausrichtung des Projekts verantwortlich und tut, was nötig ist, um es voranzubringen.

Mitwirkende: Jede Person, die sich am Projekt beteiligt, sei es durch Kommentare zu Problemen oder durch das Schreiben von Code. Wer dem Projekt etwas Wertvolles beisteuert, übernimmt die Rolle eines Mitwirkenden.

Committer: Eine Person mit besonderen Commit-Berechtigungen, die sich dauerhaft und intensiv für das Projekt engagiert hat.

4 Möglichkeiten, Ihr Open-Source-Projekt zu schützen

Open-Source-Software ist attraktiv, weil alle mitwirken können. Gleichzeitig besteht das größte Risiko bei Open-Source-Projekten darin, dass jede Person Beiträge leisten kann. Zur Open-Source-Governance gehört es daher, Maßnahmen zum Schutz des Projekts vor Bedrohungen zu ergreifen. Zu den Schritten, mit denen sich Risiken vermeiden lassen, gehören:

1. Legen Sie projektinterne Sicherheitsrichtlinien fest, darunter Vorgaben für die Überwachung von Nutzerinnen und Nutzern sowie Mitwirkenden oder für die Projektdokumentation. Eine Person mit Führungsrolle sollte befugt sein, diese Richtlinien durchzusetzen. Maintainer sind dafür gut geeignet.

2. Schwachstellen testen, nachverfolgen und beheben. Mit Tools zur Software-Composition-Analyse (SCA) können Entwicklerinnen und Entwickler Open-Source-Komponenten in Software analysieren und verwalten. SCA-Tools prüfen beispielsweise die Lizenzierung und bewerten das Schwachstellenrisiko. 

3. Beschränken Sie, wer Pull Requests erstellen darf, und prüfen Sie diese, bevor Sie Maßnahmen ergreifen. Pull Requests lassen sich auch mit SCA- oder Static Application Security Testing (SAST)-Tools auf Schwachstellen untersuchen.

4. Prüfen Sie Mitwirkende, bevor sie dem Projekt beitreten, und gewähren Sie nur vertrauenswürdigen Nutzenden Zugriff.

Wann Governance eingeführt werden sollte

Governance sollte in jedem Open-Source-Projekt so früh wie möglich eingeführt werden. Je früher die Dokumentation erstellt wird, desto einfacher lassen sich Erwartungen und Ziele festlegen. Eine frühzeitige Governance sorgt außerdem für klar definierte Rollen. Wird das Projekt von einem Unternehmen oder einer Stiftung getragen, sollten interne Gespräche vor dem Projektstart stattfinden. So sind die Abläufe klar und es gibt einen bekannten Weg für die weitere Entwicklung des Projekts.

Beiträge von Unternehmen und Governance-Modelle

Open-Source-Software wird von vielen unterschiedlichen Nutzenden eingesetzt. Da verschiedene Unternehmen jeweils eigene Anforderungen an die Software haben, können ihre Beiträge den Projektumfang verändern. Unternehmen setzen mitunter auch bezahlte Entwicklerinnen und Entwickler ein, die bei bestimmten Projekten als Mitwirkende tätig werden.

Diese Beiträge sollten wie alle anderen Beiträge behandelt werden. Die Governance richtet sich weiterhin nach dem Wert der Beiträge und dem Engagement.

Erste Schritte mit Open-Source-Governance

Mehr als 90 % der proprietären Software verwenden Open-Source-Komponenten. Daher sollte Open-Source-Governance für IT-Abteilungen und Führungskräfte in jedem Unternehmen, das Code als Open Source veröffentlicht, Priorität haben. Richtlinien für Open-Source-Governance, Projektmitwirkende und Führung sollten klar definiert und gut kommuniziert werden. Alle, die an der Entwicklung von Open-Source-Software beteiligt sind, sollten ihre Rollen bei der Mitwirkung an Projekten kennen.

Die Richtlinie zur Open-Source-Governance bietet Lösungen für mögliche Probleme – von Sicherheitsrisiken bis hin zu Betriebsrisiken. Fehlende Governance kann den Softwareentwicklungszyklus verlangsamen, Releases verzögern oder nach der Produkteinführung Nachbesserungen erforderlich machen.

Governance-Modelle helfen, mögliche rechtliche Probleme anzugehen. So sollte die Governance-Richtlinie einer Organisation ein SCA-Tool umfassen, mit dem sich mögliche Schwachstellen und Lizenzprobleme in Abhängigkeiten erkennen lassen. Snyk Open Source bietet Einblick in die von Ihnen verwendeten Open-Source-Pakete sowie in die Lizenzkonformität und das Abhängigkeitsmanagement.