Open-Source-Softwareentwicklung: Der Leitfaden 2026 für Produktteams

Redaktion YuSMP Group Redaktionsteam, YuSMP Group

Open-Source-Softwareentwicklung ist still und leise zum Standard geworden: Fast jedes kommerzielle Produkt wird heute mit Frameworks, Bibliotheken und Tools ausgeliefert, die andere öffentlich geschrieben haben. Damit ist Open Source eine Lieferkette und kein Randthema. 2026 hat sich das Risikobild gleich zweifach verändert: Der OSSRA-Bericht 2026 von Black Duck zeigte, dass sich die durchschnittliche Zahl bekannter Schwachstellen pro Codebasis innerhalb eines Jahres mehr als verdoppelt hat, und der EU Cyber Resilience Act verpflichtet Anbieter seit dem 11. September 2026, aktiv ausgenutzte Schwachstellen zu melden.

Die meisten Teams, mit denen wir arbeiten, fangen nicht bei null an: Individuelle Softwareentwicklung bedeutet heute, Open-Source-Frameworks zusammenzusetzen und zu erweitern und dann die 10–30 % des Codes zu schreiben, die wirklich Ihnen gehören. Der Open-Source-Anteil entscheidet darüber, wie schnell Sie liefern, wie sicher Sie sind und welche rechtlichen Pflichten Sie übernehmen. Er verdient deshalb dieselbe Engineering-Disziplin wie Ihr eigener Code.

Dieser Leitfaden richtet sich an CTOs, Gründer und Product Owner in den USA und der EU. Er erklärt, wie Open Source entsteht und gesteuert wird, was Unternehmen bei Open-Source-Softwareentwicklungsdiensten einkaufen, wie sich Lizenzen unterscheiden, was die aktuellen Sicherheitsdaten zeigen, was der Cyber Resilience Act verlangt, was Open Source über die gesamte Lebensdauer wirklich kostet und wie Sie einen Entwicklungspartner wählen, der Sie nicht mit einem Fork allein lässt.

Was ist Open-Source-Softwareentwicklung?

Open-Source-Softwareentwicklung ist die Praxis, Software zu entwickeln, deren Quellcode unter einer Lizenz veröffentlicht wird, die es jedem erlaubt, ihn zu nutzen, zu untersuchen, zu ändern und weiterzugeben. Die Arbeit geschieht öffentlich: Der Code liegt in gemeinsamen Repositories, Änderungen kommen als Pull Requests von vielen Beitragenden, und Maintainer prüfen und veröffentlichen sie offen.

Als Open Source gilt eine Lizenz nur, wenn sie die Open Source Definition der Open Source Initiative (OSI) erfüllt. In der Praxis bedeutet das die vier Freiheiten, die zuerst die Freie-Software-Bewegung formuliert hat: die Freiheit, das Programm für jeden Zweck auszuführen, seine Funktionsweise zu untersuchen und zu ändern, Kopien weiterzugeben und veränderte Versionen zu verbreiten. Eine Lizenz, die kommerzielle Nutzung verbietet, den Nutzerkreis einschränkt oder konkurrierende Dienste untersagt, ist kein Open Source – auch wenn der Code öffentlich ist.

Für ein Unternehmen hat Open-Source-Softwareentwicklung zwei Seiten. Sie konsumieren Open Source, wenn Ihr Produkt von Linux, PostgreSQL, React, Kubernetes oder Tausenden kleinerer Pakete abhängt. Sie produzieren Open Source, wenn Ihre Engineers Korrekturen upstream einbringen, interne Tools veröffentlichen oder ein eigenes Projekt betreiben. Die meisten Unternehmen tun weit mehr vom Ersten als vom Zweiten – und dort liegt auch das meiste Risiko.

Open Source vs. freie Software vs. Source-Available

Open Source, freie Software und Source-Available stehen für unterschiedliche Versprechen, obwohl Sie in allen drei Fällen den Code lesen können.

• Freie Software betont die Freiheit der Nutzer als ethisches Prinzip und ist eng mit Copyleft-Lizenzen wie der GPL verbunden. Fast jede freie Software ist zugleich Open Source.
• Open Source betont die praktischen Vorteile offener Zusammenarbeit und umfasst sowohl permissive als auch Copyleft-Lizenzen, die von der OSI anerkannt sind.
• Source-Available-Software veröffentlicht den Code, schränkt aber die Nutzung ein, typischerweise durch ein Verbot konkurrierender gehosteter Dienste. Die Business Source License (BSL) und die Server Side Public License (SSPL) sind gängige Beispiele; keine von beiden ist OSI-anerkannt.

Kurze Geschichte: von der Kathedrale zum Basar

Open Source ist aus der Freie-Software-Bewegung hervorgegangen und wurde Ende der 1990er-Jahre zum Mainstream. Richard Stallman kündigte 1983 das GNU-Projekt an, um ein freies Betriebssystem zu bauen; die GPL folgte. Linus Torvalds veröffentlichte 1991 den Linux-Kernel, 1995 erschien der Apache HTTP Server. In seinem Essay The Cathedral and the Bazaar stellte Eric Raymond Software, die eine kleine geschlossene Gruppe baut (die Kathedrale), Software gegenüber, die viele Beitragende offen entwickeln (der Basar). Der Begriff Open Source wurde 1998 geprägt, im selben Jahr wurde die Open Source Initiative gegründet, um das Basar-Modell Unternehmen nahezubringen. Heute beherbergen Stiftungen wie die Linux Foundation, die Apache Software Foundation und die Eclipse Foundation Tausende Projekte, auf die Unternehmen angewiesen sind.

Die zentralen Prinzipien der Open-Source-Entwicklung

Open-Source-Entwicklung beruht auf sechs Arbeitsprinzipien, die erklären, warum das Modell über Unternehmens- und Zeitzonengrenzen hinweg skaliert. Es lohnt sich, sie auch in geschlossenen Codebasen zu übernehmen – dort spricht man von Inner Source.

• Transparenz. Code, Issues, Roadmaps und Designdiskussionen sind öffentlich, sodass jeder sieht, was sich ändert und warum.
• Peer Review. Jede Änderung wird vor dem Merge geprüft. Mehr Augen finden mehr Fehler – aber nur, wenn tatsächlich jemand hinschaut.
• Dezentrale, leistungsbasierte Zusammenarbeit. Beitragende gewinnen Einfluss durch die Qualität ihrer Arbeit, nicht durch Arbeitgeber oder Titel.
• Früh und oft veröffentlichen. Kleine, häufige Releases bringen Korrekturen schnell zu den Nutzern und halten Feedbackschleifen kurz.
• Wiederverwendung als Standard. Lizenzen erlauben es, auf bestehender Arbeit aufzubauen, statt dieselben Komponenten neu zu erfinden.
• Gemeinschaftliche Governance. Schriftliche Regeln legen fest, wer mergen darf, wie Entscheidungen fallen und wie Konflikte gelöst werden.

Wie funktioniert Open-Source-Softwareentwicklung?

Open-Source-Softwareentwicklung folgt einem öffentlichen, wiederholbaren Lebenszyklus: Ein Projekt startet, erhält eine Lizenz und Beitragsregeln, sammelt Arbeit als Issues, nimmt Änderungen über geprüfte Pull Requests an, testet sie automatisch, liefert versionierte Releases aus und behandelt Sicherheitsmeldungen vertraulich. Die Schritte sind dieselben, ob ein Projekt drei oder dreitausend Beitragende hat.

1. Initiierung. Ein Projekt beginnt als neue Idee, als Fork eines bestehenden Projekts oder als interner Code, den ein Unternehmen öffnet. Interner Code braucht vorher eine Prüfung: Secrets, Kundendaten und Drittcode mit inkompatiblen Lizenzen müssen entfernt werden.
2. Öffentliches Repository und Spielregeln. Das Repository erhält eine Lizenzdatei, eine README, einen CONTRIBUTING-Leitfaden, der erklärt, wie Änderungen vorgeschlagen werden, und einen CODE_OF_CONDUCT mit Verhaltenserwartungen.
3. Issues und Roadmap. Bugs, Feature-Wünsche und Designvorschläge werden als öffentliche Issues verfolgt. Labels wie good first issue helfen Neulingen beim Einstieg.
4. Pull Requests und Code Review. Beitragende forken oder branchen den Code, nehmen eine Änderung vor und eröffnen einen Pull Request. Maintainer prüfen ihn, fordern Anpassungen an und mergen ihn, wenn er bereit ist. Unser Leitfaden zu Pull Requests in der Softwareentwicklung beschreibt diesen Schritt ausführlich.
5. Continuous Integration. Jeder Pull Request durchläuft automatisierte Tests, Linter und Sicherheitsprüfungen, bevor ein Mensch ihn ansieht. So bleibt die Qualität über Hunderte Beitragende hinweg konstant.
6. Releases und semantische Versionierung. Maintainer kennzeichnen Releases nach Semantic Versioning (MAJOR.MINOR.PATCH), damit Nutzer auf einen Blick erkennen, ob ein Upgrade ihren Code brechen kann.
7. Umgang mit Sicherheitslücken. Eine SECURITY.md-Datei erklärt Forschenden, wie sie Schwachstellen vertraulich melden, damit Korrekturen erscheinen, bevor Details öffentlich werden.

Governance-Modelle

Die Governance legt fest, wer in einem Open-Source-Projekt das letzte Wort hat. Für Käufer ist sie wichtig, weil sie vorhersagt, wie stabil das Projekt in fünf Jahren sein wird. Vier Modelle decken die meisten Projekte ab:

Wer schreibt eigentlich Open Source?

Ein großer Teil der Open Source, auf die Unternehmen angewiesen sind, wird von bezahlten Engineers geschrieben, nicht nur von Freiwilligen. Große Projekte wie Linux und Kubernetes werden von Beitragenden vorangetrieben, die bei Technologieunternehmen angestellt sind, während viele kleine, aber kritische Bibliotheken noch immer von ein oder zwei unbezahlten Personen gepflegt werden. Größere Unternehmen koordinieren diese Arbeit über ein Open Source Program Office (OSPO): ein kleines Team, das Richtlinien für Nutzung, Beiträge und Veröffentlichung festlegt, die Lizenz-Compliance überwacht und entscheidet, welche Upstream-Projekte Engineering-Zeit verdienen.

Open-Source-Softwareentwicklungsdienste: Was Unternehmen tatsächlich einkaufen

Open-Source-Softwareentwicklungsdienste (open source software development services) sind Engineering-Leistungen, die einem Unternehmen helfen, auf Open-Source-Code aufzubauen, ihn zu erweitern, abzusichern oder zu veröffentlichen. Kaum ein Käufer will Open Source um ihrer selbst willen; er will ein Produkt schneller und günstiger, ohne versteckte rechtliche oder sicherheitstechnische Altlasten. Die häufigsten Aufträge sind:

• Produkte auf Open-Source-Stacks bauen – Web-, Mobile- und Datenplattformen aus bewährten Frameworks mit individueller Geschäftslogik.
• Open Source anpassen und erweitern – Module für Odoo, Identity-Flows in Keycloak, Kubernetes-Operatoren, Integrationen für Headless-CMS.
• Internen Code als Open Source veröffentlichen – Codebasis bereinigen, Lizenz wählen, Dokumentation schreiben, Governance aufsetzen.
• OSPO-Aufbau – Richtlinien, Freigabeprozesse und Tooling für große Organisationen.
• Lizenz- und SBOM-Audits – jede ausgelieferte Komponente, ihre Lizenz und ihre bekannten Schwachstellen ermitteln.
• Langfristige Wartung von Forks – Sicherheits-Patches, Upstream-Abgleich und Upgrade-Planung.
• Migration weg von proprietären Plattformen – teure lizenzierte Software durch offene Alternativen ersetzen, ohne Daten und Integrationen zu verlieren.

Anwendungsfälle: typische Anwendungen auf Open-Source-Basis

Open Source passt zu fast jeder Anwendungskategorie; die Wahl des Basisprojekts entscheidet, wie viel individueller Code noch zu schreiben ist. Typische Muster aus unseren Projekten:

• ERP und CRM auf Odoo oder SuiteCRM, erweitert um branchenspezifische Module und Integrationen.
• Webanwendungen auf React oder Next.js mit Node.js- oder Python-Backends und PostgreSQL.
• Datenplattformen auf Apache Kafka, Apache Spark und offenen Tabellenformaten für Streaming und Analytics.
• Identität und Zugriff auf Keycloak für Single Sign-on über interne und kundenseitige Anwendungen.
• KI-Funktionen auf Open-Weight-Modellen, die auf eigener Infrastruktur laufen, wenn Datenresidenz oder Kosten gehostete APIs ausschließen.

Vorteile von Open Source für die Softwareentwicklung

Die wichtigsten Vorteile von Open Source für die Softwareentwicklung sind geringere Lizenzkosten, schnellere Lieferung und Freiheit vom Vendor-Lock-in, gefolgt von Transparenz, einem größeren Talentpool und schnellerer Innovation. Kostenlos heißt frei von Lizenzgebühren, nicht frei von Kosten: Die Einsparungen sind nur real, wenn die Wartung geplant ist.

• Keine Lizenzgebühren. Sie zahlen für Engineering, nicht für Plätze oder Kerne. IBM Think nennt Marktschätzungen von 41,83 Mrd. US-Dollar 2024 und 48,92 Mrd. US-Dollar 2025 für den Markt für Open-Source-Dienstleistungen, ein jährliches Wachstum von 16,9 % – Geld, das in Dienstleistungen statt in Lizenzen fließt.
• Geschwindigkeit. Ausgereifte Frameworks decken Authentifizierung, Routing, Datenzugriff und UI-Komponenten ab, sodass Teams sich auf die Funktionen konzentrieren, für die Kunden zahlen.
• Kein Vendor-Lock-in. Erhöht ein Anbieter die Preise oder verschwindet er, können Sie oder ein anderes Team den Code weiter betreiben und ändern.
• Transparenz und Prüfbarkeit. Sie können den Code lesen, der Ihre Daten verarbeitet – wichtig für Sicherheitsprüfungen und regulierte Branchen.
• Talentpool. Engineers kennen populäre Open-Source-Stacks bereits, was Einstellung und Einarbeitung verkürzt.
• Innovation. Neue Ideen in Cloud-native-Infrastruktur, Daten-Tooling und KI entstehen meist zuerst als Open-Source-Projekte.

Der Wert ist kaum zu überschätzen. Ein Working Paper der Harvard Business School von Hoffmann, Nagle und Zhou aus dem Jahr 2024 schätzt den nachfrageseitigen Wert weit verbreiteter Open Source auf rund 8,8 Billionen US-Dollar und kommt zu dem Schluss, dass Unternehmen ohne Open Source etwa 3,5-mal mehr für Software ausgeben würden.

Open Source vs. proprietäre Software im Vergleich

Open Source gewinnt bei Kosten, Flexibilität und Lock-in; proprietäre Software gewinnt bei paketiertem Support und einem einzigen verantwortlichen Anbieter. Die Tabelle vergleicht beide nach den Kriterien, die meist über den Kauf entscheiden.

Fazit: Entscheiden Sie pro Komponente, nicht pro Projekt. Die meisten Produkte kombinieren beides, und die beste Architektur hält Standardschichten offen und kauft oder baut nur dort, wo es einen klaren Grund gibt. Unser Vergleich Individualsoftware vs. Standardsoftware wendet dieselbe Logik auf Produktebene an.

Open-Source-Lizenzen erklärt: Welche passt zu Ihrem Produkt?

Die richtige Open-Source-Lizenz hängt von einer Frage ab: Müssen Sie Ihren eigenen Code geschlossen halten, wenn Sie ihn ausliefern? Permissive Lizenzen erlauben das, schwache Copyleft-Lizenzen erlauben es unter Bedingungen, und starke Copyleft-Lizenzen in der Regel nicht.

Relizenzierung ist ein reales Geschäftsrisiko. Als HashiCorp Terraform 2023 auf die Business Source License umstellte, forkte die Community das Projekt als OpenTofu unter dem Dach der Linux Foundation, und viele Nutzer mussten entscheiden, welchem Zweig sie folgen. Projekte im Besitz eines einzelnen Anbieters können ihre Bedingungen ändern; stiftungsgetragene Projekte tun das selten.

Dieser Abschnitt ist eine allgemeine Information und keine Rechtsberatung. Ziehen Sie einen Rechtsbeistand hinzu, bevor Sie Software weitergeben, die Copyleft-Komponenten mit proprietärem Code kombiniert.

Ist Open-Source-Software sicher? Risiken und wie Sie sie steuern

Open-Source-Software ist so sicher wie Ihr Wartungsprozess. Öffentlicher Code ist nicht von Natur aus sicherer oder unsicherer als geschlossener Code; das Risiko entsteht durch Komponenten, die niemand verfolgt, aktualisiert oder ersetzt. Der OSSRA-Bericht 2026 von Black Duck auf Basis von 947 kommerziellen Codebasen aus 17 Branchen zeigt, wie verbreitet dieses Problem ist:

• 98 % der Codebasen enthielten Open Source.
• Die durchschnittliche Codebasis hatte 581 bekannte Schwachstellen, 107 % mehr als ein Jahr zuvor.
• 87 % enthielten mindestens eine Schwachstelle, 78 % Schwachstellen mit hohem Risiko und 44 % Probleme mit kritischem Risiko.
• 93 % enthielten Komponenten ohne Entwicklungsaktivität seit zwei oder mehr Jahren, 92 % Komponenten, die vier oder mehr Jahre veraltet waren. Nur 7 % der Teams nutzten die neuesten Versionen.
• 65 % der Organisationen erlebten im vergangenen Jahr einen Angriff auf die Software-Lieferkette, 66 % dieser Angriffe liefen über bösartige Pakete.

Angriffe auf die Software-Lieferkette

Ein Angriff auf die Software-Lieferkette kompromittiert eine Abhängigkeit statt Ihres eigenen Codes, sodass der Schadcode über eine normale Installation oder ein Update eintrifft. Gängige Techniken sind Typosquatting (ein Paket, dessen Name nur einen Buchstaben von einem populären abweicht), Dependency Confusion (ein Build zieht ein öffentliches statt eines internen Pakets) und die Übernahme eines Maintainer-Kontos. Der bekannteste jüngere Fall ist die im März 2024 entdeckte Hintertür in xz-utils: Ein Beitragender, der rund zwei Jahre lang das Vertrauen der Maintainer aufgebaut hatte, schleuste sie in die Versionen 5.6.0 und 5.6.1 der Kompressionsbibliothek ein. Ein Engineer bemerkte ungewöhnliche SSH-Latenz und meldete das Problem, bevor die betroffenen Versionen die meisten stabilen Linux-Distributionen erreichten.

Eine praktische Sicherheits-Checkliste für Open Source

Ein praxistaugliches Sicherheitsprogramm für Open Source braucht sieben Kontrollen, von denen die meisten automatisch in Ihrer CI-Pipeline laufen können:

• Eine SBOM führen. Erzeugen Sie für jedes Release eine Software-Stückliste im Format CycloneDX oder SPDX.
• Software Composition Analysis (SCA) in der CI. Lassen Sie Builds bei neuen kritischen Schwachstellen und unzulässigen Lizenzen fehlschlagen.
• Versionen festschreiben und Lockfiles committen. Builds sollen reproduzierbar und Upgrades bewusst sein.
• Dependency-Updates automatisieren. Bots, die kleine Upgrade-Pull-Requests öffnen, verhindern, dass Sie Jahre zurückfallen.
• Neue Abhängigkeiten prüfen. Bewerten Sie Wartungsaktivität und Sicherheitspraktiken mit dem OpenSSF Scorecard, bevor Sie ein Paket übernehmen.
• Artefakte signieren und verifizieren. Nutzen Sie Sigstore oder vergleichbare Tools, um nachzuweisen, was Sie gebaut haben und woher es stammt.
• Eine Richtlinie zur Meldung von Schwachstellen veröffentlichen. Sagen Sie Forschenden, wie sie Sie erreichen und wie schnell Sie reagieren.

Diese Kontrollen fügen sich nahtlos in einen sicheren Softwareentwicklungs-Lebenszyklus ein, in dem das Abhängigkeitsrisiko schon in der Designphase geprüft wird und nicht erst nach einem Vorfall.

EU Cyber Resilience Act: Was sich 2026 für Open Source ändert

Seit dem 11. September 2026 müssen Unternehmen, die Software mit Open-Source-Komponenten auf dem EU-Markt bereitstellen, aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle über die Single Reporting Platform der ENISA melden. Nach Artikel 14 des Cyber Resilience Act (CRA) bedeutet das eine Frühwarnung innerhalb von 24 Stunden, eine Meldung innerhalb von 72 Stunden und einen Abschlussbericht innerhalb von 14 Tagen, nachdem eine Korrektur verfügbar ist (bei schweren Vorfällen innerhalb eines Monats). Die vollständigen CRA-Pflichten, einschließlich Security-by-Design-Anforderungen und Konformitätsbewertung, gelten laut der Seite der Europäischen Kommission zu den CRA-Meldepflichten ab dem 11. Dezember 2027.

Der CRA verteilt Pflichten nach Rollen. Der erste Schritt ist daher zu wissen, welche Rolle Sie einnehmen:

• Hersteller. Ein Unternehmen, das ein Produkt mit digitalen Elementen im Rahmen einer Geschäftstätigkeit auf dem EU-Markt bereitstellt. Wenn Sie Open Source in dieses Produkt einbetten, sind Sie dafür verantwortlich, als hätten Sie sie selbst geschrieben – einschließlich des Schwachstellenmanagements für diese Komponenten.
• Open-Source-Software-Verwalter (Steward). Eine juristische Person, etwa eine Stiftung oder ein Unternehmen, die die Entwicklung kommerziell genutzter Open Source systematisch unterstützt (Artikel 24). Verwalter brauchen eine dokumentierte Cybersicherheitsstrategie und müssen mit den Marktüberwachungsbehörden zusammenarbeiten. Sie melden nur, soweit sie beteiligt sind, etwa wenn sie die Infrastruktur oder die Signaturschlüssel des Projekts betreiben.
• Nicht kommerzielle Maintainer. Einzelpersonen und Projekte, die Open Source außerhalb einer Geschäftstätigkeit entwickeln, fallen nicht unter den CRA.

In der Praxis wird eine SBOM faktisch verpflichtend: Sie können keine Schwachstellen in Komponenten melden oder beheben, von denen Sie nicht wissen, dass Sie sie ausliefern. Der verständliche CRA-Leitfaden für Maintainer von openresource.dev erklärt die Rolle des Verwalters ausführlicher. Teams mit US-Fokus finden eine ähnliche Logik im NIST Secure Software Development Framework und in den Attestierungspflichten, die auf die Executive Order 14028 folgten.

Diese Zusammenfassung ist eine allgemeine Information und keine Rechtsberatung. Klären Sie Ihre Rolle und Pflichten mit einem Rechtsbeistand, der mit dem CRA vertraut ist.

Was kostet Open-Source-Softwareentwicklung?

Die Lizenz für Open-Source-Software ist kostenlos, die Gesamtbetriebskosten sind es nicht. Sie zahlen für das Engineering, das nötig ist, um Open-Source-Komponenten zu integrieren, anzupassen, abzusichern, zu aktualisieren und zu betreuen – so lange, wie Ihr Produkt läuft. In unseren Projekten beanspruchen laufende Patches und Upgrades typischerweise 15–25 % der ursprünglichen Entwicklungskosten pro Jahr. Das ist eine Schätzung aus unserer Projekterfahrung, keine Branchenstatistik, und sie hängt von der Größe des Abhängigkeitsbaums ab.

Der größte versteckte Kostenfaktor ist ein privater Fork. Jede Änderung, die nur in Ihrer Kopie existiert, muss bei jedem Upstream-Release erneut eingespielt werden, und der Abstand wächst, bis ein Upgrade zu einem eigenen Projekt wird. Korrekturen zurückzuspielen kostet heute etwas mehr und spart später deutlich mehr. Vollständige Budgetspannen nach Projekttyp finden Sie in unserer Übersicht zu den Kosten individueller Softwareentwicklung 2026.

So wählen Sie einen Partner für Open-Source-Softwareentwicklung

Der richtige Partner für Open-Source-Softwareentwicklung beweist, dass er Lizenzen, Sicherheit und Upstream-Beziehungen beherrscht, und nicht nur, dass er Code auf populären Frameworks schreiben kann. Nutzen Sie diese Checkliste mit sieben Punkten beim Vergleich von Anbietern:

1. Fähigkeit zum Lizenz-Audit. Fragen Sie, wie Lizenzen in Ihrer bestehenden Codebasis ermittelt werden und was bei einem Konflikt geschieht.
2. SBOM und SCA in der eigenen CI. Lassen Sie sich eine Beispiel-SBOM und den Pipeline-Schritt zeigen, der verwundbare oder unzulässige Abhängigkeiten blockiert.
3. Nachweisbare Upstream-Beiträge. Gemergte Pull Requests in den Projekten, von denen Sie abhängen, sind ein besserer Beleg als eine Logo-Folie.
4. Wartungs-SLA für Forks. Vereinbaren Sie schriftlich, wie schnell kritische Schwachstellen in Ihren Abhängigkeiten gepatcht werden.
5. Kenntnis von CRA und SSDF. Ein Partner, der in die EU oder an den öffentlichen Sektor der USA liefert, sollte bereits so arbeiten.
6. IP-Eigentum am individuellen Code. Der Vertrag muss festhalten, dass Ihnen der für Sie geschriebene Code gehört und wie Open-Source-Komponenten an Sie lizenziert sind. Unser Leitfaden zu Softwareentwicklungsverträgen nennt die zu prüfenden Klauseln.
7. Exit-Plan. Dokumentation, Build-Skripte und Zugänge müssen es einem anderen Team ermöglichen, ohne den ursprünglichen Anbieter weiterzuarbeiten.

Open Source und KI im Jahr 2026

KI hat jedem Projekt zwei neue Open-Source-Fragen hinzugefügt. Die erste betrifft Open-Weight-Modelle: Modelle mit veröffentlichten Gewichten, oft unter eigenen Lizenzen, die bestimmte Nutzungen einschränken. Sie brauchen dieselbe Lizenzprüfung wie jede andere Abhängigkeit. Die zweite betrifft KI-generierten Code: Assistenten können Snippets aus lizenziertem Code ohne Quellenangabe wiedergeben. Da 85 % der Organisationen KI-Coding-Assistenten nutzen und nur 54 % deren Ergebnisse auf Lizenzrisiken prüfen (Black Duck OSSRA 2026), gehört das Scannen von KI-geschriebenem Code in dieselbe Pipeline wie Ihre SCA-Prüfungen.

Häufig gestellte Fragen

Veröffentlicht am 16. Oktober 2026. Quellen: Black Duck, Open Source Security and Risk Analysis (OSSRA) Report 2026 und Pressemitteilung vom 25. Februar 2026; Europäische Kommission, Meldepflichten nach dem Cyber Resilience Act; openresource.dev, Cyber Resilience Act for maintainers; IBM Think, What is open source software?; GitHub, What is open source software; Hoffmann, Nagle und Zhou, The Value of Open Source Software, Working Paper der Harvard Business School, 2024.