Anbieterfragebögen

Wie beantworten Sie Lizenzfragen in Sicherheitsfragebögen?

Antworten Sie aus einem geprüften, produktbezogenen Bestand, gebunden an ein benanntes Release, nicht aus der Tabelle vom letzten Jahr. Fragebögen wollen stabile, aktuelle Offenlegung. Hier erfahren Sie, wie Sie antworten, ohne zu übertreiben.

Zuletzt aktualisiert: 2. Juli 2026

Sicherheitsfragebögen für Anbieter, SIG Lite, CAIQ, individuelle Ausschreibungstabellen: Die meisten enthalten einen Abschnitt zu Open Source, Drittanbieter-Software oder Lizenz-Compliance. Die Formulierung variiert. Der Prüfer will wissen, ob Sie Drittanbieter-Lizenzpflichten im bewerteten Produkt im Griff haben.

Diese Fragen kommen mitten in der Verhandlung und werden oft von jemandem beantwortet, der den Code nicht geschrieben hat. Engineering hat den Bestand vielleicht nie zentralisiert. Recht hat die Abhängigkeitsliste womöglich nie gesehen. Dieser Leitfaden ordnet typische Fragetypen ehrlichen Antworten zu, wenn sich Ihre Codebasis mit jedem Sprint ändert.

Diese Seite ordnet die Fragetypen des Fragebogens zu. Den Antwort-Workflow Schritt für Schritt finden Sie auf der Leitfäden-Seite „Lizenzanfrage aus der Beschaffung“.

Wo Lizenzfragen auftauchen

Fragebögen verteilen Lizenzpflichten über mehrere Abschnitte. Sie finden sie unter geistigem Eigentum, Softwareentwicklungspraktiken, Lieferkette, Rechtskonformität oder einem eigenen Open-Source-Anhang. Durchsuchen Sie das PDF nach: OSS, Open Source, Drittanbieter, Lizenz, SBOM, Komponente, Namensnennung, Copyleft, GPL.

Verwenden Sie Open-Source-Software im geprüften Produkt?
Stellen Sie eine Liste der Open-Source-Komponenten und Lizenzen bereit.
Stellen Sie Lizenztexte / Drittanbieter-Hinweise bereit.
Haben Sie eine Richtlinie für die Nutzung von Open Source?
Wie verfolgen Sie Lizenz-Compliance?
Stellen Sie ein SBOM bzw. eine Software-Stückliste bereit.
Link zur Open-Source- / Lizenz-Offenlegungsseite.
Gibt es Copyleft-Komponenten (GPL, AGPL, LGPL)?

Was prüfen Reviewer bei einem Lizenzfragebogen tatsächlich?

Reviewer prüfen operative Kontrolle, keine Philosophie: ob Sie eine geprüfte, produktbezogene Lizenzliste mit vollständigem Text vorlegen können, gebunden an ein benanntes Release, die auch Ihr nächstes Deployment übersteht. Standardisierte Fragebögen wie der Shared Assessments SIG und der CSA CAIQ verankern diese Erwartungen in benannten Kontrollzeilen.

Können Sie eine geprüfte Liste für dieses Produkt vorlegen? Enthält sie den vollständigen Lizenztext? Ist sie an ein benennbares Release gebunden? Bleibt sie nach Ihrem nächsten Deployment noch korrekt?

Ein Ja ohne Nachweis scheitert bei der Stichprobenprüfung: Man wählt fünf Komponenten aus und verlangt den Text. Ein Richtlinien-PDF ohne Bestand scheitert, weil Richtlinien nicht mit der Binärdatei ausgeliefert werden. Ein SBOM ohne geprüfte Lizenzen scheitert, weil Kennungen keine Offenlegung sind.

Vorhandensein eines Bestands für das konkrete Produkt, nicht unternehmensweites Schönreden.
Nachweis der Prüfung, nicht rohe Registry-Metadaten.
Vollständiger Lizenztext, keine Zusammenfassungen.
Prozess für Aktualisierungen, entscheidend, wenn Teams täglich Abhängigkeitsänderungen mergen.
Ehrlicher Geltungsbereich: SaaS, installierbare Software und eingebettete Systeme können sich unterscheiden.

Fragetyp	Ehrliche Antwort	Beizufügender Nachweis
Verwenden Sie Open-Source-Software?	Ja, mit geprüftem Bestand pro Produkt	Link zum veröffentlichten Offenlegungs-Nachweis
Komponenten und Lizenzen bereitstellen	Die geprüfte Liste für das bewertete Produkt	URL-, PDF- oder JSON-Export aus einem freigegebenen Snapshot
Lizenztexte / Hinweise bereitstellen	Vollständiger Text liegt dem Nachweis bei, nicht nur SPDX-IDs	Lizenztext pro Komponente im Nachweis
Copyleft vorhanden (GPL, AGPL, LGPL)?	Beantwortet aus einem durchsuchten Bestand, nie aus dem Gedächtnis	Suchergebnisse und Prüfstatus pro Treffer
Wie verfolgen Sie Compliance?	Import, Prüfung und Veröffentlichung bei jedem Release	Revisionsverlauf und Drift-Markierungen

Die häufigsten Fragetypen, mit der ehrlichen Antwort und dem Nachweis, der Stichprobenprüfungen übersteht.

Antworten, wenn der Bestand unvollständig ist

Kreuzen Sie nicht einfach Ja an und hängen Sie einen Footer der Marketing-Website an. Bauen Sie den Prozess gerade erst auf, sagen Sie das: was Sie heute haben, welches Release Sie abdecken können, wann die vollständige Offenlegung bereit sein wird.

Teilweise Ehrlichkeit rettet Deals. Übertriebene Behauptungen scheitern bei der rechtlichen Prüfung und zerstören Vertrauen. Viele Käufer akzeptieren einen Zeitplan, wenn Namen aus Engineering und Compliance daranhängen.

Nennen Sie den aktuellen Stand klar: teilweiser Bestand, laufende Prüfung, noch keine Veröffentlichung.
Benennen Sie das Produkt und Release, das Sie heute abdecken können.
Nennen Sie ein Datum für die vollständige Offenlegung, und halten Sie es ein.
Kopieren Sie nicht die Antworten vom letzten Jahr, wenn sich Abhängigkeiten geändert haben.
Eskalieren Sie Copyleft- oder GPL-Fragen an Ihren Rechtsbeistand. Ankreuz-Antworten sind riskant.

Antworten, wenn ein Bestand existiert

Schicken Sie aus demselben freigegebenen Veröffentlichungs-Snapshot: URL, PDF-Export oder JSON-Paket, je nachdem, was das Formular erlaubt. Nennen Sie Produktname, Release-Tag oder Datum, und einen Satz dazu, wie Sie bei Abhängigkeitsänderungen erneut veröffentlichen.

Wenn der Fragebogen sowohl SBOM als auch Lizenz-Offenlegung verlangt, fügen Sie beides aus demselben Release bei, behandeln Sie es aber nicht als austauschbar. Das SBOM erfüllt die Security-Zeilen; geprüfter Lizenztext erfüllt die Rechtszeilen.

Stimmen Sie mit dem geprüften Produkt überein, nicht mit einer verwandten SKU.
Geben Sie das Release oder Datum an, das die Daten widerspiegeln.
Fügen Sie den vollständigen Lizenztext bei oder verweisen Sie auf die geprüfte Offenlegung.
Beschreiben Sie die Pflege: Import, Prüfung, Veröffentlichung bei jedem Release.
Benennen Sie einen Verantwortlichen: Kontakt aus Engineering, Compliance oder Recht.

Wie sollten Sie Fragen zu Copyleft und risikoreichen Lizenzen beantworten?

Beantworten Sie Copyleft-Fragen aus einem durchsuchten, geprüften Bestand, nie aus dem Gedächtnis oder aus Vermutung, denn ein falsches „Nein“ ist die teuerste Antwort, die Sie geben können. Die Bedingungen von GPL, AGPL, LGPL und SSPL hängen davon ab, wie Sie linken, verbreiten und Quellcode anbieten, daher brauchen Treffer meist eine rechtliche Auslegung, bevor Sie unterschreiben.

Fragebögen fragen oft gezielt nach GPL, AGPL, LGPL oder Copyleft. Das erfordert einen genauen Bestand und häufig eine rechtliche Auslegung, wie Sie linken, verbreiten und Quellcode anbieten.

Antworten Sie nicht mit Nein, nur weil Sie nicht gesucht haben. Importieren Sie Lockfiles, suchen Sie nach Copyleft-Kennungen, eskalieren Sie Treffer, bevor Sie den Fragebogen unterschreiben. Ein falsches Nein ist schlimmer als ein markiertes Ja mit Abhilfeplan.

Durchsuchen Sie den Bestand nach GPL, AGPL, LGPL, SSPL und individuellen Lizenzen.
Dokumentieren Sie jeden Treffer: Version, Nutzungskontext, Prüfstatus.
Ziehen Sie Ihren Rechtsbeistand zu Verbreitungs- und Quellcode-Angebotspflichten hinzu.
Beantworten Sie den Fragebogen mit Fakten aus dem geprüften Bestand.
Aktualisieren Sie Antworten, wenn Copyleft-Komponenten hinzukommen oder entfernt werden.

Richtlinienfragen vs. Nachweisfragen

Viele Formulare verlangen Ihr Open-Source-Richtlinien-PDF. Richtlinien zählen im SOC-2- und ISO-Kontext. Sie beschreiben Absicht. Käufer verlangen trotzdem Nachweise: die tatsächliche Liste für das Produkt.

Beantworten Sie Richtlinienfragen mit Ihrer Richtlinie. Beantworten Sie Bestandsfragen mit Ihrem geprüften Nachweis, nicht nur mit der Richtlinie. Wenn die Richtlinie behauptet „wir halten Lizenzen ein“, Sie aber keinen veröffentlichten Bestand haben, scheitert die Nachweisfrage trotzdem.

Antworten nach der Einreichung wahr halten

Antworten in Fragebögen haben eine Halbwertszeit. In der Woche nach der Einreichung merged vielleicht jemand ein großes Abhängigkeits-Upgrade. Ihre unterschriebene Attestierung liegt weiterhin in der Akte des Käufers, jetzt veraltet.

Operative Teams importieren bei jedem Release erneut, prüfen Änderungen erneut, veröffentlichen die Offenlegung erneut und benachrichtigen Schlüsselkunden bei wesentlichen Änderungen des Lizenzstatus. Statische Antworten ohne Pflegekreislauf sind ein Risiko bei Vertragsverlängerungen und Audit-Zyklen.

Die schnellste ehrliche Antwort

SourceTrust macht diesen Kreislauf zum Standard: Lockfile importieren, jede Lizenz einmal prüfen, eine produktbezogene Attestierungsseite mit vollständigem Lizenztext veröffentlichen und bei jedem Release neu veröffentlichen. Der nächste Fragebogen bekommt eine URL statt Hektik.