CRACIとBlack Duckの比較

結論

Black Duckは、ソフトウェアコンポジション解析（SCA）製品を中心に、静的解析、バイナリ解析、ファジング、ポスチャ管理を組み合わせた幅広いアプリケーションセキュリティのポートフォリオです。CRACIは、ビルドが取り込むすべての外部依存関係を記録し、その記録からSBOM、来歴、コンプライアンスのエビデンスを生成する、GitHub Actions互換のCIランナーです。Black Duckはスキャナーであり、しかも徹底したスキャナーです。CRACIはレコーダーです。GitHub Actionsで実行されるビルドについては、SBOM生成と依存関係の監視で両者は重なります。スニペットマッチング、バイナリ解析、自社コードの静的解析では重なりません。CRACIはそれらを行わないためです。

早見表

Black Duckの強み

誰も宣言していないオープンソースの発見。Black Duck SCAは、パッケージマネージャーのスキャンに加え、シグネチャスキャン、部分的または改変されたコードのスニペット検出、バイナリ解析を組み合わせています。これは、コードがリポジトリにコピーされたり、マニフェストなしでベンダリングされたりした場合に重要です。検出結果はBlack Duck Security Advisoriesに基づき、深刻度、優先順位付け、到達可能性の指標を備え、プラットフォームは悪意のあるパッケージにもフラグを付けます。

ライセンス。Black Duckは宣言済み・未宣言のライセンス、ライセンスの全文、著作権データを特定し、そのKnowledgeBaseは2,750を超えるオープンソースライセンスを追跡しています。CRACIはSBOMのエクスポートに宣言ライセンスのメタデータを含め、ライセンスポリシーを適用します。

バイナリとファームウェア。Black Duck Binary Analysisは、実行ファイル、ライブラリ、コンテナ、ファームウェアを、ソースコードにアクセスせずに解析します。サードパーティのバイナリを受け取る場合や、完成したファームウェアイメージを確認する必要がある場合、そこはCRACIがカバーしない領域です。

SCAにとどまらない。Coverityは22言語の静的解析を提供し、Defensicsはファズテストを行い、Software Risk Managerはアプリケーションセキュリティポスチャ管理（ASPM）システムとして検出結果を統合します。Black DuckはJenkins、GitLab、Azure DevOps、Bitbucket Pipelines、CircleCI、TeamCityをはじめ多くのCIシステムと連携します。Bridge CLIは、脆弱な直接の依存関係をアップグレードするFix PRを作成できます。

Black Duckが優れている点：

• サードパーティのファームウェアなど、自社でビルドしていないソフトウェアのバイナリ解析。
• スニペットとライセンスの深さ：自社ファイル内にあるオープンソースの部分的なコピー、未宣言のライセンス、ライセンスの全文と著作権データを、2,750を超えるライセンスを収録したKnowledgeBaseから特定します。
• 成熟度とCIの幅広さ：Jenkins、GitLab、Azure DevOpsなど多数。
• より幅広いポートフォリオ：CoverityによるSAST、Defensicsによるファジング、Software Risk Managerによるアプリケーションセキュリティポスチャ管理。
• 到達可能性の指標と悪意のあるパッケージの検出。いずれも同社のSCA製品ページに記載されています。

Black Duckがコンポーネントを見つける方法と、ビルドの記録が加えるもの

Black Duckは、オープンソースを特定する4つの方法に加え、Yoctoビルド向けのディテクターを使います。いずれも検査対象については強力ですが、どれもビルドの後またはビルドの外に存在するもの、つまりマニフェスト、ファイルツリー、バイナリ、BitBakeのタスクグラフを基に動作します。ビルドレコーダーは、別の種類のエビデンスを加えます。リリースビルドが実際に取得したものを、完全性を明示して記録します。

パッケージマネージャーのディテクター（Black Duck Detect）

仕組み。Black Duck Detectは、プロジェクトのパッケージマネージャーから依存関係を見つけて抽出するディテクターを実行し、各パッケージマネージャーを使って依存関係の階層を導き出します。Detectはプロジェクトに対してBlack Duckのシグネチャスキャナーも実行します。デフォルトではDetectのすべてのツールが実行対象となり、どれを実行するかは設定で決まります。

得意な領域。多くのエコシステムとCIシステムにわたる、宣言済みの直接および推移的な依存関係を、ビルドを変更せずに把握できます。

ビルドの記録が加えるもの。宣言されたツリーは、パッケージマネージャーがインストールすると示しているものです。インストールフックがダウンロードするコード、ビルド時にダウンロードするビルドスクリプト、ベースイメージのレイヤーなど、どのマニフェストにも記載されない取得は、設計上その範囲外です。CRACIはそれらを記録し、各ジョブの完全性の状態が、見えなかったものを示します。

シグネチャスキャン

仕組み。シグネチャスキャナーは、ファイル、ディレクトリ、アーカイブを走査し、そのシグネチャをBlack Duck KnowledgeBaseにあるオープンソースコンポーネントのシグネチャと比較します。シグネチャは、ファイルシステムのメタデータとファイル内容の一方向のMD5またはSHA-1ハッシュです。スキャンはファイルパス、ファイルサイズ、シグネチャを送信し、Black Duckはソースコードやバイナリコードが社外に送られることはないとしています。改変されたオープンソースのアーカイブやディレクトリに対してファジーマッチを生成します。個々のファイルのマッチングはオプションです。リリース2020.2.0より前はデフォルトでしたが、誤検出がかなり多かったため、Black Duckはデフォルトで無効にしました。

得意な領域。マニフェストなしでコピー、ベンダリング、または名前変更されたオープンソースを、言語を問わず見つけます。

ビルドの記録が加えるもの。シグネチャスキャンが見るのは、実行された場所に存在するファイルです。ビルドが取得し、使用し、破棄したものは、もうハッシュ化できる場所にありません。両者は異なる問いに答えます。「このツリーにどんなコードがあるか」と「このビルドは何を取り込んだか」です。ベンダリングされたコードには、シグネチャスキャンが適したツールです。

スニペットマッチング

仕組み。シグネチャスキャンの後に行われる第2段階です。マッチしなかったファイルと、マッチしなかったディレクトリやアーカイブ内のファイルがスニペットスキャンの対象になります。Black Duckは一方向ハッシュの一種であるcodeprintsを計算し、KnowledgeBaseのファイル内のコードと一致するコード部分を探します。

得意な領域。自社ファイル内にあるオープンソースコードの部分的なコピーと、それに伴うライセンス上の義務。

ビルドの記録が加えるもの。ありません。CRACIはファイルの中身を見ません。

Black Duck Binary Analysis

仕組み。Black Duck Binary Analysisは、実行ファイル、ライブラリ、コンテナ、ファームウェアにコンパイルされたオープンソースを、コードにアクセスできない場合でも解析します。静的解析と文字列解析を組み合わせ、KnowledgeBaseとのファジーマッチングを行い、コンポーネント、脆弱性、ライセンスを報告します。メールアドレスや認可トークンなどの機密情報や、過剰な権限を要求するモバイルアプリケーションにもフラグを付けます。

得意な領域。自社でビルドしていないソフトウェア、つまりサプライヤーのファームウェア、購入したモジュール、他者が作成した完成イメージです。これはCRACIがカバーしない領域です。ビルドが手元にない場合、中身を知る方法はバイナリの解析です。その他のファームウェアツールはCRACIとFinite Stateの比較とCRACIとONEKEYの比較で比較しています。

ビルドの記録が加えるもの。CRACI上で自社がビルドするソフトウェアについては、出てきたものからの推測ではなく、入ったものの記録です。コンパイル済みコードの出力解析は入力を推測する必要がありますが、それを生成したビルドの記録には推測が要りません。両者は同じ製品についての異なるエビデンスです。

YoctoとBitBake（DetectのBitBakeディテクター）

仕組み。DetectのBitBakeディテクターは、ビルド環境スクリプト（デフォルトはoe-init-build-env）を読み込み、bitbake --environmentを実行してターゲットマシンのアーキテクチャとライセンスディレクトリを特定し、bitbake-layers show-recipesを実行して各レシピをそのレイヤーに対応付けます。detect.bitbake.package.namesで指定された各ターゲットについてbitbake -gを実行してtask-depends.dotを生成し、そのファイルからレシピとその依存関係を読み取ります。ビルド依存関係を除外するために、Detectはイメージのlicense.manifestを読み、イメージにインストールされているものを残します。結果は、KnowledgeBaseと照合されたレシピレベルの依存関係グラフです。

得意な領域。ビルドを変更せずに、イメージをレシピレベルで素早く把握できます。ビルド専用のレシピを除外するオプションもあります。

ビルドの記録が加えるもの。このグラフはBitBakeのタスクグラフから作られるため、列挙されるのはレシピです。ビルドが使うもののうちレシピでないもの、つまりビルドホストにインストールされたパッケージ、ワークフロー内のGitHub Actions、スクリプトが取得するツールは、構造上そのグラフの外にあります。CRACIはBitBakeのビルドを実行し、それらの取得も記録します。実際のイメージでどうなるかは、CRACIでのYoctoビルドで公開している並列比較をご覧ください。この比較はYocto自身のcreate-spdxによるSBOMを対象に行ったもので、Black Duckとの比較ではありません。

完全性

スキャンが報告するのはマッチしたものです。CRACIは各ジョブの完全性を、Complete、Complete with connections、Incomplete、Unavailable、Not recordedの5つの状態で示します。記録の欠落は、気付かれないままではなく可視化されます。

手法の比較

手法	読み取る対象	タイミング	得意な領域	ビルドの記録が加えるもの
パッケージマネージャーのディテクター	プロジェクトのパッケージマネージャー	Detectの実行場所で、プロジェクトのファイルとツールから	宣言済みの直接および推移的な依存関係	どのマニフェストにも記載されない取得、完全性の状態付き
シグネチャスキャン	ファイル、ディレクトリ、アーカイブ	スキャンの実行場所で、存在するファイルに対して	コピー、ベンダリング、名前変更されたオープンソース	ビルドが取得し、その後破棄したもの
スニペットマッチング	マッチしなかったファイル（codeprintsとして）	シグネチャスキャンの後	自社ファイル内のオープンソースの部分的なコピー	なし：CRACIはファイルの中身を見ない
Black Duck Binary Analysis	実行ファイル、ライブラリ、コンテナ、ファームウェア	ビルドの後、出力に対して	自社でビルドしていないソフトウェア	自社のビルドについて、入力の記録
BitBakeディテクター	task-depends.dot、レシピ、レイヤー	ビルド環境から、BitBake自身のコマンドで	イメージのレシピレベルの把握	ホストパッケージ、GitHub Actions、レシピ外で取得されたツール
CRACIのビルド記録	ジョブからパッケージソースへの通信	ビルド中	キャッシュや隠れた依存関係を含め、リリースビルドが実際に取得したもの	該当なし

CRACIの違い

実行中のビルドを観測する

上記の手法はいずれも、マニフェスト、ソースツリー、バイナリといった何かを検査するものです。どれも、実行中のビルドは見ていません。そこには、出力を形作りながら出力からは見えないこともある、ツールチェーン、インストールスクリプト、ベースイメージ、リリースのダウンロード、キャッシュされたパッケージが含まれます。CRACIはランナーそのものであるため、その動きを直接把握できます。パッケージを認識するプロキシが、npm、PyPI、RubyGems、Composer、Cargo、Go、Nix、OCI、apt、apk、Gitの各ソースに加え、ダウンロードプリセットについて、パッケージソースへの通信を観測します。依存関係のエビデンスはCIキャッシュとともに引き継がれます。

各SBOMは、ジョブごと・キャッシュごとに、Complete、Complete with connections、Incomplete、Unavailable、Not recordedの5つの状態で完全性を示します。CycloneDXとSPDXでのエクスポートにも対応しています。

ビルドのネットワークを制御する

CRACIはジョブを実行するため、ジョブにエグレスポリシーを設定できます。デフォルト拒否またはデフォルト許可で、24の組み込みソフトウェアソースプリセットと、npm、PyPI、apt、apk、Goプロキシ、Nix、Cargo、OCIレジストリ、Git向けの型付きカスタムソースを備えています。ポリシーはジョブの開始前に検証され、フェイルクローズで動作し、ジョブがポリシーに違反するとCRACIがアラートを送れます。スキャナーは入り込んだものを報告します。エグレスポリシーは入り込めるものを制限します。

来歴と監視

APIはSBOM、ネットワークトレース、来歴を返します。CRACIは監視対象のSBOMを新しい脆弱性に対して再評価し続けます。

どこに何がデプロイされているかのインベントリ

CRACIのインベントリビューは、どのソフトウェアバージョンがどの製品にデプロイされているかを、グローバルに正確に示します。新しい脆弱性が見つかったとき、リリースノートやスプレッドシートから寄せ集めるのではなく、影響を受けるバージョンを実行している製品を確認できます。

Black DuckのSBOMとCRACIのSBOM

Black Duck SCAは、部品表からSBOMをSPDX 2.2、2.3、3.0およびCycloneDX 1.3～1.6でエクスポートし、SBOMファイルをインポートすることもできます。CRACIはビルドの記録からCycloneDXとSPDXをエクスポートし、そのコンポーネントで見つかった脆弱性も含めます。APIはSBOM、ネットワークトレース、来歴データを返します。違いは形式ではなくリストの出どころです。Black Duckのリストはスキャンがマッチしたものから、CRACIのリストはビルドが取得したものから作られます。

どちらが適しているか、そして併用すべき場合

• Yoctoでビルドする組み込み製品。CRACIはBitBakeのビルドをCRACIのランナー上で最大32 vCPU・96 GBで実行し、取得したものを記録します。BitBake自身のネットワーク制御を補完するエグレスポリシーも適用できます。Black DuckのBitBakeディテクターはタスクグラフからイメージのレシピを把握し、Black Duck Binary Analysisは完成したイメージを確認できます。CRACIでのYoctoビルドとYoctoガイドをご覧ください。
• コピーやベンダリングされたオープンソースの長い履歴を持つコード。スニペットとシグネチャのスキャンはBlack Duckの強みです。引き続きご利用ください。
• リリースのエビデンスが必要なGitHub Actions利用チーム。CRACIは各ビルドを記録し、そのSBOMと来歴データを保持し、SBOMをCycloneDXまたはSPDXとしてエクスポートします。
• Jenkins、GitLab、Azure DevOps上のパイプライン。現時点ではBlack Duckが適しています。CRACIは現在GitHub Actionsのみに対応しており、GitLab CIとJenkinsはロードマップに掲載されているため、それらのパイプラインはまず移行が必要です。

Cyber Resilience Actへの対応

Black Duckは、期限、24時間以内の脆弱性報告要件、そしてCRAにはSCAだけでは不十分と考える理由を扱うCRA関連ページを公開しています。同社は自社のポートフォリオを規制に対応付けています。EUVDとNVDのデータに照らしてコードベースを分析しSBOMを生成するBlack Duck SCA、2026年7月に発表されたCRA対応のチェッカーオプションを備えたCoverity、堅牢性テストのためのDefensics、そしてポリシーゲートのためのSoftware Risk Managerです。同社の主張は、規制には複数のレイヤーが必要だというものです。コンポーネントにはSCA、そして自社のコードとサービスには静的・動的テストです。

CRACIは、ビルドそのものからのエビデンスを加えます。各リリースに何が含まれたか、その記録がどの程度完全か、そしてその後の継続的な監視であり、SBOMはCycloneDXまたはSPDXとしてエクスポートできます。企業がより広範なCRAコンプライアンスプロセスに必要とするソフトウェアサプライチェーンの可視性とエビデンスのかなりの部分を自動化します。詳しくはCRAコンプライアンスと産業用IoTをご覧ください。

Black DuckとCRACIを併用する

CRACIが置き換えるのはランナーであり、GitHub Actionsではありません。ワークフローでruns-onをcraciに変更すれば、実行結果は引き続きGitHubのUIに表示されます。Black Duckのスキャンステップはワークフローに残ります。製品リリースを1つ選び、CRACIのビルド時SBOMとBlack Duckの部品表を比較して、どちらか一方だけが見つけたコンポーネントを確認してください。

Black DuckとCRACI：よくあるご質問

それぞれのコンポーネントの見つけ方と、両者の組み合わせ方

Black Duckはどのようにオープンソースを見つけますか？

4つの方法に加え、Yocto向けのBitBakeディテクターがあります。Black Duck Detectはプロジェクトのパッケージマネージャーを読み取って依存関係ツリーを導き出します。シグネチャスキャナーは、ファイル、ディレクトリ、アーカイブのハッシュをKnowledgeBaseと照合します。スニペットマッチングは、マッチしなかったファイル内にあるオープンソースコードの部分的なコピーを見つけます。Black Duck Binary Analysisは、コンパイル済みの実行ファイル、ライブラリ、コンテナ、ファームウェアを解析します。

Black Duck Binary Analysisとは何ですか？

実行ファイル、ライブラリ、コンテナ、ファームウェアにコンパイルされたオープンソースを、ソースコードにアクセスせずに解析するBlack Duckの製品です。静的解析と文字列解析にKnowledgeBaseとのファジーマッチングを組み合わせ、コンポーネント、脆弱性、ライセンスに加え、認可トークンなどの機密情報も報告します。サプライヤーのファームウェアなど、自社でビルドしていないソフトウェアに適しています。

Black DuckはYoctoに対応していますか？

はい。DetectのBitBakeディテクターは、各ターゲットイメージに対するbitbake -gを含むBitBake自身のコマンドを実行し、task-depends.dotからレシピとその依存関係を読み取り、イメージのlicense.manifestを使ってビルド依存関係を除外できます。結果は、KnowledgeBaseと照合されたレシピレベルの依存関係グラフです。

CRACIはBlack Duckの代わりになりますか？

いいえ。CRACIはスニペット解析、バイナリ解析、静的解析を行わないため、それらはBlack Duckに残ります。CRACIで実行するビルドについては、SBOM生成と依存関係の監視を引き継げます。GitHub Actionsの各ビルドが取得したものを記録し、SBOMをCycloneDXまたはSPDXとしてエクスポートし、新しい脆弱性に対して再評価し続けます。

両方を併用できますか？

はい。CRACIが置き換えるのはランナーであり、GitHub Actionsではないため、Black Duckのスキャンステップは同じワークフロー内でCRACIのランナー上で引き続き実行されます。1つのリリースについてCRACIのビルド時SBOMとBlack Duckの部品表を比較し、どちらか一方だけが見つけたコンポーネントを確認してください。

Black DuckとSnykの違いは何ですか？

どちらもソフトウェアコンポジション解析（SCA）ツールですが、オープンソースの見つけ方が異なります。Snyk Open Sourceはマニフェストとロックファイルから依存関係ツリーを構築し、管理されていないC/C++コードについては、依存関係のソースコード全体がスキャン対象ディレクトリにある場合にファイルのシグネチャを照合します。IDE、CLI、リポジトリ、CIで使う開発者向けの設計で、Snyk Code、Snyk Container、Snyk IaCと並んで提供されます。Black Duckはこれに加えて、任意のファイルのシグネチャスキャン、部分的なコピーを見つけるスニペットマッチング、ソースコードなしでコンパイル済みソフトウェアやファームウェアを調べるBinary Analysisを備えています。SnykはFreeプランと月額$25からのTeamプランを公開しており、Black Duckは見積もりベースです。どちらもビルドを実行しません。CRACIはビルドを実行し、各GitHub Actionsビルドが取得したものを記録するため、どちらとも併用できます。