Die zentralen Begriffe rund um Open-Source-Betrieb, SBOM, Sicherheitsprozesse, Regulierung und öffentlichen Sektor — kompakt und präzise erklärt. Als Referenz für Teams, die Verantwortung für Open Source tragen.
Ein Open Source Program Office ist die Stelle in einer Organisation, die den Umgang mit Open Source verantwortet: Inventar der eingesetzten Komponenten, Lizenzfragen, Sicherheitsprozesse und die Kommunikation mit den Open-Source-Projekten. Große Technologiekonzerne betreiben dafür eigene Teams; ein externes OSPO stellt dieselbe Funktion als vertraglich definierten Dienst bereit.
Managed Open Source Operations bezeichnet den laufenden, extern verantworteten Betrieb der Open-Source-Basis einer Organisation: Inventar und SBOM, Monitoring von Schwachstellen und Lifecycle, Triage und Support-Prozesse sowie die Arbeit mit den Upstream-Projekten. Der Unterschied zur klassischen Beratung: Es geht nicht um Empfehlungen, sondern um dauerhaft übernommene operative Verantwortung mit definierten Prozessen.
Managed Open Source Operations für den öffentlichen Sektor →
Maintainer sind die Personen, die ein Open-Source-Projekt pflegen: Sie prüfen Beiträge, entscheiden über Änderungen, veröffentlichen Releases und behandeln Sicherheitsmeldungen. Viele kritische Komponenten werden von wenigen Freiwilligen betreut — ihre Reaktionszeiten und Prioritäten kann kein Außenstehender garantieren, weshalb seriöse Dienstleister nur eigene Prozesse zusagen.
„Upstream" bezeichnet das Ursprungsprojekt einer Open-Source-Komponente — dorthin fließen Fehlermeldungen, Patches und Verbesserungen zurück. Upstream-Delivery meint diese Rückführung als professionellen Prozess: Issues nach den Regeln des Projekts, Sicherheitslücken über private Meldewege, eigene Patches und die Begleitung eines Pull Requests bis zu Merge und Release. Nur im Upstream gelöste Probleme bleiben dauerhaft gelöst; lokale Workarounds müssen bei jedem Update erneut gepflegt werden.
Eine SBOM ist die maschinenlesbare Stückliste einer Software: Sie führt alle enthaltenen Komponenten mit Version, Herkunft und Lizenz auf. Sie ist die Grundlage, um bei einer neuen Schwachstelle sofort zu wissen, ob und wo man betroffen ist — und wird von Regulierung wie dem EU Cyber Resilience Act und von Kunden zunehmend als Nachweis verlangt. Verbreitete Formate sind SPDX und CycloneDX.
SPDX und CycloneDX sind die beiden etablierten Standardformate für SBOMs. SPDX stammt aus der Linux Foundation und ist als ISO/IEC 5962 international genormt; CycloneDX wurde im OWASP-Umfeld entwickelt und als Ecma-Standard veröffentlicht, mit Schwerpunkt auf Security-Anwendungsfällen. Welche Variante gefordert ist, hängt vom Abnehmer ab — Werkzeuge und Dienstleister sollten beide erzeugen können.
QUELLE: spdx.dev ↗ · cyclonedx.org ↗
Open-Source-Lizenzen erlauben die Nutzung unter Bedingungen — von sehr freizügigen (permissiven) Lizenzen wie MIT oder Apache-2.0 bis zu Copyleft-Lizenzen wie der GPL, die Weitergaben an Pflichten knüpfen. Lizenz-Compliance heißt: alle eingesetzten Komponenten und ihre Lizenzen kennen, Pflichten wie Quelltext- oder Hinweispflichten erfüllen und Konflikte zwischen Lizenzen vermeiden. Die technische Feststellung ist Fleißarbeit auf Basis des Inventars; die rechtliche Bewertung im Einzelfall bleibt Aufgabe spezialisierter Juristen.
Die Software-Lieferkette umfasst alles, was in ein Softwareprodukt einfließt: direkte und transitive Abhängigkeiten, Build-Werkzeuge, Registries und Update-Kanäle. Supply-Chain-Security bedeutet, diese Kette transparent zu machen und abzusichern — denn Angriffe wie kompromittierte Pakete oder übernommene Maintainer-Konten treffen alle Nutzer einer Komponente gleichzeitig. Inventar, SBOM und laufendes Monitoring sind die Grundwerkzeuge dafür.
CVE ist das internationale System zur eindeutigen Kennzeichnung öffentlich bekannter Sicherheitslücken; jede erhält eine Nummer wie CVE-2021-44228 (Log4Shell). Eine CVE-Meldung sagt allerdings noch nicht, ob die eigene Organisation betroffen ist — das hängt von eingesetzter Version, Konfiguration und Nutzungskontext ab und ist Aufgabe der Triage.
QUELLE: cve.org ↗
Triage ist die strukturierte Erstbewertung einer gemeldeten Schwachstelle oder Störung: Betrifft uns das? In welcher Version, in welchem System, mit welcher Ausnutzbarkeit? Danach folgen Priorisierung, Workaround oder Patch und die Nachverfolgung bis zur Lösung. Ohne definierten Triage-Prozess entscheidet der Zufall, welche Meldung Aufmerksamkeit bekommt — mit ihm entsteht ein belastbarer, dokumentierter Ablauf mit Zeiten und Zuständigkeiten.
Coordinated (auch: responsible) Vulnerability Disclosure ist das abgestimmte Melden von Sicherheitslücken: zuerst vertraulich an die Verantwortlichen des Projekts über deren private Security-Kanäle, Veröffentlichung erst, wenn eine Behebung verfügbar ist. Das schützt alle Nutzer der betroffenen Komponente. Öffentliche Issues oder Social-Media-Posts über ungefixte Lücken gelten als unseriös und erhöhen das Risiko aktiver Ausnutzung.
End-of-Life bezeichnet den Zeitpunkt, ab dem eine Komponente oder Version keine Pflege mehr erhält — auch keine Sicherheitsupdates. Bei Open Source geschieht das oft still: Der Maintainer hört auf, ein Zweig wird eingestellt. Lifecycle-Management heißt, Release- und Supportzyklen laufend zu beobachten, EOL-Termine vorherzusehen und Migrationen zu planen, bevor eine ungepflegte Komponente zum Sicherheitsrisiko wird.
Der Cyber Resilience Act (Verordnung (EU) 2024/2847) verpflichtet Hersteller von Produkten mit digitalen Elementen zu Cybersicherheit über den gesamten Lebenszyklus: Risikobewertung, Schwachstellenmanagement, SBOM und Security-Updates. Die Verordnung ist am 10. Dezember 2024 in Kraft getreten; die Meldepflichten nach Art. 14 gelten ab dem 11. September 2026, die vollen Herstellerpflichten ab dem 11. Dezember 2027. Wer Community-Open-Source verbaut, muss deren Sicherheit damit aktiv verantworten.
Mit dem „Verwalter quelloffener Software" (Open Source Steward) führt der CRA eine eigene Akteurskategorie ein: Organisationen — etwa Stiftungen —, die die Entwicklung bestimmter, für kommerzielle Tätigkeiten bestimmter Open-Source-Produkte dauerhaft und systematisch unterstützen. Für Stewards gilt ein reduziertes Pflichtenprogramm, nicht der volle Herstellerkatalog. Wichtig: Wer Open Source lediglich in eigene Produkte einbaut, wird dadurch nicht zum Steward, sondern trägt die regulären Herstellerpflichten für das Gesamtprodukt.
Die Technische Richtlinie TR-03183 des Bundesamts für Sicherheit in der Informationstechnik konkretisiert Cyber-Resilienz-Anforderungen an Hersteller und Produkte; ihr zweiter Teil definiert formale und inhaltliche Anforderungen an SBOMs. Sie dient in Deutschland als praktischer Prüfmaßstab, um SBOM-Fähigkeit und Schwachstellenprozesse CRA-tauglich aufzusetzen.
NIS2 (Richtlinie (EU) 2022/2555) ist die EU-Richtlinie zur Netz- und Informationssicherheit. Sie verpflichtet wesentliche und wichtige Einrichtungen — darunter viele Betreiber öffentlicher Infrastruktur — zu Risikomanagement, Vorfallsmeldungen und Sicherheit in der Lieferkette; die nationale Umsetzung konkretisiert Geltungsbereich und Pflichten. Für Organisationen mit großem Open-Source-Bestand heißt das: nachweisbare Prozesse für Inventar, Schwachstellen und Lieferkette auch für Software ohne Hersteller.
Der IT-Grundschutz des BSI ist die in der deutschen Verwaltung etablierte Methodik für Informationssicherheits-Management: Bausteine, Gefährdungen und Anforderungen, aus denen sich ein prüfbares Sicherheitskonzept ergibt — anschlussfähig an ISO 27001. Für den Open-Source-Betrieb liefert er den Nachweisrahmen, in den Inventar, Schwachstellenmanagement und Betriebsprozesse einzahlen.
Nachweise für NIS2 und IT-Grundschutz im Public-Sector-Angebot →
Digitale Souveränität bezeichnet die Fähigkeit von Staaten und Organisationen, ihre digitale Infrastruktur selbstbestimmt zu gestalten und zu betreiben — ohne kritische Abhängigkeit von einzelnen Anbietern. Open Source ist dafür ein zentraler Baustein, verlagert die Verantwortung aber nach innen: Ohne Hersteller im Rücken braucht es eine klar zugewiesene operative Zuständigkeit für Sicherheit, Lifecycle und Weiterentwicklung der eingesetzten Software.
openDesk ist der quelloffene Arbeitsplatz für die öffentliche Verwaltung in Deutschland, aufgebaut aus etablierten Open-Source-Komponenten und betreut durch das Zentrum für Digitale Souveränität (ZenDiS). Er steht beispielhaft für die strategische Open-Source-Wende der Verwaltung — und für die Folgefrage, wer Betrieb, Sicherheitsprozesse und Upstream-Arbeit der eingesetzten Komponenten dauerhaft verantwortet.
QUELLE: opendesk.eu ↗
Direktauftrag und Verhandlungsvergabe sind vereinfachte Verfahren des deutschen Vergaberechts unterhalb der EU-Schwellenwerte: Beim Direktauftrag kann ein Auftrag ohne förmliches Verfahren vergeben werden, bei der Verhandlungsvergabe ohne Teilnahmewettbewerb werden ausgewählte Unternehmen direkt zur Angebotsabgabe aufgefordert. Welche Wertgrenzen jeweils gelten, richtet sich nach Auftraggeber und aktuellem Regelwerk — die Prüfung liegt immer beim Auftraggeber.
ALVPHA Upstream übernimmt genau die hier beschriebenen Aufgaben als externen, vertraglich definierten Service — für Hersteller unter dem CRA und für den öffentlichen Sektor.
Dieses Glossar erläutert Begriffe allgemeinverständlich und ersetzt keine Rechtsberatung. Verbindlich sind allein die jeweiligen Rechtstexte und die Prüfung im Einzelfall.
