CRACIとExeinの比較

結論

Exeinは、組み込み機器やコネクテッドデバイス向けのセキュリティ製品を提供しています。Exein Runtimeはデバイス上で脅威を監視・ブロックし、Exein Analyzerはリリース前にファームウェアの脆弱性をスキャンします。同社のYoctoレイヤーであるmeta-exeinは、ランタイムエージェントをイメージに組み込みます。CRACIはGitHub Actionsのランナーです。Yoctoビルドはその上で実行され、CRACIはビルドがダウンロードしたものを記録し、接続先を制限します。Exeinはデバイスとファームウェアを対象とし、CRACIはビルドを対象とします。両方が必要なチームの多くは、両方を使うことになるでしょう。

一覧で比較

ExeinのYocto連携とは

どちらもYoctoに言及しているため2つの製品は混同されやすく、正確に区別しておく価値があります。meta-exeinはオープンソースのYoctoレイヤーで、「Pulsarセキュリティフレームワークをイメージに追加するためのPulsarおよびカーネルのレシピを含む」ものです。このレイヤーをbblayers.confに追加し、pulsarをIMAGE_INSTALLに追記してBTFを有効にすると、ExeinのeBPFベースのランタイムセキュリティツールであるPulsarを含むイメージが出荷されます。このレイヤーはKirkstone以降のYoctoリリースでテストされており、2024年にYocto Project Compatibleの公式レイヤーとなりました。Exeinは2023年にPlatinum MemberとしてYocto Projectに参加しています。

つまり、Exeinのレイヤーはデバイス上で動作するものを変えるものです。ビルドを実行したり、ビルドが取得したものを記録したりはしません。またExeinは、Exein Analyzerが「Yocto、Buildroot、そしてお客様のCI/CDパイプラインにネイティブに統合されている」とし、新しいビルドごとにスキャンするとしています。これは、お客様自身のパイプライン内でビルドの出力を解析するものです。

Exeinの強み

デバイス上での実行時保護。Exein RuntimeはRustで書かれており、eBPFを使ってカーネルレベルで悪意ある挙動を監視・ブロックします。「実行しようとしたその瞬間に」です。フリート全体でインシデントを追跡し、実行時のテレメトリからフォレンジックおよびコンプライアンスのレポートを生成します。またExeinは、「eBPFを活用した、IoT向けのモジュール式で非常に高速なランタイムセキュリティツール」であるPulsarをオープンソースで公開しています。

リリース前のファームウェア解析。Exein Analyzerは最終的なファームウェアを直接検査し、バイナリが入手できない場合はSBOMを取り込みます。ExeinによればLinux、RTOS、Docker、UEFI、Androidなどに対応しており、到達可能性スコアリングとLLMによる絞り込みで、悪用可能なCVEを優先します。

修正とCRAへのマッピング。Exeinは、YoctoやCI/CDパイプライン内で動作するAI駆動の修正機能を掲げており、検出結果をCyber Resilience Actの要件にマッピングします。

CRACIの違い

ビルドを実行する

Yoctoビルドは長時間かかり、負荷も高いものです。CRACIはGitHub ActionsワークフローからBitBakeを、最大32vCPU・RAM 96GBのランナーで実行します。設定はcracicorp/setup@v1とsize: "32"で行います。ジョブは隔離された仮想マシンで実行され、実行結果はこれまでどおりGitHubに表示されます。

ビルドが取得したものを記録する

ジョブの実行中、CRACIはパッケージホストやソースホストへの通信を観測し、ジョブごと・キャッシュごとの完全性の状態とともにビルドのエビデンスとして保存します。Yoctoにとっては、ネットワーク経由で取得されたものの独立した記録となり、Yoctoのcreate-spdxクラスが生成するSPDX SBOMから漏れるものも含まれます。core-image-satoを並べてビルドした比較では、CRACIのSBOMはYoctoのSBOMにあるすべてのコンポーネントに加え、ホストパッケージやGitHub Actionsなど88個多くのコンポーネントを含み、YoctoがパッケージURLなしで記載していた653のRustクレートのバージョンすべてにパッケージURLを付けていました。BitBakeがYoctoソースミラーから取得したソースは、CRACIのジョブSBOMに記録されます。 イメージスキャナーとYocto独自のツールの比較は、SBOMスキャナーがYoctoビルドの中身を見落とす理由をご覧ください。

ビルドの接続先を制御する

BitBakeはBB_ALLOWED_NETWORKSでフェッチャーを制限できます。CRACIはこれに加えてランナーでエグレスポリシーを適用します。ポリシーはジョブ開始前に検証され、フェイルクローズで動作するため、フェッチャーを迂回するスクリプトやツールも、許可していないホストには到達できません。違反があればCRACIがアラートを通知します。

出荷したものを監視する

APIはSBOM、ネットワークトレース、来歴を返します。CRACIはビルドとリポジトリをまたいで脆弱性を集約し、監視対象のSBOMを継続的に再評価します。

CRACIはデバイスに何も配置せず、バイナリも解析しません。実行時保護や完成したイメージのスキャンが必要なら、それはExeinの領域です。

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

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

使い分けと併用

• 現場のデバイスで脅威の検出とブロックを行いたい。Exein Runtimeです。CRACIにはデバイス上のコンポーネントがありません。
• Yoctoビルドを机の下のサーバーで実行している、または小さなCIランナーで何時間もかかっている。CRACIはGitHub Actionsからビルドを実行し、それぞれの記録を残します。
• meta-exeinを含むYoctoイメージを出荷している。CRACIでビルドしてください。このレイヤーは他のレイヤーと同じようにビルドされ、CRACIはビルドが取得したものを記録します。
• SBOMの出どころを示す必要がある。CRACIのランナーの記録は、SBOMを特定のビルドに結び付けます。Exein Analyzerによる出力のスキャンは、有用なもう1つの視点になります。

CRAへの対応

Cyber Resilience Actはメーカーに対し、SBOMを含めて製品のコンポーネントを文書化すること、サポート期間を通じて脆弱性に対処すること、そして2026年9月からは積極的に悪用されている脆弱性を報告することを求めています。Exeinはデバイス側を支援し、リリース前のファームウェア解析、CRAのエビデンスのマッピング、現場からの実行時テレメトリを提供します。CRACIはビルド側を支援し、ファームウェアに何が入ったかのビルドごとのエビデンス、来歴、継続的な監視、CycloneDXまたはSPDXでのSBOMエクスポートを提供します。CRAの通知の内容も準備し、提出はお客様がSingle Reporting Platformを通じて行います。CRACIは、メーカーがより広範なCRAコンプライアンスのプロセスで必要とするソフトウェアサプライチェーンの可視性とエビデンスのかなりの部分を自動化しますが、それだけで製品が準拠するわけではありません。CRAの要件をご覧ください。

YoctoワークフローへのCRACIの追加

meta-exeinを含むレイヤーも、Exein Analyzerのステップもそのまま残します。ビルドジョブにruns-on: craciを設定し、ランナーのサイズを選ぶだけです。CRACIドキュメントのYoctoの例では、core-image-satoを、公式のYoctoソースミラーと、それに合わせたBB_ALLOWED_NETWORKSの設定でビルドします。CRACIが現在対応しているのはGitHub Actionsのみで、GitLab CIとJenkinsはロードマップに掲載されています。産業用IoTやコンシューマーエレクトロニクスでのCRACIの活用方法もご覧ください。