CRACI vs Black Duck

The short answer

Black Duck is a broad application security portfolio built around its software composition analysis (SCA) product, with static analysis, binary analysis, fuzzing and posture management around it. CRACI is a GitHub Actions-compatible CI runner that records every external dependency a build pulls in, and produces the SBOM, provenance and compliance evidence from that record. Black Duck is a scanner, and a thorough one. CRACI is a recorder. For most manufacturers the two are complementary.

At a glance

What Black Duck does well

Finding open source that nobody declared. Black Duck SCA combines package manager scanning with signature scanning, snippet detection for partial or modified code, and binary analysis. That matters when code was copied into a repository or vendored without a manifest. Findings draw on Black Duck Security Advisories, with severity, prioritization and reachability metrics, and the platform flags malicious packages.

Licenses. Black Duck identifies declared and undeclared licenses, full license text and copyright data, and its KnowledgeBase tracks more than 2,750 open-source licenses. CRACI includes declared license metadata in its SBOM export and enforces license policy.

Binaries and firmware. Black Duck Binary Analysis examines executables, libraries, containers and firmware without access to source code. If you receive third-party binaries or need to check a finished firmware image, that is ground CRACI does not cover.

More than SCA. Coverity provides static analysis across 22 languages, Defensics does fuzz testing, and Software Risk Manager consolidates findings as an application security posture management (ASPM) system. Black Duck integrates with Jenkins, GitLab, Azure DevOps, Bitbucket Pipelines, CircleCI, TeamCity and many other CI systems. Its Bridge CLI can open Fix PRs that upgrade vulnerable direct dependencies.

Where CRACI is different

It witnesses the build

Every technique above inspects something: a manifest, a source tree, a binary. None of them sees the build while it runs, including the toolchains, install scripts, base images, release downloads and cached packages that shape the output but may not be visible in it. CRACI is the runner, so it sees that activity directly. A package-aware proxy observes traffic to package sources for npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk and Git sources, plus download presets. Dependency evidence travels with CI caches.

Each SBOM states its completeness, per job and per cache, in five states: Complete, Complete with connections, Incomplete, Unavailable and Not recorded. CycloneDX and SPDX export are included.

It controls the build network

Because CRACI runs the job, you can set an egress policy for it: default deny or default allow, 24 built-in software-source presets, and typed custom sources for npm, PyPI, apt, apk, the Go proxy, Nix, Cargo, OCI registries and Git. Policies are validated before the job starts and fail closed, and CRACI can alert you when a job violates one. A scanner reports on what got in. An egress policy limits what can get in.

Provenance and monitoring

The API returns SBOMs, network traces and provenance. CRACI keeps re-evaluating monitored SBOMs for new vulnerabilities.

An inventory of what is deployed where

CRACI's inventory view shows exactly which software versions are deployed to which products, globally. When a new vulnerability lands, you can see which products run the affected version instead of piecing it together from release notes and spreadsheets.

Which one fits, and when to use both

• Embedded products built with Yocto. CRACI can run Yocto and BitBake builds on its runners, up to 32 vCPU and 96 GB, with an egress policy that complements BitBake's own network controls. CRACI's SBOM records what the build fetched, including host packages and GitHub Actions that Yocto's create-spdx SBOM leaves out, with a package URL for every Rust crate. Black Duck Binary Analysis can then check the finished image. See the Yocto guide.
• Code with a long history of copied or vendored open source. Snippet and signature scanning is Black Duck's strength. Keep it.
• Teams on GitHub Actions that need release evidence. CRACI records each build, holds the SBOM and provenance data for it, and exports SBOMs as CycloneDX or SPDX.
• Pipelines on Jenkins, GitLab or Azure DevOps. Black Duck fits today. CRACI supports GitHub Actions only today, with GitLab CI and Jenkins on the roadmap, so those pipelines would need to move first.

For the Cyber Resilience Act

Black Duck publishes a set of CRA pages covering deadlines, the 24-hour vulnerability reporting requirement, and why it considers SCA alone insufficient for CRA. It maps its portfolio to the regulation: Black Duck SCA to analyze codebases against EUVD and NVD data and generate SBOMs, Coverity with a CRA-aligned checker option announced in July 2026, Defensics for robustness testing, and Software Risk Manager for policy gates. Its argument is that the regulation needs layers: SCA for components, plus static and dynamic testing for your own code and services.

CRACI adds evidence from the build itself: what went into each release, how complete that record is, and continuous monitoring afterward, with SBOMs that export as CycloneDX or SPDX. It automates a significant part of the software supply chain visibility and evidence that companies need for their wider CRA compliance process. Read more on CRA compliance and industrial IoT.

Adding CRACI alongside Black Duck

CRACI replaces the runner, not GitHub Actions. Change runs-on to craci in a workflow and runs still appear in the GitHub UI. Black Duck scan steps stay in the workflow. Pick one product release, compare CRACI's build-time SBOM with your Black Duck bill of materials, and review the components only one of them found.