CRACI vs Black Duck

En bref

Black Duck est un vaste portefeuille de sécurité applicative construit autour de son produit d'analyse de la composition logicielle (SCA), complété par l'analyse statique, l'analyse binaire, le fuzzing et la gestion de la posture. CRACI est un runner CI compatible avec GitHub Actions qui enregistre chaque dépendance externe récupérée par un build, et produit la SBOM, la provenance et les preuves de conformité à partir de cet enregistrement. Black Duck est un scanner, et un scanner minutieux. CRACI est un enregistreur. Pour la plupart des fabricants, les deux sont complémentaires.

En un coup d'œil

Ce que Black Duck fait bien

Trouver l'open source que personne n'a déclaré. Black Duck SCA associe le scan des gestionnaires de paquets au scan par signatures, à la détection d'extraits pour le code partiel ou modifié, et à l'analyse binaire. C'est important lorsque du code a été copié dans un dépôt ou intégré sans manifeste. Les résultats s'appuient sur les Black Duck Security Advisories, avec des indicateurs de gravité, de priorisation et d'atteignabilité, et la plateforme signale les paquets malveillants.

Les licences. Black Duck identifie les licences déclarées et non déclarées, le texte intégral des licences et les données de copyright, et sa KnowledgeBase suit plus de 2 750 licences open source. CRACI inclut les métadonnées des licences déclarées dans son export de SBOM et applique une politique de licences.

Les binaires et les firmwares. Black Duck Binary Analysis examine les exécutables, les bibliothèques, les conteneurs et les firmwares sans accès au code source. Si vous recevez des binaires tiers ou devez vérifier une image firmware finale, c'est un terrain que CRACI ne couvre pas.

Bien plus que la SCA. Coverity assure l'analyse statique sur 22 langages, Defensics réalise des tests de fuzzing, et Software Risk Manager consolide les résultats en tant que système de gestion de la posture de sécurité des applications (ASPM). Black Duck s'intègre à Jenkins, GitLab, Azure DevOps, Bitbucket Pipelines, CircleCI, TeamCity et de nombreux autres systèmes CI. Sa Bridge CLI peut ouvrir des Fix PR qui mettent à jour les dépendances directes vulnérables.

Ce qui distingue CRACI

Il est témoin du build

Chacune des techniques ci-dessus inspecte quelque chose : un manifeste, une arborescence source, un binaire. Aucune ne voit le build pendant son exécution, y compris les toolchains, les scripts d'installation, les images de base, les téléchargements de releases et les paquets en cache qui façonnent le résultat sans forcément y être visibles. CRACI est le runner : il voit donc cette activité directement. Un proxy qui comprend les paquets observe le trafic vers les sources de paquets pour npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk et les sources Git, ainsi que des presets de téléchargement. Les preuves de dépendances suivent les caches CI.

Chaque SBOM indique sa complétude, par job et par cache, selon cinq états : Complete, Complete with connections, Incomplete, Unavailable et Not recorded. L'export CycloneDX et SPDX est inclus.

Il contrôle le réseau du build

Comme CRACI exécute le job, vous pouvez lui fixer une politique de trafic sortant : refus par défaut ou autorisation par défaut, 24 presets de sources logicielles intégrés et des sources personnalisées typées pour npm, PyPI, apt, apk, le proxy Go, Nix, Cargo, les registres OCI et Git. Les politiques sont validées avant le démarrage du job et bloquent tout en cas d'échec, et CRACI peut vous alerter lorsqu'un job en enfreint une. Un scanner rend compte de ce qui est entré. Une politique de trafic sortant limite ce qui peut entrer.

Provenance et surveillance

L'API renvoie les SBOM, les traces réseau et la provenance. CRACI continue de réévaluer les SBOM surveillées pour détecter de nouvelles vulnérabilités.

Un inventaire de ce qui est déployé et où

La vue d'inventaire de CRACI montre précisément quelles versions logicielles sont déployées dans quels produits, à l'échelle globale. Quand une nouvelle vulnérabilité apparaît, vous voyez quels produits exécutent la version concernée, au lieu de reconstituer l'information à partir de notes de version et de tableurs.

Lequel choisir, et quand utiliser les deux

• Les produits embarqués construits avec Yocto. CRACI peut exécuter des builds Yocto et BitBake sur ses runners, jusqu'à 32 vCPU et 96 Go, avec une politique de trafic sortant qui complète les contrôles réseau propres à BitBake. La SBOM de CRACI enregistre ce que le build a récupéré, y compris les paquets hôtes et les GitHub Actions que la SBOM create-spdx de Yocto laisse de côté, avec une package URL pour chaque crate Rust. Black Duck Binary Analysis peut ensuite vérifier l'image finale. Consultez le guide Yocto.
• Le code avec un long historique d'open source copié ou intégré. Le scan par extraits et par signatures est le point fort de Black Duck. Gardez-le.
• Les équipes sur GitHub Actions qui ont besoin de preuves de release. CRACI enregistre chaque build, conserve la SBOM et les données de provenance associées, et exporte les SBOM en CycloneDX ou SPDX.
• Les pipelines sur Jenkins, GitLab ou Azure DevOps. Black Duck convient aujourd'hui. CRACI ne prend en charge que GitHub Actions aujourd'hui, avec GitLab CI et Jenkins sur la roadmap : ces pipelines devraient donc d'abord migrer.

Pour le Cyber Resilience Act

Black Duck publie une série de pages sur le CRA couvrant les échéances, l'obligation de signaler les vulnérabilités sous 24 heures et les raisons pour lesquelles il juge la SCA seule insuffisante pour le CRA. Il associe son portefeuille au règlement : Black Duck SCA pour analyser les bases de code au regard des données de l'EUVD et de la NVD et générer des SBOM, Coverity avec une option de vérification alignée sur le CRA annoncée en juillet 2026, Defensics pour les tests de robustesse, et Software Risk Manager pour les politiques de blocage. Son argument : le règlement exige plusieurs couches, la SCA pour les composants, plus des tests statiques et dynamiques pour votre propre code et vos services.

CRACI ajoute des preuves issues du build lui-même : ce qui est entré dans chaque release, le niveau de complétude de cet enregistrement et une surveillance continue par la suite, avec des SBOM qui s'exportent en CycloneDX ou SPDX. Il automatise une part importante de la visibilité et des preuves sur la chaîne d'approvisionnement logicielle dont les entreprises ont besoin pour leur démarche plus large de conformité au CRA. En savoir plus sur la conformité CRA et l'IoT industriel.

Ajouter CRACI à côté de Black Duck

CRACI remplace le runner, pas GitHub Actions. Remplacez runs-on par craci dans un workflow, et les exécutions apparaissent toujours dans l'interface GitHub. Les étapes de scan Black Duck restent dans le workflow. Choisissez une release de produit, comparez la SBOM de build de CRACI avec votre nomenclature Black Duck, et examinez les composants qu'un seul des deux a trouvés.