CRACIとFinite Stateの比較

結論から

Finite Stateは、コネクテッドデバイス向けの製品セキュリティプラットフォームです。ファームウェア、バイナリ、ソースコード、サプライヤーのSBOMを解析し、到達可能性によって脆弱性に優先順位を付け、その結果をCRAなどの規制向けのエビデンスにまとめます。CRACIはGitHub Actionsのランナーで、各ビルドが実行中に取り込むものを記録し、その記録からSBOMを作成し、ビルドの接続先を制御します。Finite Stateは出荷するものを、その出どころを問わず解析します。CRACIは自社のビルドが何をしたかを記録します。両者は大部分で補完し合う関係です。

一覧で比較

Finite Stateが得意なこと

バイナリとファームウェアのカバー範囲。Finite Stateは、ファームウェア、バイナリ、ソースコードにわたってSBOMとソフトウェアインベントリを作成し、「50以上のバイナリ命令セットアーキテクチャに対応」しています。多数のベンダーのコードを特殊なチップ上で動かすデバイスにとっては、この幅広さこそが重要です。

サプライヤーをまたぐ1つの記録。ファームウェア、バイナリ、ソースコード、サプライヤーのSBOM、サードパーティの検出結果を1つのプラットフォームに集約します。サプライヤーの申告内容と製品に実際に含まれるものを突き合わせる必要があるときに役立ちます。

ノイズの削減。Finite Stateは、到達可能性、エクスプロイト情報、製品のコンテキストに基づいて検出結果を順位付けします。同社によると、2024年以降に到達可能性を分析した検出結果のうち40.5%が到達不能と確認されました。VEXの判断は、製品への影響と悪用可能性のステータスとともに記録されます。

コンプライアンスのエビデンス。コンプライアンスのワークフローはEU CRAのコントロールマッピングとエビデンスの維持をカバーし、SBOMとVEXの成果物を含む監査対応レポートを生成します。FDAガイダンス、UN R155、IEC 62443などのフレームワークにも対応しています。

CI連携。Finite Stateは、GitHub Actions、GitLab CI、Jenkinsにチェックを組み込めます。Binary Scanアクションは、CIでビルドしたバイナリをFinite Stateのプラットフォームにアップロードし、クイックスキャンまたはフルスキャンを実行します。

CRACIの違い

Finite Stateの出発点は成果物です。完成したバイナリ、ソースツリー、サプライヤーから届いたSBOMなどです。CRACIの出発点はビルドそのものです。ビルドがCRACI上で実行されるからです。

推測ではなく観測

runs-onをcraciに変更すると、ジョブはCRACIランナー上の分離された仮想マシンで実行されます。パッケージを認識するプロキシがジョブのパッケージソースからのダウンロードを記録し、CIキャッシュから復元されたパッケージも引き継がれます。各SBOMには、ジョブごと・キャッシュごとに、Complete、Complete with connections、Incomplete、Unavailable、Not recordedのいずれかで完全性が示されます。ファームウェアチームは、最大32 vCPU、96 GBのRAMを備えたランナーでYoctoを実行できます。BitBakeがYoctoのソースミラーから取得するソースは、CRACIのジョブSBOMに記録されます。 完成したYoctoイメージのスキャンとの比較は、SBOMスキャナーがYoctoビルドの中身を見落とす理由をご覧ください。

ビルド中の制御

出力をスキャンしても、ビルドがアクセスできた範囲は変えられません。CRACIのエグレスポリシーなら変えられます。デフォルトで拒否または許可を選べ、ジョブ開始前に検証され、フェイルクローズで動作し、違反時にはアラートを送信します。

来歴と監視

APIからSBOM、ネットワークトレース、来歴を取得できます。CRACIはビルドとリポジトリをまたいで脆弱性を集約し、アドバイザリが公開されるたびに監視対象のSBOMを再評価し続けます。

CRACIはバイナリの解析や到達可能性分析は行いません。ビルドの記録はCRACI上で実行されるビルドが対象で、ベンダーが提供するSBOMを追加することもできます。SBOMなしでバイナリとして受け取るサプライヤーのファームウェアについては、CRACIがカバーしない領域をFinite Stateがカバーします。

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

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

どちらを使うべきか、両方を使うべきか

• ファームウェアの大半をサプライヤーから調達している場合。Finite Stateです。バイナリ解析とサプライヤーのSBOMの取り込みは、まさにそのために作られています。
• 自社のイメージやアプリをGitHub Actionsでビルドしている場合。CRACIが各ビルドを記録します。同じ成果物をFinite Stateにアップロードすれば、ビルドの記録とバイナリ解析を並べて確認できます。
• 多数の製品とサプライヤーを管理する記録システムが必要な場合。Finite Stateです。CRACIのSBOMはCycloneDXまたはSPDXでエクスポートでき、Finite Stateはアップロードアクションを通じてこれらのフォーマットを受け付けます。
• ビルドがダウンロードできるものを制限したい場合。CRACIです。この制御は、ビルドが実行される場所にしか存在しません。

CRAへの対応

Cyber Resilience Actはメーカーに対し、SBOMを含めて製品のコンポーネントを特定・文書化すること、サポート期間を通じて脆弱性に対処すること、そして2026年9月からは積極的に悪用されている脆弱性を報告することを求めています。Finite Stateは、CRAのコントロールマッピングとレポートにより、製品とそのサプライヤーにわたるエビデンスの整理を支援します。CRACIは、自社でビルドするソフトウェアに何が入ったかをビルドごとのエビデンスとして作成し、来歴、継続的な監視、CycloneDXまたはSPDXでのSBOMエクスポートを提供することで支援します。CRACIは、メーカーがより広いCRAコンプライアンスのプロセスに必要とするソフトウェアサプライチェーンの可視性とエビデンスのかなりの部分を自動化しますが、それだけで製品がコンプライアンスを満たすわけではありません。CRAの要件をご覧ください。

Finite StateとCRACIを併用する

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

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