FOSSA-Alternativen

Wir entwickeln CRACI, bitte berücksichtigen Sie das; wir beschreiben jede Option anhand ihrer eigenen Dokumentation und sagen, wann ein anderes Tool besser passt.

Warum Teams Alternativen zu FOSSA prüfen

Bei der Lizenz-Compliance hat FOSSA angefangen, und das merkt man: Volltext-Lizenzerkennung, automatische Policies, Copyright-Extraktion und Attribution Notices in SPDX, HTML und Text. Darüber hinaus erzeugt FOSSA SPDX- und CycloneDX-SBOMs, importiert Lieferanten-SBOMs mit Mindestelement-Policies nach NTIA und FDA und teilt sie im Enterprise-Plan über ein SBOM-Portal. Die FOSSA CLI ist in mehr als 20 Build-Systeme integriert, und es gibt einen kostenlosen Plan.

Teams vergleichen trotzdem Alternativen, meist aus Gründen des Umfangs und der Eignung:

• Tiefere Code-Prüfung. Snippet-, Signatur- und Binäranalyse im großen Maßstab oder statische Analyse Ihres eigenen Codes in derselben Suite.
• Eine Plattform mit Sicherheitsfokus. Container-Policy, Erreichbarkeit oder ein System of Record für Produktsicherheit sind Ihnen vielleicht wichtiger als Lizenzarbeit.
• Woher die SBOM kommt. Die FOSSA CLI fragt Ihr Build-Tool ab, wenn ein funktionierender Build verfügbar ist, und leitet andernfalls aus dem Quellcode ab. Manche Teams wollen eine Aufzeichnung dessen, was der Build geladen hat.
• Preise und Hosting. Preise pro Projekt passen vielleicht nicht, oder Sie möchten ein kostenloses, selbst gehostetes Tool.

Worauf Sie achten sollten

• Lizenztiefe: deklarierte und nicht deklarierte Lizenzen, Policies, Attribution Notices.
• Wie SBOMs entstehen und ob das Tool Ihnen sagt, wann eine unvollständig ist.
• Annahme von Lieferanten-SBOMs, VEX und Weitergabe an Kunden oder Behörden.
• Snippet-, Binär- oder Firmware-Analyse, wenn Sie Code ausliefern, den Sie nicht aus dem Quellcode gebaut haben.
• CI-Abdeckung, Hosting-Optionen und wie die Preise skalieren: pro Projekt, pro Entwickler oder auf Anfrage.

Die Optionen

1. CRACI (unser Produkt)

CRACI ist ein GitHub-Actions-Runner, der die SBOM aufzeichnet, während der Build läuft. Ein paketbewusster Proxy erfasst den Datenverkehr zu Paketquellen, einschließlich der aus CI-Caches wiederhergestellten Pakete und aller transitiven Abhängigkeiten, die der Build verwendet hat, und jede SBOM gibt ihre Vollständigkeit pro Job und pro Cache an. CRACI setzt eine Egress-Richtlinie durch, die im Zweifel blockiert (fail closed), und bewertet überwachte SBOMs fortlaufend neu. Die Inventaransicht von CRACI zeigt genau, welche Softwareversionen in welchen Produkten im Einsatz sind, weltweit.

Lizenzen stammen aus derselben Aufzeichnung. Jedes aufgezeichnete Paket trägt seine deklarierte Lizenz, sodass Sie vor der Auslieferung sehen, welche Abhängigkeiten unter einer kommerziellen oder anderweitig einschränkenden Lizenz stehen, und Copyleft-Lizenzen werden erkannt, bevor sie im Produkt landen. Lizenzrichtlinien können einen Build wegen einer Lizenz blockieren.

Ideal für: Teams auf GitHub Actions, die zeigen müssen, woraus jedes Release gebaut wurde, mit deklarierten Lizenzen und Lizenzrichtlinie in derselben Aufzeichnung. Sinnvoll, wenn: deklarierte Lizenzen Ihre Lizenzarbeit abdecken. CRACI bietet weder Snippet- noch Binär-Scanning und unterstützt heute nur GitHub Actions; GitLab CI und Jenkins sind auf der Roadmap. CRACI vs. FOSSA

2. Black Duck

Black Duck SCA kombiniert Paketmanager-Scanning mit Signatur-Scanning, Snippet-Erkennung und Binäranalyse und findet so Open Source, das niemand deklariert hat. Seine KnowledgeBase verfolgt mehr als 2.750 Lizenzen, einschließlich nicht deklarierter Lizenzen, Volltexten und Copyright-Daten. Black Duck Binary Analysis untersucht ausführbare Dateien, Container und Firmware ohne Quellcode, und Coverity ergänzt SAST für 22 Sprachen.

Ideal für: Codebasen mit kopiertem oder eingebundenem Open Source und Teams, die Binärdateien oder Firmware von Drittanbietern prüfen. Sinnvoll, wenn: Preise auf Anfrage zu Ihnen passen; Stand September 2026 gab es keine veröffentlichten Preise. CRACI vs. Black Duck

3. Sonatype

Sonatype Lifecycle ist das SCA- und Policy-Produkt von Sonatype. Es bringt 18 Standard-Policies mit, dazu Lizenz-Policies für mehr als 2.000 Lizenzen, und sein Advanced Binary Fingerprinting untersucht die fertige Anwendung, einschließlich umbenannter oder veränderter Komponenten. Repository Firewall stoppt Komponenten, die Ihre Policies nicht erfüllen, bevor sie in Ihre Repositories gelangen, und SBOM Manager importiert und überwacht SBOMs mit einem VEX-Workflow.

Ideal für: Organisationen, die Lizenz- und Sicherheits-Policies am Paket-Repository und in der Anwendung durchsetzen wollen. Sinnvoll, wenn: Sie Nexus oder einen anderen Repository-Manager betreiben. Neukunden kaufen Sonatype Guide; Firewall Pro beginnt bei $4,800 pro Jahr (Stand September 2026). CRACI vs. Sonatype

4. Anchore Enterprise

Anchore Enterprise baut auf den Open-Source-Tools Syft und Grype auf. Es erstellt SBOMs für Container, Quellcode und Dateisysteme, importiert anderswo erstellte SBOMs, scannt gespeicherte SBOMs fortlaufend neu und setzt Policy-Pakete wie FedRAMP und NIST durch. Es lässt sich selbst hosten, auch air-gapped.

Ideal für: containerlastige und behördliche Umgebungen. Sinnvoll, wenn: Lizenz-Compliance nicht Ihr Hauptbedarf ist; die von uns genutzten Anchore-Quellen konzentrieren sich auf Sicherheits-Policies. Preise auf Anfrage. CRACI vs. Anchore

5. Cybeats SBOM Studio

SBOM Studio ist ein System of Record für SBOMs aus Ihren Produkten und von Ihren Lieferanten. Es unterstützt SPDX 2.2 bis 3.0.1 und CycloneDX 1.2 bis 1.7, validiert Dateien mit einem Quality Score, gleicht Komponenten fortlaufend ab und ergänzt VEX sowie Lizenzanalyse für OSS und COTS. Es teilt SBOMs mit Kunden, auch über die Transparency Exchange API.

Ideal für: Produktsicherheitsteams, die ein SBOM-Programm über viele Produkte und Lieferanten betreiben. Sinnvoll, wenn: Sie einen separaten Weg zur SBOM-Generierung haben; Cybeats verweist auf die Anbieter in seinem Marketplace. CRACI vs. Cybeats

6. Manifest

Manifest erstellt und importiert SBOMs für Ihre Produkte, die Software Ihrer Anbieter und Ihre KI-Modelle, reichert sie an und teilt sie. Anbieter laden über ein Portal hoch, und Manifest kann eine SBOM aus einer kompilierten Binärdatei erzeugen, wenn ein Anbieter keine liefern kann. Es unterstützt SPDX, CycloneDX und VEX und macht aus Befunden Tickets und Risikoberichte.

Ideal für: Organisationen, deren größtes Risiko Software ist, die sie einkaufen. Sinnvoll, wenn: Lizenz-Compliance zentral ist; beachten Sie, dass sich die von uns genutzten Manifest-Quellen auf Sicherheit und Lieferantenrisiken konzentrieren. CRACI vs. Manifest

7. Mend.io

Mend SCA erkennt Lizenzen bei direkten und transitiven Abhängigkeiten und setzt Policies durch, etwa das Blockieren von AGPL in kommerziellen Produkten. Es ergänzt Erreichbarkeit per Aufrufgraph, Erkennung bösartiger Pakete, SPDX- und CycloneDX-SBOMs, die Aufnahme von SBOMs Dritter und VEX. Mend SAST deckt mehr als 30 Sprachen ab, und Mend Renovate hält Abhängigkeiten aktuell.

Ideal für: Teams, die Lizenz-Policy, Sicherheits-Scanning und Abhängigkeits-Updates von einem Anbieter möchten. Sinnvoll, wenn: Preise pro Entwickler passen; Mend AppSec ist mit bis zu $1,000 pro beitragendem Entwickler und Jahr gelistet (Stand September 2026). CRACI vs. Mend.io

8. Dependency-Track (Open Source)

OWASP Dependency-Track ist eine kostenlose Plattform unter Apache 2.0, die Komponenten über Ihr Portfolio hinweg verfolgt, Schwachstellendaten aus Quellen wie der NVD und GitHub Advisories bezieht und Sicherheits-, Lizenz- und Betriebs-Policies anwendet. Es verarbeitet und erzeugt CycloneDX VEX.

Ideal für: Teams, die selbst gehostete SBOM-Analyse und Lizenz-Policy ohne Lizenzgebühr wollen. Sinnvoll, wenn: Sie bereit sind, es zu betreiben und zu befüllen; es analysiert hochgeladene SBOMs und erzeugt keine. CRACI für Dependency-Track-Nutzer

9. ScanCode Toolkit (Open Source)

ScanCode Toolkit aus dem Projekt AboutCode erkennt Lizenzen, Copyrights, Paketmanifeste und direkte Abhängigkeiten in Quellcode und Binärdateien. Es schreibt Ergebnisse als JSON, YAML, HTML, CycloneDX oder SPDX. Das Toolkit steht unter Apache-2.0.

Ideal für: Teams, die kostenlose Lizenz- und Copyright-Erkennung auf Dateiebene wollen, die sie überall ausführen können. Sinnvoll, wenn: Sie den Workflow darum herum aufbauen können. Es ist ein Scanner, Policies, Überwachung und Reporting müssen Sie also selbst ergänzen.

10. OSS Review Toolkit (Open Source)

Das OSS Review Toolkit (ORT) ist ein Projekt der Linux Foundation unter Apache 2.0, das Open-Source-Policy automatisiert. Sein Analyzer löst Abhängigkeiten über Paketmanager hinweg auf, der Downloader lädt ihren Quellcode, der Scanner führt Lizenz- und Copyright-Scanner aus, der Advisor bezieht Sicherheitshinweise, der Evaluator wendet Ihre Policy-Regeln an, und der Reporter erzeugt Berichte, Open-Source-Hinweise und SBOMs.

Ideal für: Teams, die eine kostenlose, selbst gehostete Lizenz-Compliance-Pipeline mit Policy as Code wollen. Sinnvoll, wenn: Sie die Entwicklungszeit haben, um es zu konfigurieren und zu betreiben.

Im direkten Vergleich

„Anchore“ steht für Anchore Enterprise und „Cybeats“ für SBOM Studio. ScanCode und ORT sind Toolkits, die Sie zu Ihrem eigenen Workflow zusammenstellen; sie sind deshalb oben beschrieben und nicht in der Tabelle enthalten. „Keine Angabe“ bedeutet, dass die Funktion in der Dokumentation der Anbieter nicht beschrieben ist, nicht dass sie fehlt.

Wann Sie bei FOSSA bleiben sollten

• Lizenz-Compliance und Attribution Notices sind Ihr erstes Anliegen, gemeinsam von Rechtsabteilung und Entwicklung getragen.
• Sie möchten kostenlos starten und mit dem Wachstum pro Projekt zahlen.
• Sie teilen SBOMs über das SBOM-Portal von FOSSA mit Partnern oder der Öffentlichkeit.

Mehr zur Aufzeichnung von SBOMs an der Quelle unter SBOM-Generierung während des Builds, CRA-Nachweise und Preise.

FOSSA-Alternativen: FAQ

Kurze Antworten auf die Fragen, die Teams beim Vergleichen stellen

Was ist die beste Alternative zu FOSSA?

Das hängt von der Lücke ab. Für Snippet- und Binär-Scanning sehen Sie sich Black Duck an. Für Lizenz-Policy am Paket-Repository Sonatype. Für Lizenz-Policy mit Sicherheits-Scanning und Abhängigkeits-Updates Mend.io. Für SBOM-Programme über Lieferanten hinweg Cybeats oder Manifest. Für kostenlose Tools ScanCode Toolkit, ORT und Dependency-Track. Wenn Sie einen Nachweis dessen brauchen, was jeder Build geladen hat, zeichnet CRACI ihn aus dem Build selbst auf.

Gibt es eine kostenlose Alternative zu FOSSA?

Ja. ScanCode Toolkit und das OSS Review Toolkit (ORT) sind kostenlose Open-Source-Lizenzscanner, und OWASP Dependency-Track ist eine kostenlose Plattform, die Lizenz-Policies auf von Ihnen hochgeladene SBOMs anwendet. Auch FOSSA selbst hat einen kostenlosen Plan. Kostenlose Tools überlassen Hosting, Konfiguration und Reporting Ihnen.

Welche FOSSA-Alternativen setzen Lizenz-Policies durch?

FOSSA, Black Duck, Sonatype, Mend.io und Dependency-Track wenden alle Lizenz-Policies an, und ORT wertet Lizenzregeln aus, die Sie schreiben. Mend.io kann zum Beispiel AGPL in kommerziellen Produkten blockieren. Bei CRACI trägt jedes aufgezeichnete Paket seine deklarierte Lizenz, sodass Copyleft-Lizenzen erkannt werden, bevor sie im Produkt landen, und eine Lizenzrichtlinie kann den Build blockieren.

Bietet CRACI Lizenz-Compliance?

Ja, für deklarierte Lizenzen. Jedes Paket, das CRACI aus dem Build aufzeichnet, trägt seine deklarierte Lizenz, die in der SBOM exportiert wird, und Lizenzrichtlinien können einen Build wegen einer Lizenz blockieren. CRACI bietet weder Snippet- noch Binär-Scanning und findet deshalb kein Open Source, das ohne Paket in Ihren Code kopiert wurde.

Worin unterscheidet sich FOSSA von Black Duck?

FOSSA begann bei der Lizenz-Compliance und ergänzt SBOM-Management, mit einem kostenlosen Plan und Preisen pro Projekt. Black Duck ist ein breiteres AppSec-Portfolio: SCA mit Signatur-, Snippet- und Binäranalyse, eine KnowledgeBase mit mehr als 2.750 Lizenzen und Coverity SAST, verkauft auf Anfrage. FOSSA bietet Snippet- und Binär-Scanning als Add-ons an.