CRACIとTimesys Vigilesの比較

結論

Vigilesは、Lynx Software Technologiesが2023年12月に買収したTimesysのSBOMおよび脆弱性管理製品で、現在はLynx Vigilesとして販売されています。組み込みLinux向けに作られており、Yoctoレイヤーのmeta-timesysがイメージ内のパッケージに関するメタデータを収集してアップロードし、Vigilesがそれを厳選されたCVEデータベースと照合します。その後、トリアージの判断を追跡し、SBOM、VEX、脆弱性レポートをエクスポートします。

CRACIはGitHub Actionsのランナーです。BitBakeビルドはCRACI上で実行され、その間にCRACIはビルドが取得したすべてのパッケージとソースを記録し、ビルドの接続先を制限し、SBOMの脆弱性を継続的に監視します。どちらの製品もYoctoイメージのSBOMとCVE監視を提供しますが、SBOMの情報源が異なります。VigilesはBitBakeのメタデータがイメージに入ると示すものを読み取ります。CRACIはビルドが実際に取り込んだものを記録します。

一覧で比較

Vigilesの強み

組み込みLinux向けの設計。Vigilesはmeta-timesysを通じてYoctoと連携するほか、Buildroot、OpenWrt、Timesys Factory、FreeRTOSとも連携し、それ以外のものについてはSPDX 2.2～3.0.1、CycloneDX 1.1～1.7、CSV形式のSBOMをインポートできます。Lynxによると、2019年にリリースされたVigilesはこれまでに90,000件を超えるSBOMを処理しています。

CVEのノイズを削減。Vigilesは公開データをそのまま使うのではなく、厳選されたCVEデータベースとコンポーネントを照合します。Lynxによれば、これにより公開データが生む誤検知の大半が除去されます。スキャナーはLinuxカーネルとU-Bootの.configファイル全体をアップロードできるため、ビルドしていない機能のCVEは除外されます。これは組み込みLinuxでは重要です。meta-timesysのREADMEにあるレポート例では、未修正のCVE 62件のうち60件がカーネルにあります。

リリースをまたいで残る判断。チームは各CVEについて、影響あり、修正済み、保留、悪用不可のいずれかを記録し、Vigilesはその判断をリリースごとに保持します。CISA Known Exploited Vulnerabilitiesを強調表示し、SBOMをCycloneDX、SPDX、SPDX Liteでエクスポートし、VEXと脆弱性レポートも出力します。レポートには、ビルド内のパッチですでに修正されたCVEや、meta-timesys-securityレイヤーで利用できるパッチも表示されます。Lynxは対応を支援する規格としてEU CRAとEO 14028を挙げており、VigilesはJiraおよびOktaと連携します。

CRACIが異なる点

VigilesのSBOMの完全性は、BitBakeがイメージをどう把握しているかに左右されます。meta-timesysのREADMEは、インストール予定のパッケージに関するメタデータを収集するものと説明しており、BitBakeの外でビルドされたパッケージや、BitBakeでビルドされてもルートファイルシステムのマニフェストに含まれないパッケージは手作業で列挙する必要があります。CRACIはメタデータを読み取りません。ビルドが実行されるマシンそのものです。

Yocto自身のSBOMに含まれないもの

当社はVigilesのSBOMとCRACIのSBOMを比較していません。比較したのは、同じくBitBakeのメタデータから生成されるYocto組み込みのSPDX SBOMとCRACIのSBOMです。32vCPUのARM64ランナーでcore-image-satoの比較ビルドを行った結果、CRACIのSBOMにはYoctoのSBOMにあるすべてのコンポーネントに加え、Yoctoが見落とした88件が含まれていました。Ubuntuのcpioなどビルドマシン上のホストパッケージ、GitHubのソースとGitHub Action actions/upload-artifact、その他ビルド中に取得されたソースやツールです。いずれもイメージにはインストールされませんが、すべてビルドのクリティカルパス上にあります。

どちらのSBOMにも同じ653個のRustクレートのバージョンが記載されていましたが、YoctoのSBOMはファイル名とダウンロードURLだけで記載し、パッケージURLがありません。脆弱性の照合はパッケージURLで行われるため、YoctoのSBOMからはこれらのクレートを監視できません。CRACIはそのすべてをpkg:cargoのパッケージURL付きで記録します。 イメージスキャナー、バイナリ解析、Yoctoのcve-checkの比較は、SBOMスキャナーがYoctoビルドの中身を見落とす理由をご覧ください。

ビルドが到達できる範囲を制御

ランナーのエグレスポリシーが、ジョブが接続できるホストを決めます。ポリシーはジョブの開始前に検証され、フェイルクローズで動作し、違反時にはアラートを送信します。Yoctoでは、BitBake自身のBB_ALLOWED_NETWORKSに加わる第2の防御層になります。デフォルト拒否のポリシーにより、侵害されたビルドツールがビルドに不要なホストへシークレットを送信することを防ぎます。

同じ記録から来歴と監視

APIはSBOM、ネットワークトレース、来歴を返します。CRACIは来歴に署名しません。CRACIはビルドとリポジトリをまたいで脆弱性を集約し、アドバイザリが公開されるたびに監視対象のSBOMを再評価し続けます。セキュリティチームは検出結果をトリアージして修正を担当するチームに振り分けられ、過去のどのビルドに脆弱な依存関係が含まれていたかも表示されるため、影響を受けていた期間がわかります。CRACIはVEXに対応しており、CRAの脆弱性通知の内容も準備します（提出はお客様が行います）。

ビルドそのものを、より大きなランナーで

Vigilesはビルドを実行しませんが、CRACIは実行します。Yoctoビルドは最大32vCPU、96GB RAMのランナーで実行され、秒単位で計測されて1vCPU分あたり$0.002（デフォルトの2vCPUランナーは$0.004）で課金されます。同じcore-image-satoの比較では、YoctoのSBOM生成を行わないビルドは、行うビルドより所要時間が43%短くなりました。

VigilesからCRACIへの置き換え

GitHub ActionsでビルドするYoctoイメージについては、CRACIはVigilesが導入される目的をカバーします。すべてのビルドのSBOM、リリース後のCVE監視、トリアージの判断、VEXです。さらに、メタデータベースのSBOMでは得られないもの、つまりビルドが使用したホストパッケージ、GitHubのソースとActions、そして実行中のエグレスポリシーが加わります。

失うものも明確にしておきます。Vigilesの厳選されたCVEデータと、カーネルおよびU-Bootの設定フィルターは、CRACIにはない方法でCVEのノイズを削減します。Vigilesはビルド内のパッチですでに修正されたCVEを報告しますが、CRACIはこれを記録しません。Yocto自身のSPDXにもこのレシピのメタデータが含まれるため、それに依存している場合はcreate-spdxを有効のままにしてください。VigilesはBuildroot、OpenWrt、FreeRTOSにも対応し、どのCIの中でも動作し、多くの形式のSBOMをインポートできます。CRACIが現在対応しているのはGitHub Actionsのみで、GitLab CIとJenkinsはロードマップに掲載されています。そのため、JenkinsやGitLabのパイプラインは先にGitHub Actionsへ移行する必要があります。

CRAへの対応

Cyber Resilience Actは、メーカーに対し、SBOMを含む製品のコンポーネントを文書化し、製品のサポート期間中は脆弱性に対処することを求めています。報告義務は2026年9月から適用されます。VigilesはSBOM、CVEの判断、レポートをリリースごとに保持することで支援します。CRACIは、ファームウェアに何が入ったかを示すビルドごとのエビデンスを、来歴、継続的な監視、CycloneDXまたはSPDXでのSBOMエクスポートとともに生成します。メーカーがより広いCRAプロセスに必要とするソフトウェアサプライチェーンの可視性とエビデンスのかなりの部分を自動化しますが、どちらのツールも単独で製品をコンプライアンスに適合させるものではありません。CRAの要件をご覧ください。

YoctoビルドをCRACIに移行する

BitBakeジョブにruns-on: craciを設定し、ランナーのサイズを選ぶだけです。ワークフローは引き続きGitHub Actionsで実行されます。CRACIドキュメントのYoctoの例では、最大サイズでcore-image-satoをビルドしています。産業用IoTやコンシューマーエレクトロニクスでCRACIがどのように機能するかもご覧ください。