CRACI vs Cybellum

要点

Cybellumは、自動車、医療、産業分野のデバイスメーカー向けの製品セキュリティプラットフォームです。ファームウェアバイナリを解析し、ソースコードやサプライヤーのSBOMと統合したうえで脆弱性データと照合し、出荷後のPSIRT業務（監視、トリアージ、調査、規制対応のエビデンス）を支援します。CRACIはGitHub Actionsランナーであり、各ビルドが実行中に取り込むものを記録し、その記録からSBOMを生成して、継続的に監視します。

あらゆるPSIRT案件で最初に問われるのは、脆弱なコンポーネントを含む製品とバージョンはどれか、という点です。Cybellumは、出荷するものを解析することで、その出所にかかわらずこの問いに答えます。CRACIは、自社のビルドが実際に取得したものの記録から答えます。GitHub Actionsでビルドするソフトウェアについては、CRACIがインベントリ、監視、トリアージそのものまでカバーします。バイナリで受け取るファームウェアについては、CRACIが対応しない領域をCybellumがカバーします。

一覧で比較

Cybellumの強み

バイナリの解析。CybellumのCyber Digital Twinsは「あらゆる製品やコンポーネントのバイナリファイルから抽出できる」とされています。プラットフォームは各製品のファームウェアバイナリを解析して「SBOM、バージョン履歴、ライセンス、ハードウェアアーキテクチャ、OS構成など」を明らかにし、「ソースコードもお持ちですか？」と問うのはあくまで追加の情報としてです。車両や医療機器のコードの多くが、ビルドを一切見ることのできないサプライヤー製である場合、この点は重要です。

多様なソースから1つのSBOMへ。Cybellumは「バイナリスキャナー、ソースコード、SPDX、CycloneDX、CPE CSV形式の外部SBOMソースのデータ」を統合し、同一パッケージの重複を排除します。チームはあらゆる製品、バージョン、ブランチのSBOMを自動修正、検証、承認したうえで、SPDXまたはCycloneDXとして共有できます。

既知のCVE以外の検出。Cybellumの脆弱性データベースは、公開および非公開のフィード、EPSS、リサーチによる知見を組み合わせており、さらに「マルウェアとコーディング上の弱点を検出する組み込みエンジン」を備えています。チームは脅威モデル、TARA、ファジングやペネトレーションテストの結果を取り込み、AIアシスタント「VM CoPilot」でトリアージできます。

PSIRT業務のための設計。インシデント対応モジュールでは、チームが「新たな脆弱性や規制の影響を受ける製品やコンポーネントを正確に把握」でき、「調査を作成・管理するためのワークベンチ」が提供されます。チケットを発行し、脆弱性のステータスを「必要に応じてVEX/CSAFレポートで」共有できます。

規制対応のエビデンス。Cybellumは「FDA PMA、ISO 21434、CRA、さらに独自のカスタムポリシーフレームワーク」のエビデンスを管理し、「50以上の標準、規制、ベストプラクティス」の要件をあらかじめマッピングしています。パブリッククラウドでも自社データセンターでも稼働します。LG Electronicsは2021年にCybellumの過半数株式を取得しましたが、Cybellumは独自ブランドとして事業を継続しています。

CRACIの違い

Cybellumの出発点は成果物です。ファームウェアイメージ、ソースツリー、サプライヤーから届いたSBOMです。CRACIの出発点はビルドそのものです。ビルドがCRACI上で実行されるからです。

推測ではなく観測

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

CVEが到達したビルドと製品

CRACIは過去のすべてのビルドをSBOMとともに保持しています。そのため、アドバイザリが公開されたときに、脆弱な依存関係（直接・推移的を問わず）を含んでいたビルドと、その期間を、保持期間内で確認できます。インベントリビューでは、どのソフトウェアバージョンがどの製品にデプロイされているかを、グローバルに正確に把握できます。CRACIは監視対象のSBOMを継続的に再評価し、VEXに対応し、セキュリティチームが検出結果をトリアージして、修正を担当するチームにそれぞれ振り分けられるようにします。ベンダーのSBOMを追加できるため、購入したコンポーネントも自社のビルドと並べて監視されます。

ビルド中の制御

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

CRACIを選ぶ場合に諦めるもの

CRACIはバイナリを解析しないため、ビルドがダウンロードするサプライヤーのバイナリの中身はわかりません。わかるのは、ビルドがそれを取得したことと、その取得元です。ゼロデイの探索は行わず、ソースコードのコーディング上の弱点のスキャンは対象範囲外で、標準に対するガイド付きチェックやレポートのエクスポートもありません。現在はGitHub Actionsのみに対応しており、GitLab CIとJenkinsはロードマップに掲載されています。欧州のインフラ上のマネージドランナーとして稼働し、顧客ホスト型ランナーはロードマップに掲載されています。

使い分けの目安

• ファームウェアの大半をサプライヤーからバイナリで受け取っている場合。Cybellumです。バイナリの中身を見るには、バイナリの解析が必要です。
• 自社のソフトウェアとイメージをGitHub Actionsでビルドしている場合。CRACIがビルドを実行してその入力を記録し、記録した内容の脆弱性を追跡するため、PSIRTのインベントリはビルドそのものから得られます。
• 自動車や医療機器の規制申請のためにエビデンスが必要な場合。CybellumにはFDA PMA、ISO 21434、EU CRA向けの規制テンプレートがあります。CRACIはSBOMをCycloneDXまたはSPDXでエクスポートし、APIからSBOM、ネットワークトレース、来歴を取得できるため、より広範なプロセスに活用できます。
• ビルドがダウンロードできるものを制限したい場合。CRACIです。この制御は、ビルドが実行される場所でしか実現できません。

CRAへの対応

Cyber Resilience Actはメーカーに対し、SBOMを含めて製品のコンポーネントを特定・文書化すること、サポート期間を通じて脆弱性に対処すること、そして2026年9月からは積極的に悪用されている脆弱性を報告することを求めています。Cybellumは、製品やサプライヤーをまたいだCRAテンプレートとエビデンスで支援します。CRACIは、自社でビルドするソフトウェアに何が含まれたかをビルドごとのエビデンスとして生成し、継続的な監視とCycloneDXまたはSPDXでのSBOMエクスポートを提供するとともに、CRAの通知の内容を作成することで支援します（提出はお客様が行います）。CRACIは、メーカーがより広範なCRAコンプライアンスプロセスで必要とするソフトウェアサプライチェーンの可視性とエビデンスのかなりの部分を自動化しますが、それだけで製品が準拠するわけではありません。CRAの要件をご覧ください。

CRACIでビルドを実行する

ビルドジョブをruns-on: craciに向けるだけで、同じワークフローがGitHub Actionsで動き続け、CRACIがそれを記録します。Yoctoについては、CRACIドキュメントのサンプルでBitBakeワークフロー全体を紹介しています。産業用IoTやコンシューマーエレクトロニクスでのCRACIの活用もご覧ください。

この役割が初めての方は、PSIRTの役割とPSIRTチーム向けのCRACIをご覧ください。3つ以上のツールを検討している場合は、PSIRTツールの比較とCybellumの代替ツールをご覧ください。