Sichere Entwicklung von FOSS-Komponenten

Für Entwickler und Maintainer von FOSS-Komponenten bedeutet der risikobasierte Ansatz des CRA vor allem, das Risikomanagement nachgelagerter Nutzer zu ermöglichen, statt selbst direkte regulatorische Verantwortung zu übernehmen.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat die Technische Richtlinie TR-03185-2 (Secure Software Lifecycle for Open Source Software) veröffentlicht, einen praxisnahen Referenzrahmen dafür, wie sich Open-Source-Softwareentwicklung unter Sicherheitsgesichtspunkten gestalten lässt. Die folgenden Grundsätze bauen darauf auf.

Der risikobasierte Ansatz ist die zentrale Triebfeder des CRA. Statt starre Einheitskontrollen vorzuschreiben, sollte die Analyse ergebnisorientierte Kriterien heranziehen, deren Umsetzung sich richtet nach:

Security by Design verlangt, dass Cybersicherheitsaspekte über den gesamten Software-Lebenszyklus hinweg verankert sind. In einem CRA-konformen, risikobasierten Modell ist Sicherheit keine separate Tätigkeit, sondern ein kontinuierlicher und verhältnismäßiger Prozess, in dem jede Phase zur Gesamtresilienz einer FOSS-Komponente beiträgt und die Compliance-Pflichten nachgelagerter Nutzer unterstützt.

In Open-Source-Ökosystemen dienen Governance-Mechanismen oft als wichtigste Instrumente zur Risikominderung. Transparenz, Dokumentation und Community-Prozesse sind nicht bloß administrative Merkmale, sondern zentrale Wegbereiter der Sicherheit. Vier Elemente sind entscheidend:

Diese Maßnahmen verringern systemische Risiken, indem sie die Rechenschaftspflicht stärken und nachgelagerten Nutzern ermöglichen, die Vertrauenswürdigkeit eines Projekts zu beurteilen.

Open-Source-Komponenten sind tief in moderne Software-Lieferketten eingebettet. Ein risikobasierter Ansatz für die FOSS-Entwicklung muss daher nicht nur Risiken auf Projektebene berücksichtigen, sondern auch systemische Risiken, die sich durch Wiederverwendung und Weiterverteilung ausbreiten. Die Resilienz der Lieferkette wird gestärkt, indem Folgendes gefördert wird:

Solche Praktiken verbessern die Fähigkeit nachgelagerter Integratoren, einschließlich kleiner und mittlerer Unternehmen, Risikobewertungen durchzuführen und regulatorische oder vertragliche Pflichten zu erfüllen.

Die Sicherheit eines Endprodukts ist untrennbar mit der Integrität seiner vorgelagerten Komponenten verbunden. Mit der Umsetzung des CRA steht die Branche vor einer entscheidenden Herausforderung: Wie lässt sich die Sicherheit der Millionen von Open-Source-Abhängigkeiten, die das Rückgrat der globalen Infrastruktur bilden, überprüfen, ohne das kollaborative Modell zu ersticken, das sie hervorgebracht hat?

Die tragfähigste Lösung liegt in Artikel 25, der einen Rahmen für freiwillige Sicherheitsattestierungen beschreibt. Durch den Wechsel von reaktivem Patchen zu proaktiver, standardisierter Transparenz können gemeinnützige Stewards gestufte, risikobasierte Zusicherungen gegen eine Vergütung bereitstellen, die transparente Betriebskosten deckt. So wird die Einhaltung von Vorschriften zu einem nachhaltigen Motor für die Resilienz der Lieferkette. Drei Säulen tragen diese Resilienz:

Wer sich verpflichtet, ein Produkt während seiner gesamten Nutzungsdauer zu warten und abzusichern, übernimmt fortlaufende Verantwortung für alle enthaltenen Komponenten, einschließlich Open-Source-Bibliotheken von Dritten. Open-Source-Komponenten entwickeln sich unabhängig weiter: Schwachstellen können Jahre nach der Integration auftauchen, Maintainer können sich zurückziehen, Release-Zyklen können sich verlangsamen. Ohne strukturierten Überblick über Abhängigkeiten, kontinuierliche Überwachung, disziplinierte Versionskontrolle und dokumentierte Update-Richtlinien laufen Organisationen Gefahr, unkontrollierte technische Schulden und latente Schwachstellen in der Lieferkette zu übernehmen. Konkrete Maßnahmen:

Durch die Kombination aus Transparenz (SBOMs), strukturierter Risikobewertung, kontinuierlicher Überwachung und Mitwirkung im Upstream können Hersteller Open-Source-Abhängigkeiten von einem unkontrollierten Risiko in ein strategisch gesteuertes Gut verwandeln, das langfristige Sicherheit, Compliance und Vertrauen unterstützt.

Nach dem CRA müssen Hersteller Schwachstellen während des gesamten Produktlebenszyklus zeitnah und strukturiert erkennen, managen und beheben. Open-Source-Projekte als solche werden zwar nicht direkt reguliert, ihre Praktiken beeinflussen jedoch erheblich, ob nachgelagerte Hersteller und KMU die Anforderungen erfüllen können. In einem risikobasierten Modell beschränkt sich die Schwachstellenbehandlung nicht auf reaktives Patchen. Sie umfasst:

Kleinere Projekte verfügen nicht unbedingt über die Ressourcen großer kommerzieller Anbieter, sollten aber dennoch grundlegende Praktiken umsetzen, die es nachgelagerten Integratoren ermöglichen, Risiken wirksam zu bewerten und zu steuern.

Um dem Verhältnismäßigkeitsprinzip des CRA Rechnung zu tragen, lassen sich die Praktiken der Schwachstellenbehandlung in drei Reifegrade gliedern.

Für KMU, die FOSS-Komponenten in Produkte mit digitalen Elementen integrieren, wirken sich die Praktiken der Schwachstellenbehandlung vorgelagerter Projekte unmittelbar auf ihre eigene Compliance aus. KMU sollten daher prüfen: