CRACIとNetRiseの比較

要点

NetRiseはバイナリ解析の企業です。同社の製品Turbineは、ファームウェア、コンテナイメージ、アプリケーションバイナリを解析し、コンパイル済みコードからSBOMを生成するとともに、脆弱性、露出したシークレット、設定ミス、暗号を含むリスクを検出します。Dragosは2026年9月21日にNetRiseの買収を発表しました。CRACIはGitHub Actionsランナーであり、各ビルドが実行中に取り込むものを記録し、その記録からSBOMを生成して、リリース後も監視します。NetRiseは自社でビルドしていないソフトウェアも含めて出力を解析し、CRACIは自社で実行するビルドからエビデンスを残します。PSIRTにとって、両者がカバーする領域は異なります。

一覧で比較

NetRiseの強み

コンパイル済みコードからのSBOM。NetRise Turbineは「ソフトウェアそのものから導き出した、バイナリ由来の完全なSBOM」を生成し、静的リンクされた依存関係や組み込みの依存関係も含めます。ファームウェア、コンテナイメージ、アプリケーションバイナリに対応し、アプリケーション層の下にあるカーネル、RTOS、ドライバー、ファームウェアまで掘り下げます。チップベンダー、モジュールサプライヤーなど、ビルドを一切見ることのできないベンダーのソフトウェアの中身を見るには、この方法が必要です。

CVEスキャンでは見えないリスク。Turbineは、成果物に含まれて出荷されるシークレット、公開鍵と秘密鍵、証明書、設定ミスを報告し、あわせてライセンスの問題や、耐量子暗号への移行に向けた暗号インベントリも提示します。NetRise ZeroLensは、コンパイル済みソフトウェアの弱点を、悪用される前に探します。

優先順位付け。Turbineは、実行中のエントリーポイントから脆弱なコンポーネントまで追跡可能な実行パスがつながっているかを確認し、CISA KEVのステータスなど悪用可能性のシグナルを示します。NetRiseによれば、プラットフォームはNVD、CISA KEVカタログ、脅威アクターグループ、ボットネットを継続的にスキャンし、悪用可能性に関する知見を得ています。

サプライヤーのSBOMと連携機能。NetRiseはSPDXとCycloneDXのインポート、エンリッチ、正規化、エクスポートに対応しているため、複数のソースからのSBOMを統合できます。CI/CD向けにGraphQL APIを提供し、Jira、ServiceNow、Splunk、Armis、Brinqa、Nucleus Security、GitHub、Google Cloudとの連携を掲げています。

オープンソースの来歴。NetRise Provenanceは、オープンソースコンポーネントの出所、メンテナー、リポジトリの健全性を調べ、CI/CDやAIコーディングアシスタントを含め、開発者がパッケージを取得する場所で、悪意あるパッケージやポリシー違反のパッケージをブロックします。

現在はDragos傘下。Dragosの発表によれば、NetRiseはOT（運用技術）デバイス上で動作するファームウェアとソフトウェアの可視性をもたらし、NetRiseの経営陣は既存顧客へのサービスを継続しながら、それをDragos Platformに統合するとしています。買収金額などの条件は開示されていません。

CRACIの違い

バイナリ解析は、出荷されたものからさかのぼって分析します。CRACIはビルドから順を追って記録します。ビルドがCRACI上で実行されるからです。

ビルドこそが信頼できる情報源

runs-onを1行変更するだけで、ワークフローがCRACIのランナー上で実行されます。ジョブの実行中、パッケージを認識するプロキシがパッケージソースからダウンロードされたものを記録し、CIキャッシュから復元されたパッケージも引き継がれます。各SBOMには、ジョブごと・キャッシュごとに完全性の状態が示されます。状態はComplete、Complete with connections、Incomplete、Unavailable、Not recordedのいずれかです。Yoctoについては、CRACIは最大32 vCPU、96 GB RAMのランナーでBitBakeを実行します。core-image-satoを並べてビルドした比較では、CRACIのSBOMはYocto自身のSPDX出力に含まれるすべてのコンポーネントに加え、ホストパッケージやGitHub Actionsなど88件を追加で記録し、YoctoがパッケージURLなしで列挙する653のRustクレートのバージョンすべてにパッケージURLを付与しました。

ビルドがアクセスできる範囲の制御

ランナーのエグレスポリシーが、ジョブが接続できるホストを決めます。ポリシーはジョブ開始前に検証され、フェイルクローズで動作し、違反時にはアラートを送信します。出力をスキャンしても、ビルドがアクセスできた範囲は変えられません。

CVEから影響を受ける製品へ

CRACIはビルドとリポジトリをまたいで脆弱性を集約し、アドバイザリが公開されるたびに監視対象のSBOMを再評価し続けます。ビルド履歴から、脆弱な依存関係（直接・推移的を問わず）を含んでいたビルドがわかるため、影響を受けていた期間を把握でき、インベントリビューでは、どのソフトウェアバージョンがどの製品にデプロイされているかを正確に確認できます。セキュリティチームは検出結果をトリアージし、修正を担当するチームにそれぞれ振り分けます。VEXにも対応しており、ポリシーゲートで特定のCVEを含むビルドをブロックできます。APIからはSBOM、ネットワークトレース、来歴を取得できます。

CRACIが行わないことも同じくらい重要です。CRACIはバイナリを解析しないため、自社でビルドしていないファームウェアや、ビルドがダウンロードするサプライヤーのバイナリの中身は見えません。わかるのは、ビルドがそれを取得したことと、その取得元です。ベンダーのSBOMを追加すればそのコンポーネントも監視されますが、SBOMがない場合はNetRiseのようなバイナリ解析ツールが必要です。CRACIには到達可能性分析がなく、出力に含まれるシークレットや設定ミスも探しません。

PSIRTがそれぞれに求めるもの

製品セキュリティインシデント対応チーム（PSIRT）は、サードパーティのファームウェアを含め、すべての製品に何が含まれて出荷されているかを把握し、脆弱性が公開されたときに影響を受ける製品を特定し、リリース後も監視を続け、検出結果をトリアージし、影響を受けない製品を（多くの場合VEXで）示す必要があります。

• 受け取ったサードパーティのファームウェアとバイナリ。NetRiseです。サプライヤーがSBOMを提供しない場合、中身を見る方法はバイナリ解析しかありません。
• GitHub Actionsで自社ビルドするファームウェアとソフトウェア。CRACIは各ビルドを実行時に記録し、どのビルドにどのコンポーネントが含まれていたかの履歴を保持します。
• 大量の検出結果の優先順位付け。NetRiseの到達可能性と悪用可能性のシグナルです。CRACIが示すのは脆弱なパッケージがビルドに含まれていたことであり、自社のコードがそれを呼び出しているかどうかではありません。
• 検出結果を修正担当チームに振り分ける。CRACIのトリアージと振り分けは、CRACIが記録するビルドに対して機能します。NetRiseはJiraやServiceNowと連携します。

PSIRTチーム向けのCRACIとPSIRTツールの比較もご覧ください。

使い分けの目安と、併用すべき場合

• 出荷するものの大半をサプライヤーから調達している場合。NetRiseです。自社でビルドするソフトウェアだけでなく、購入したソフトウェアも解析します。
• 自社のLinuxイメージやアプリをGitHub Actionsでビルドしている場合。CRACIがビルドを実行し、その入力を記録します。同じイメージをNetRiseで解析すれば、出荷したものについて独立した2つ目の視点が得られます。
• OT（運用技術）デバイスのフリートを運用している場合。現在Dragos傘下のNetRiseは、そうしたデバイス上で動作するファームウェアとソフトウェアを対象としています。CRACIはソフトウェアをビルドするチーム向けです。
• ビルドがダウンロードできるものを制限したい場合。CRACIです。この制御は、ビルドが実行される場所でしか実現できません。

CRAへの対応

Cyber Resilience Actはメーカーに対し、SBOMを含めて製品のコンポーネントを文書化すること、サポート期間を通じて脆弱性に対処すること、そして2026年9月11日からは実際に悪用されている脆弱性を報告することを求めています。NetRiseは、コンパイル済みの成果物から生成するリリースビルドのSBOM、バージョンをまたいだ脆弱性対応とパッチ検証、適合性エビデンスのためのレポート出力でCRAに対応しています。CRACIは、自社でビルドするソフトウェアに何が含まれたかをビルドごとのエビデンスとして生成して監視し、CRAの通知の内容を作成します。提出はお客様が行います。CRACIは、メーカーがより広範なCRAコンプライアンスプロセスで必要とするソフトウェアサプライチェーンの可視性とエビデンスのかなりの部分を自動化しますが、それだけで製品が準拠するわけではありません。CRAの要件をご覧ください。

NetRiseと並行してCRACIを導入する

NetRiseから何かを移行する必要はありません。runs-on: craciを設定してビルドジョブをCRACIランナーに移すだけで、同じワークフローがGitHub Actionsで動き続け、CRACIがビルドを記録します。CRACIドキュメントのYoctoサンプルでBitBakeワークフロー全体を紹介しています。CRACIは現在GitHub Actionsのみに対応しており、GitLab CIとJenkinsはロードマップに掲載されています。産業用IoTでのCRACIの活用もご覧ください。

3つ以上のツールを検討している場合は、NetRiseの代替ツールで7つの選択肢を並べて比較しています。