Ripple20
デバイスメーカーが長年にわたり、しばしば別の名前でライセンスを受けて使っていた小さなTCP/IPライブラリに、CVSS最大10.0の脆弱性が19件見つかりました。このライブラリは多くのベンダーの製品に組み込まれており、その多くはまず、自社がそれを出荷しているかどうかを調べる必要がありました。
出荷していると知らないコンポーネントにはパッチを当てられません。
コンシューマー機器のサイバーセキュリティ
すべてのスマートデバイスは、オープンソースパッケージ、チップベンダーのSDK、ビルド中に取得したツールから作られたファームウェアを搭載して出荷されます。サプライチェーン攻撃に必要なのは、そのうちの1つだけです。CRACIはファームウェアのビルドを実行し、入るすべてのコンポーネントを記録し、ビルドが不要なものに到達できないようにします。
デバイスメーカーがサプライチェーン攻撃の標的になる理由
コネクテッドデバイスのコードの大部分は他者が書いたものです。組み込みLinuxディストリビューション、チップベンダーのボードサポートパッケージ、ネットワークスタック、数百のオープンソースライブラリ、その下にあるRustクレートなどです。同じコンポーネントが多くのブランドの製品で出荷され、デバイスは何年も家庭で使われ続け、誰かが最後に中身を確認してから長い時間がたっていることもよくあります。
そのため、1つの弱いコンポーネントは攻撃者にとって大きな価値を持ちます。共有ライブラリやSDKの欠陥は、それを出荷するすべての製品への入り口となり、汚染されたリリースはそれを取り込むすべてのビルドに到達します。以下のインシデントがそのパターンを示しています。
Realtek SDK
チップベンダーのSDKの欠陥が、約65社のメーカーの約200機種に及びました。ルーター、IPカメラ、スマート照明のゲートウェイ、コネクテッド玩具などです。詳細が公開された2日後には、Miraiボットネットがそれらを探してスキャンしていました。
チップベンダーのコードも、自社のデバイスで出荷すれば自社のコードです。
xz utilsのバックドア
アップストリームのxzプロジェクトそのものの、バージョン5.6.0と5.6.1にバックドアが仕込まれました。組み込みLinuxのイメージは、xzのような圧縮ライブラリを当然のように取り込み、通常は誰かが意識して選んだわけでもありません。
信頼されたオープンソースも、1つのリリースで敵に変わり得ます。
ShadowHammer
攻撃者はASUS自身の署名証明書を使って、バックドアを仕込んだアップデートユーティリティに署名し、公式のアップデートサーバーから配信しました。Kasperskyは、100万人を超えるユーザーに届いた可能性があると推定しています。
有効な署名が証明するのは誰が署名したかであり、何が入っているかではありません。
コンシューマー機器のサイバーセキュリティを強化する方法
セキュアブート、デフォルトパスワードの廃止、デバッグポートの閉鎖といったデバイスの堅牢化は、出荷するデバイスを守ります。以下のステップは、その中に入るものを守ります。
- すべてのファームウェアイメージの中身を把握する. 出荷するすべてのビルドについて、推移的依存関係、ホストツール、ビルドが途中で取得したソースを含むSBOMを保持します。SBOMがなければ、新しいアドバイザリが出るたびに、まず何日もかけて調べることから始めなければなりません。
- サプライヤーのコードを自社製品の一部として扱う. ボードサポートパッケージ、チップベンダーのSDK、ライセンスを受けたスタックにも、自社のコードと同じトラッキングが必要です。サプライヤーにSBOMを求め、自社のビルドと並べて監視します。
- デバイスの出荷後も監視を続ける. デバイスは何年も家庭で使われ続けます。新たな脆弱性が公開されるたびに、出荷した各バージョンの中身を確認し直し、どの製品とバージョンがいつから影響を受けているかを把握します。
- ビルドを堅牢にする. ビルドマシンには、ソースコード、シークレット、そしてリリースそのものがあります。各ビルドを新しい隔離されたマシンで実行し、CIのアクションをコミットに固定し、外向きの接続はビルドに必要なソースのみに許可します。
- 問題が判明しているバージョンを締め出す. 脆弱なリリースや悪意あるリリースが判明したら、それを含むビルドをすべてブロックし、依存関係の更新を通じて再び入り込まないようにします。
- 署名鍵とアップデートチャネルを保護する. セキュアブートと署名付きアップデートが役立つのは、鍵が安全に保たれている場合だけです。署名鍵はビルドとは切り離してハードウェアベースのストアに保管し、それを使える人やシステムを限定します。
- 脆弱性対応プロセスを整える. 誰が検出結果をトリアージし、誰が各修正を担当し、顧客と当局にどのように知らせるかを決めておきます。EUでは、Cyber Resilience Actにより、2026年9月11日から脆弱性の報告が製造業者の法的義務になります。
CRACIはこのリストのうちビルド側をカバーします。すべてのビルドのSBOM、サプライヤーのSBOM、継続的な監視、ビルドの隔離、エグレス制御、ポリシーゲートです。署名とデバイスの堅牢化は、引き続き自社のツールで行います。
何が入ったかを記録するファームウェアビルド
Yoctoをはじめとする組み込みLinuxのビルドを、x86-64またはネイティブARM64、最大32vCPUのCRACIのGitHub Actionsランナーで実行できます。ビルドの実行中、CRACIはホストパッケージ、Gitソース、GitHub Actions、どのレシピやロックファイルにも載らないダウンロードを含め、ビルドが取り込むすべてのパッケージとファイルを記録します。core-image-satoのビルドでは、CRACIのSBOMにはYocto自身のSBOMに含まれるすべてのコンポーネントに加え、Yoctoが見逃した88件が含まれ、653個のRustクレートバージョンすべてにパッケージURLが付いていたため、そのすべてを脆弱性について監視できます。
必要な接続先にしか到達できないビルド
各ジョブは独自の隔離された仮想マシンで、ジョブ開始前に検証されフェイルクローズするエグレスポリシーのもとで実行されます。デフォルト拒否のポリシーなら、ビルドが到達できるのは自社のパッケージソースだけです。侵害された依存関係が署名用の鍵情報やトークンを攻撃者のホストに送ろうとしても、たとえ新しい攻撃でまだ誰もアドバイザリを公開していなくても、ブロックされてアラートが上がります。
サプライヤーのコンポーネントも自社のものと並べてトラッキング
チップベンダーやその他のサプライヤーのSBOMを追加すれば、購入したコンポーネントも自社でビルドしたソフトウェアと並べて監視されます。次にSDKの脆弱性が見つかったときも、ベンダーのコードは自社のコードと同じ記録にあります。
どのデバイスが、いつから影響を受けているか
CRACIは、新たな脆弱性が公開されるたびに監視対象のSBOMを再評価し続けます。ビルド履歴からは、直接か推移的かを問わず脆弱な依存関係を含んでいたビルドが、インベントリビューからはどのソフトウェアバージョンがどの製品にデプロイされているかがわかります。セキュリティチームは各検出結果をトリアージして修正を担当するチームに割り当て、ポリシーゲートで特定のCVEを以降のすべてのビルドから締め出せます。
Cyber Resilience Actのためのエビデンス
Cyber Resilience ActのもとでのCEマーキングは、技術文書と適合性評価に基づきます。CRACIは、その文書に必要なサプライチェーンのエビデンスを提供します。CycloneDXまたはSPDXでエクスポートするビルド時SBOM、脆弱性の記録、ビルド履歴です。さらにCRACIは、お客様が提出するCRAの脆弱性通知の内容を準備します。適合性評価、EU適合宣言、CEマーキングは、製造業者であるお客様の役割として残ります。
CRACIが行わないこと
CRACIはファームウェア、SBOM、来歴に署名せず、挙動やレピュテーションに基づいて新しい悪意あるパッケージを検出することもありません。CVE付きのアドバイザリが存在すれば悪意あるリリースとして指摘し、それまではエグレスポリシーで対処します。適合性評価の実施や適合宣言書の作成も行いません。現在はLinuxランナーでGitHub Actionsのジョブを実行しており、GitLab CI、Jenkins、WindowsとmacOSのランナーはロードマップに掲載されています。
コンシューマー機器のセキュリティを解説
コネクテッドデバイスとそのソフトウェアサプライチェーンの保護に関するよくあるご質問
コンシューマー機器に対するサプライチェーン攻撃とは何ですか？
デバイスそのものではなく、メーカーが依存しているものを通じてデバイスに到達する攻撃です。脆弱なオープンソースライブラリ、チップベンダーのSDK、汚染されたパッケージのリリース、侵害されたビルドツール、乗っ取られたアップデートチャネルなどが経路になります。同じコンポーネントが多くの製品で出荷されるため、1つの弱点が多数のブランドの何百万台ものデバイスに一度に及ぶことがあります。
コンシューマー機器のサイバーセキュリティはどのように強化しますか？
まず出荷するものから始めます。すべてのファームウェアビルドのSBOMを保持し、サプライヤーのコンポーネントをトラッキングし、新たな脆弱性が現れるたびに出荷済みのバージョンを確認し続けます。ビルドそのものを堅牢にし、ポリシーゲートで問題が判明しているバージョンを締め出し、署名鍵を保護し、トリアージ、修正、開示のプロセスを整えます。セキュアブートやデフォルトパスワードの無効化といったデバイスの堅牢化も重要ですが、ファームウェアにすでに脆弱なコンポーネントが含まれていれば役に立ちません。
ファームウェアのサプライチェーンはどのように保護しますか？
レシピやロックファイルの外でビルドが取得するものも含め、イメージに入るすべてのコンポーネントを把握し、その記録をリリースごとに保持します。必要なソースにしか到達できない隔離された環境でビルドし、悪意ある依存関係がシークレットをどこにも送れないようにします。デバイスのサポートが続く限り、記録したコンポーネントとサプライヤーのSBOMを新たな脆弱性と照合して監視します。
CRACIはYoctoに対応していますか？
はい。YoctoとBitBakeのビルドはCRACIのランナーで実行でき、CRACIはビルドの実行中にジョブのSBOMを記録します。Yocto自身のSPDX出力には、適用されたパッチやレシピが修正済みとするCVEなど、CRACIが記録しないレシピのメタデータが含まれているため、それらに依存している場合はcreate-spdxを有効のままにしてください。
CRACIはチップベンダーのSDKの脆弱性をトラッキングできますか？
SBOMがあれば可能です。ベンダーのSBOMをCRACIに追加でき、それらのコンポーネントは自社でビルドしたソフトウェアと並べて監視されます。ビルド中にベンダーからダウンロードしたものも、ジョブのSBOMに記録されます。
CRACIはファームウェア内のマルウェアを検出しますか？
挙動やレピュテーションに基づく検出は行いません。xzのバックドアのようにCVEが公開されている既知の悪意あるリリースは、他の脆弱性と同様に指摘され、ポリシーゲートでそれを含むビルドをブロックできます。新しい攻撃に対するCRACIの防御は、ビルドが不要なホストに到達するのをブロックする、デフォルト拒否に設定したエグレスポリシーです。
CRACIはファームウェアや来歴に署名しますか？
いいえ。CRACIはファームウェア、SBOM、来歴のいずれにも署名しません。リリースとアップデートには、引き続き自社の署名プロセスとハードウェアベースの鍵保管をお使いください。
Cyber Resilience Actはコンシューマー機器に適用されますか？
Cyber Resilience Actは、EU市場に出されるデジタル要素を含む製品を対象としており、ほとんどのコネクテッドなコンシューマー機器が含まれます。報告義務は2026年9月11日から適用され、規則は2027年12月11日から全面的に適用されます。CRACIはCRAプロセスに必要なサプライチェーンの可視性とエビデンスのかなりの部分を自動化しますが、規則への対応は製造業者自身のプロセスです。
CRACIはどのCIシステムとビルドマシンに対応していますか？
CRACIは、x86-64とARM64、1〜32vCPUのLinuxランナーでGitHub Actionsのジョブを実行します。GitLab CIやJenkinsなどの他のCIシステム、そしてWindowsとmacOSのランナーはロードマップに掲載されています。