CRACIとONEKEYの比較

結論

ONEKEYは、コネクテッドデバイス向けの製品サイバーセキュリティおよびコンプライアンスプラットフォームです。ファームウェアイメージをアップロードすると、バイナリを解析してコンポーネント、既知の脆弱性、ゼロデイの可能性、コンプライアンス上のギャップを、ソースコードなしで見つけます。CRACIはGitHub Actionsのランナーで、各ビルドが実行中に取り込むものを記録し、その記録からSBOMを生成します。ONEKEYは出力を解析し、CRACIはビルドのエビデンスを残します。両者はうまく組み合わせられ、どちらかがもう一方を置き換えるものではありません。

一覧で比較

ONEKEYの強み

ソースコードなしのバイナリ解析。ONEKEYはコンパイル済みのファームウェアを直接解析します。同社のサイトには端的に「ソースコードもネットワークアクセスも不要」と書かれています。デバイスで出荷されるものの多くがチップベンダー、モジュールサプライヤー、委託先から来ており、そのビルドを見る機会がない場合、これは重要です。

既知のCVEを超える検出。ONEKEYは、コンポーネントを脆弱性データと照合するだけでなく、自動化されたゼロデイ解析も実行し、バイナリ内のコマンドインジェクション、安全でない通信、ハードコードされた認証情報などの問題を探します。

イメージからのSBOM。ONEKEYはバイナリからSBOMを生成し、ソーススキャナーやサプライヤーからのSBOMを取り込むこともでき、CycloneDXとSPDXをエクスポートします。

コンプライアンスのガイダンス。ONEKEY Compliance Wizardは、Cyber Resilience Act、IEC 62443-4-2、ETSI EN 303 645、Radio Equipment Directiveの要件をチームに順を追って案内し、第三者認証のために結果をエクスポートします。

監視とCI。ファームウェア監視機能は、新たな脆弱性の出現に応じて、アップロードされたファームウェアを毎日再解析します。ONEKEYのドキュメントでは、GitHub、GitLab、Jenkinsから新しいビルドを毎回アップロードし、新たな検出結果があればパイプラインを失敗させる方法が示されています。ONEKEYは、バイナリブロブ向けのオープンソース展開ツール群であるunblobも保守しています。

CRACIの違い

バイナリスキャンは、完成したイメージからさかのぼって調べます。CRACIはビルドが実行されるマシンそのものなので、ビルドから順に記録していきます。Yoctoイメージについては、SBOMスキャナーがYoctoビルドの中身を見落とす理由をご覧ください。

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

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を付けていました。BitBakeがYoctoソースミラーから取得したソースは、CRACIのジョブSBOMに記録されます。

ビルドの到達先を制御

ランナーでのエグレスポリシーが、ジョブが接続できるホストを決めます。ポリシーはジョブ開始前に検証され、フェイルクローズで動作し、違反時にはアラートを送信します。Yoctoでは、BitBake自身のBB_ALLOWED_NETWORKSに第2の防御層を加えます。

来歴と出荷したもの

APIはSBOM、ネットワークトレース、来歴を返します。CRACIは来歴に署名しません。ビルドとリポジトリをまたいで脆弱性を集約し、アドバイザリの公開に応じて監視対象のSBOMを再評価し続けます。

ここでは、CRACIが行わないことも同じくらい重要です。CRACIはバイナリを解析しないため、ビルドがダウンロードしたサプライヤーのブロブの中身はわかりません。わかるのは、ビルドがそれを取得したことと、その取得元です。

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

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

使い分けと併用

• 自社でビルドしていないファームウェアを組み込んでいる。ONEKEYです。中身を見るにはバイナリ解析が必要です。
• GitHub Actionsで自社のLinuxイメージをビルドしている。CRACIがビルドを実行し、その入力を記録します。ONEKEYを加えれば、完成したイメージについて独立した第2の視点が得られます。
• SBOMが製品と一致していることをどう確認しているのか、監査人に問われた。CRACIのランナーの記録は「このビルドに何が入ったか」に答え、ONEKEYの解析は「このイメージに何が入っているか」に答えます。両者を合わせれば相互に検証できます。
• IEC 62443やETSI EN 303 645に沿ったガイド付きチェックが必要。ONEKEYにはそれが組み込まれています。CRACIはより広範なプロセスのために、SBOMをCycloneDXまたはSPDXでエクスポートし、APIでネットワークトレースと来歴を返します。

CRAへの対応

Cyber Resilience Actはメーカーに対し、SBOMを含めて製品のコンポーネントを特定・文書化し、製品のサポート期間中は脆弱性に対処することを求めています。積極的に悪用されている脆弱性の報告は2026年9月から適用されます。ONEKEYは、市場に投入するファームウェアを解析し、要件を案内することで支援します。CRACIは、そのファームウェアに何が入ったかのビルドごとのエビデンスを、来歴と継続的な監視とともに生成することで支援します。CRACIは、メーカーがより広範なCRAコンプライアンスのプロセスで必要とするソフトウェアサプライチェーンの可視性とエビデンスのかなりの部分を自動化しますが、それだけで製品が準拠するわけではありません。CRAの要件をご覧ください。

ONEKEYとCRACIの併用

ONEKEYへのアップロードステップはそのまま残します。runs-on: craciを設定してファームウェアのジョブをCRACIランナーに移すと、同じワークフローはGitHub Actionsで実行され続け、CRACIがビルドを記録します。これにより、ONEKEYへのアップロードはエビデンスのあるビルドから行われるようになります。CRACIドキュメントのYoctoの例では、BitBakeワークフロー全体を紹介しています。CRACIが現在対応しているのはGitHub Actionsのみのため、GitLabやJenkinsのパイプラインでCRACIランナーを使うには移行が必要です。GitLab CIとJenkinsはロードマップに掲載されています。産業用IoTやコンシューマーエレクトロニクスでのCRACIの活用方法もご覧ください。

3つ以上のツールを比較検討していますか？ONEKEYの代替ツールでは、9つの選択肢を並べて比較しています。