Was Ihnen dieser Scan sagen kann und was nicht

Er beantwortet eine einzige, eng gefasste Frage: Zeigt diese öffentliche URL offensichtliche Anzeichen für Drittanbieter-Lizenz-Offenlegung oder offensichtliche Lücken? Er hilft Teams, die ihre Marketing-Website noch nie geprüft haben, fehlende Links, Weiterleitungen zur Startseite oder leere Lizenzseiten zu finden.

Für SaaS-Anbieter ist die Marketing-Website oft die erste Anlaufstelle für Käufer, bevor sie nach der echten Lizenz-Compliance-Seite für das ausgelieferte Produkt fragen.

• HTTP-Antworten auf gängigen Lizenz- und Hinweispfaden (/license, /legal, /oss usw.).
• Ob diese Seiten plausiblen Lizenz- oder Drittanbieter-Hinweistext enthalten und keine leeren Hüllen sind.
• Einige im HTML der Startseite sichtbare Drittanbieter-Skript-URLs.
• Offensichtliche Weiterleitungen, die Lizenzpfade auf themenfremde Seiten umleiten.
• Fehlende Links: Kein Lizenz-Footer, keine Open-Source-Erwähnung, keine Compliance-URL in der Sitemap.

Er sieht nicht, was nicht auf der öffentlichen Seite steht: Lizenz-Compliance für ein ausgeliefertes Produkt lebt in den Build-Inputs (Lockfiles, SBOMs, Release-Bundles), nicht auf Ihrer Startseite. Ein sauberer Scan bedeutet nicht, dass Ihre mobile App, Ihr Desktop-Installer oder Ihr API-Backend dokumentiert ist.

Der Scan liest keine transitiven npm-Abhängigkeiten, prüft keine SPDX-Kennungen, bestätigt keinen vollständigen Lizenztext pro Komponente und weiß nicht, ob ein Mensch die Veröffentlichung freigegeben hat. Diese Lücke ist groß: Laut Black Ducks OSSRA-Bericht 2025 verursachten transitive Abhängigkeiten fast 30 % der gefundenen Lizenzkonflikte, und keiner davon ist von einer Startseite aus sichtbar. Er kann die Drittanbieter-Lizenz-Offenlegung, die an das gebunden ist, was Sie ausliefern, nicht ersetzen.

• Abhängigkeiten, die in iOS-, Android-, Desktop- oder eingebetteten Produkten gebündelt sind, nicht im öffentlichen Web.
• Transitive Pakete, die nie in browserseitigem JavaScript geladen werden.
• Ob gelistete Lizenzen mit dem übereinstimmen, was im geprüften Produkt tatsächlich ausgeliefert wird.
• Status von Prüfung und Veröffentlichungsfreigabe: Gates, Freigaben, Audit-Trail.
• Copyleft-Compliance: Quellcode-Angebote, entsprechender Quellcode, Auslöser durch Verbreitung.
• Schriftarten, SDKs und Icons, die auf der gescannten URL nicht referenziert sind.
• Rein interne Komponenten oder luftisolierte Auslieferungsmodelle.

Der Scan ist ein Vorgeschmack, der sichtbare Lücken auf einer einzelnen öffentlichen URL findet; eine Lizenz-Compliance-Seite ist der operative Nachweis: geprüfter Bestand, vollständiger Lizenztext, Namensnennung, eine stabile URL für die Beschaffung und Exporte im Einklang mit den Releases.

Teams bestehen einen Oberflächen-Scan, indem sie einen Footer-Link zu einer dünn besetzten Hinweisseite hinzufügen. Teams bestehen Enterprise-Due-Diligence, indem sie Lizenz-Compliance-Dokumentation pro Produkt pflegen, aktualisiert bei jeder Änderung der Abhängigkeiten.

Wenn der Scan Lücken findet, verstehen Sie das als Anstoß, nicht als Versagen. Bauen Sie einen Bestand aus Lockfiles oder SBOMs für das auf, was Sie tatsächlich ausliefern. Prüfen Sie die Lizenzen. Veröffentlichen Sie gepflegte Offenlegung in jedem Format, das Due-Diligence-Prüfungen verlangen.

Sieht der Scan sauber aus, fragen Sie trotzdem, ob die sichtbare Seite das vertraglich vereinbarte Produkt abdeckt. Lizenz-Footer der Marketing-Website und Lizenz-Compliance-Seiten des Produkts sind oft unterschiedliche Artefakte. Beide können nötig sein; nur eine davon erfüllt eine Anfrage nach Drittanbieter-Lizenz-Offenlegung für das ausgelieferte Produkt.