Alternatives à FOSSA

Nous développons CRACI, tenez-en compte ; nous décrivons chaque option à partir de sa propre documentation et indiquons quand un autre outil convient mieux.

Pourquoi les équipes regardent au-delà de FOSSA

La conformité des licences est le point de départ de FOSSA, et cela se voit : détection des licences en texte intégral, politiques automatiques, extraction des copyrights et mentions d'attribution en SPDX, HTML et texte. En plus de cela, FOSSA génère des SBOM SPDX et CycloneDX, importe les SBOM des fournisseurs avec des politiques d'éléments minimaux NTIA et FDA, et les partage via un SBOM Portal avec Enterprise. La CLI FOSSA s'intègre à plus de 20 systèmes de build, et il existe un plan gratuit.

Les équipes comparent tout de même des alternatives, généralement pour des raisons de périmètre et d'adéquation :

• Une inspection du code plus poussée. Une analyse de snippets, de signatures et de binaires à grande échelle, ou l'analyse statique de votre propre code dans la même suite.
• Une plateforme axée d'abord sur la sécurité. La politique de conteneurs, l'atteignabilité ou un système de référence pour la sécurité produit peuvent compter davantage pour vous que le travail sur les licences.
• L'origine de la SBOM. La CLI FOSSA interroge votre outil de build lorsqu'un build fonctionnel est disponible et procède par déduction à partir du code source dans le cas contraire. Certaines équipes veulent un enregistrement de ce que le build a récupéré.
• Tarifs et hébergement. Une tarification par projet peut ne pas convenir, ou vous voulez peut-être un outil gratuit et auto-hébergé.

Ce qu'il faut examiner

• La profondeur de l'analyse des licences : licences déclarées et non déclarées, politiques, mentions d'attribution.
• La façon dont les SBOM sont produites, et si l'outil vous indique quand l'une d'elles est incomplète.
• La réception des SBOM de fournisseurs, VEX et le partage avec les clients ou les autorités.
• L'analyse de snippets, de binaires ou de firmware si vous livrez du code que vous n'avez pas construit depuis les sources.
• La couverture CI, les options d'hébergement et la façon dont le prix évolue : par projet, par développeur ou sur devis.

Les options

1. CRACI (notre produit)

CRACI est un runner GitHub Actions qui enregistre la SBOM pendant que le build s'exécute. Un proxy qui comprend les paquets capture le trafic vers les sources de paquets, y compris les paquets restaurés depuis les caches CI et toutes les dépendances transitives utilisées par le build, et chaque SBOM indique sa complétude par job et par cache. CRACI applique une politique de trafic sortant qui bloque tout en cas d'échec et réévalue en continu les SBOM surveillées. La vue d'inventaire de CRACI montre exactement quelles versions logicielles sont déployées sur quels produits, à l'échelle mondiale.

Les licences proviennent du même enregistrement. Chaque paquet enregistré porte sa licence déclarée : vous voyez donc quelles dépendances sont sous une licence commerciale ou autrement restrictive avant de livrer, et les licences copyleft sont repérées avant d'aboutir dans le produit. Des règles de politique de licences peuvent bloquer un build en raison d'une licence.

Idéal pour : les équipes sur GitHub Actions qui doivent montrer à partir de quoi chaque release a été construite, avec les licences déclarées et la politique de licences dans le même enregistrement. À envisager si : les licences déclarées couvrent votre travail sur les licences. CRACI ne fait aucun scan de snippets ou de binaires, et il ne prend en charge que GitHub Actions aujourd'hui, avec GitLab CI et Jenkins sur la roadmap. CRACI face à FOSSA

2. Black Duck

Black Duck SCA combine le scan des gestionnaires de paquets avec le scan de signatures, la détection de snippets et l'analyse de binaires, ce qui lui permet de trouver l'open source que personne n'a déclaré. Sa KnowledgeBase suit plus de 2 750 licences, y compris les licences non déclarées, le texte intégral et les données de copyright. Black Duck Binary Analysis examine les exécutables, les conteneurs et les firmwares sans code source, et Coverity ajoute le SAST sur 22 langages.

Idéal pour : les bases de code contenant de l'open source copié ou vendoré, et les équipes qui vérifient des binaires ou des firmwares tiers. À envisager si : une tarification sur devis vous convient ; il n'y avait aucun prix publié en septembre 2026. CRACI face à Black Duck

3. Sonatype

Sonatype Lifecycle est le produit SCA et de politiques de Sonatype. Il fournit 18 politiques par défaut, avec des politiques de licences couvrant plus de 2 000 licences, et son Advanced Binary Fingerprinting examine l'application finie, y compris les composants renommés ou modifiés. Repository Firewall arrête les composants qui ne respectent pas vos politiques avant qu'ils n'entrent dans vos dépôts, et SBOM Manager importe et surveille les SBOM avec un workflow VEX.

Idéal pour : les organisations qui veulent appliquer les politiques de licences et de sécurité au niveau du dépôt de paquets comme dans l'application. À envisager si : vous utilisez Nexus ou un autre gestionnaire de dépôts. Les nouveaux clients achètent Sonatype Guide ; Firewall Pro commence à $4,800 par an (en septembre 2026). CRACI face à Sonatype

4. Anchore Enterprise

Anchore Enterprise s'appuie sur les outils open source Syft et Grype. Il crée des SBOM pour les conteneurs, le code source et les systèmes de fichiers, importe des SBOM produites ailleurs, rescanne en continu les SBOM stockées et applique des packs de politiques comme FedRAMP et NIST. Il peut être auto-hébergé, y compris en environnement isolé (air-gapped).

Idéal pour : les environnements gouvernementaux et ceux qui reposent largement sur les conteneurs. À envisager si : la conformité des licences n'est pas votre besoin principal ; les sources Anchore que nous avons utilisées portent sur les politiques de sécurité. La tarification se fait sur devis. CRACI face à Anchore

5. Cybeats SBOM Studio

SBOM Studio est un système de référence pour les SBOM de vos produits et de vos fournisseurs. Il prend en charge SPDX 2.2 à 3.0.1 et CycloneDX 1.2 à 1.7, valide les fichiers avec un Quality Score, rapproche les composants en continu, et ajoute VEX et l'analyse des licences OSS et COTS. Il partage les SBOM avec les clients, y compris via la Transparency Exchange API.

Idéal pour : les équipes de sécurité produit qui mènent un programme SBOM sur de nombreux produits et fournisseurs. À envisager si : vous disposez d'un autre moyen de générer des SBOM ; Cybeats renvoie vers les éditeurs de sa Marketplace. CRACI face à Cybeats

6. Manifest

Manifest crée, importe, enrichit et partage des SBOM pour vos produits, les logiciels de vos fournisseurs et vos modèles d'IA. Les fournisseurs téléversent leurs SBOM via un portail, et Manifest peut générer une SBOM à partir d'un binaire compilé lorsqu'un fournisseur ne peut pas en fournir. Il prend en charge SPDX, CycloneDX et VEX, et transforme les résultats en tickets et en rapports de risque.

Idéal pour : les organisations dont la principale exposition vient des logiciels qu'elles achètent. À envisager si : la conformité des licences est centrale ; les sources Manifest que nous avons utilisées portent sur la sécurité et le risque fournisseur. CRACI face à Manifest

7. Mend.io

Mend SCA détecte les licences sur les dépendances directes et transitives et applique des politiques, par exemple pour bloquer l'AGPL dans les produits commerciaux. Il ajoute l'atteignabilité par graphe d'appels, la détection des paquets malveillants, des SBOM SPDX et CycloneDX, la réception de SBOM tierces et VEX. Mend SAST couvre plus de 30 langages, et Mend Renovate maintient les dépendances à jour.

Idéal pour : les équipes qui veulent la politique de licences, le scan de sécurité et les mises à jour des dépendances chez un seul éditeur. À envisager si : une tarification par développeur vous convient ; Mend AppSec est affiché jusqu'à $1,000 par développeur contributeur et par an (en septembre 2026). CRACI face à Mend.io

8. Dependency-Track (open source)

OWASP Dependency-Track est une plateforme gratuite sous licence Apache 2.0 qui suit les composants de votre portefeuille, récupère les données de vulnérabilité auprès de sources comme la NVD et GitHub Advisories, et applique des politiques de sécurité, de licences et opérationnelles. Il consomme et produit du VEX CycloneDX.

Idéal pour : les équipes qui veulent une analyse de SBOM et une politique de licences auto-hébergées, sans frais de licence. À envisager si : vous êtes prêt à l'exploiter et à l'alimenter ; il analyse les SBOM que vous téléversez et ne les génère pas. CRACI pour les utilisateurs de Dependency-Track

9. ScanCode Toolkit (open source)

ScanCode Toolkit, issu du projet AboutCode, détecte les licences, les copyrights, les manifestes de paquets et les dépendances directes dans le code source et les fichiers binaires. Il écrit ses résultats en JSON, YAML, HTML, CycloneDX ou SPDX. Le toolkit est sous licence Apache-2.0.

Idéal pour : les équipes qui veulent une détection gratuite des licences et des copyrights au niveau des fichiers, exécutable partout. À envisager si : vous pouvez construire le workflow autour de lui. C'est un scanner : à vous d'ajouter les politiques, la surveillance et le reporting.

10. OSS Review Toolkit (open source)

OSS Review Toolkit (ORT) est un projet de la Linux Foundation sous licence Apache 2.0 qui automatise les politiques open source. Son Analyzer résout les dépendances entre gestionnaires de paquets, le Downloader récupère leur source, le Scanner exécute des scanners de licences et de copyrights, l'Advisor récupère les avis de sécurité, l'Evaluator applique vos règles de politique, et le Reporter produit des rapports, des mentions open source et des SBOM.

Idéal pour : les équipes qui veulent un pipeline de conformité des licences gratuit et auto-hébergé, avec des politiques sous forme de code. À envisager si : vous disposez du temps d'ingénierie nécessaire pour le configurer et l'exécuter.

Côte à côte

« Anchore » désigne Anchore Enterprise, et « Cybeats » désigne SBOM Studio. ScanCode et ORT sont des boîtes à outils que vous assemblez dans votre propre workflow : ils sont donc décrits ci-dessus et ne figurent pas dans le tableau. « Non précisé » signifie que la fonctionnalité n'est pas décrite dans la documentation des éditeurs, et non qu'elle est absente.

Quand rester sur FOSSA

• La conformité des licences et les mentions d'attribution sont votre première préoccupation, partagée par les équipes juridiques et d'ingénierie.
• Vous voulez commencer gratuitement et payer par projet au fil de votre croissance.
• Vous partagez des SBOM avec des partenaires ou le public via le SBOM Portal de FOSSA.

Pour en savoir plus sur l'enregistrement des SBOM à la source, consultez la génération de SBOM au moment du build, les preuves CRA et les tarifs.

Alternatives à FOSSA : FAQ

Des réponses courtes aux questions que se posent les équipes qui comparent

Quelle est la meilleure alternative à FOSSA ?

Tout dépend de ce qui vous manque. Pour le scan de snippets et de binaires, regardez Black Duck. Pour une politique de licences au niveau du dépôt de paquets, regardez Sonatype. Pour une politique de licences avec scan de sécurité et mises à jour des dépendances, regardez Mend.io. Pour des programmes SBOM couvrant les fournisseurs, regardez Cybeats ou Manifest. Pour des outils gratuits, regardez ScanCode Toolkit, ORT et Dependency-Track. Si vous avez besoin d'un enregistrement de ce que chaque build a récupéré, CRACI l'enregistre depuis le build lui-même.

Existe-t-il une alternative gratuite à FOSSA ?

Oui. ScanCode Toolkit et OSS Review Toolkit (ORT) sont des scanners de licences gratuits et open source, et OWASP Dependency-Track est une plateforme gratuite qui applique une politique de licences aux SBOM que vous téléversez. FOSSA propose lui aussi un plan gratuit. Les outils gratuits vous laissent l'hébergement, la configuration et le reporting.

Quelles alternatives à FOSSA appliquent une politique de licences ?

FOSSA, Black Duck, Sonatype, Mend.io et Dependency-Track appliquent tous une politique de licences, et ORT évalue les règles de licence que vous écrivez. Mend.io, par exemple, peut bloquer l'AGPL dans les produits commerciaux. Dans CRACI, chaque paquet enregistré porte sa licence déclarée : les licences copyleft sont donc repérées avant d'aboutir dans le produit, et une règle de politique de licences peut bloquer le build.

CRACI gère-t-il la conformité des licences ?

Oui, pour les licences déclarées. Chaque paquet que CRACI enregistre depuis le build porte sa licence déclarée, qui est exportée dans la SBOM, et des règles de politique de licences peuvent bloquer un build en raison d'une licence. CRACI ne fait aucun scan de snippets ou de binaires : il ne trouve donc pas l'open source copié dans votre code sans paquet.

En quoi FOSSA diffère-t-il de Black Duck ?

FOSSA a commencé par la conformité des licences et y ajoute la gestion des SBOM, avec un plan gratuit et une tarification par projet. Black Duck est un portefeuille AppSec plus large : SCA avec analyse de signatures, de snippets et de binaires, une KnowledgeBase de plus de 2 750 licences et Coverity SAST, vendus sur devis. FOSSA propose le scan de snippets et de binaires sous forme de modules complémentaires.