はじめに
皆さんこんにちは！
今般、始めてアドベントカレンダーに参加します。12月8日担当の余保（ヨボ）です。
主にLinux Foundation OpenChain Japan WG、Linux Foundation OpenSSF、Linux Foundation Civil Infrastructure Platform(CIP)に参画しています。
今年もいよいよ師走ですね。年末までに完了予定の仕事が大詰めを迎えバタバタしています。もっと余裕を持って師走を迎えたかったと、毎年この時期になると思います。巷ではインフルエンザが大流行しており、こんな中で罹患したら。。。と想像するだけで恐ろしくなりながら、うがい手洗いを徹底する日々を送っています。
さて、前置きはこの辺にして、少しだけ私のバックボーンについてお話しします。
私は20数年程前から組み込み機器向けセキュリティ分野に携わってきました。最初は職務として与えられた仕事でしたが、従事するうちにセキュリティの重要性を痛感するようになり、単に仕事として世の中にセキュリティ製品や機能を提供するだけではなく、広く世の中にセキュリティの大事さを分かってもらい、安心・安全な世の中にしたいと思うようになりました。
そんな折、OpenChain、OpenSSF、CIPに参画し、セキュリティの大事さを世の中に発信する機会をいただき、今までの経験を生かし社会に貢献出来ればという思いでコミュニティ活動をしています。
今回の記事では、そんな私のバックボーンを生かしてEU Cyber Resillience Act(以下EU CRA)についてお話します。
なお、本記事では全体感を把握してもらう事を優先しており、必ずしも厳密な説明とはなっていない事をご了承ください。
筆者は法律の専門家ではありません。ここでは筆者がEU CRAをウォッチし調べたことを共有しますが、誤りを含む可能性があります。
法令の正確・正式な意味・解釈は、別途専門家に確認を取ることをお勧めいたします。
セキュリティの難しさ
まずセキュリティの難しさについて少し触れたいと思います。よく言われるセキュリティの難しさには次の２つがあります。
1：セキュリティ桶理論
複数の板を張り合わせて作った桶に貯められる水位は一番低い板で決まってしまうように、特定の箇所のセキュリティだけを強化しても全体の堅牢性は向上しないという理論。
システム全体のセキュリティ堅牢性はシステムの中で最も脆弱な箇所で決まる。
→システム設計時に全体のセキュリティ設計をしておく必要がある。
２：攻撃者の非対称な優位性
長大な城壁を築いて攻撃者の侵入を防ごうとする場合、城壁に1か所でも隙があれば侵入されてしまい、城壁が長ければ長いほど防御する側が不利になる。
攻撃者はセキュリティホールを1か所見つければ良く、守る側はセキュリティホールが1か所もあってはならない。
→最終製品だけでなくサプライチェーン全体で守る必要がある
EU CRAは、これらセキュリティの難しさを踏まえた上で、安心・安全の為にこれらを克服する事を目指した法律であると筆者は捉えています。
それでは、EU CRAを見ていきましょう！
EU CRA概要
EU CRAは製品の脆弱性を減らしセキュリティ情報の透明性を高めることで、消費者と企業をサイバー脅威から保護する事を目的に、EU市場に出されるすべてのデジタル要素を含む製品（ハードウェア・ソフトウェア）に対し、ライフサイクル全体でのサイバーセキュリティ要件を定め義務付ける法律です。
1.主なタイムライン
EU CRAは2024年12月11日に施行されました。EU CRAは施行日から有効ですが、施行日から21か月の脆弱性報告義務猶予期間、36か月の移行猶予期間が設けられています。
| 日付 | イベント |
|---|---|
| 2024年12月11日 | 施行 |
| 2026年9月10日 | 脆弱性報告義務猶予期間満了 |
| 2027年12月10日 | EU CRA移行猶予期間満了 |
2.対象となる機器と分類
デジタル要素を含む製品全てが対象
対象製品は製品の機能によって
・Defualt
・Important Class I
・Important Class II
・Critical
の４つのカテゴリに分類されます。カテゴリによって求められるセキュリティ要件や義務は同じですが、適合性評価の手順や評価の厳しさが異なります。
以下にカテゴリ分類例を示します。Important Class I、II、Criticalに分類されないデジタル製品はDefaultに分類されます。
3.EU CRAで求められる要件と義務
＜主なセキュリティ要件＞
・リスクベースアセスメントを基にした、製品のセキュリティ設計、開発、製造、保守
（製品ライフサイクル全体でセキュリティ確保）
・機械可読形式で一般的に使用されるSBOM作成
（少なくとも最上位レベルの依存関係含む）
＜製造業者の主な義務＞
・第三者から調達したコンポーネントのデューデリジェンス実施
(商業活動でないOSSを導入する場合も含む）
・脆弱性管理とセキュリティアップデートの提供
公開から10年間またはサポート期間のどちらか長い期間アップデートを利用可能とする。
・脆弱性およびインシデントの報告義務
積極的に悪用されている脆弱性や重大なセキュリティインシデントをENISA* へ報告
*ENISA:European Union Agency for Cybersecurity
まとめ＆所感
ここまでEU CRAの要点をざっくりと見てきました。
セキュリティの難しさの所で触れた
・セキュリティはシステム全体で考える必要があり設計段階からセキュリティ設計を行う事
・サプライチェーン全体でセキュリティを守る必要がある事
をEU CRAでは要件として定めています。
筆者は、特に第三者から調達したコンポーネント（OSS含む）のデューデリジェンス実施を求めている点に注目しています。今まではOSSのセキュリティについての責任範囲が曖昧でしたが、EU CRAではOSS導入時のデューデリジェンス実施を製造者の義務と定めました。この事は重要な意味を持つと考えています。OSSコミュニティの協力なしに製造者が独自にOSSのデューデリジェンスを実施する事は難しいと推測しており、EU CRAの施行によって製造者とOSSコミュニティとの互恵関係の必要性が増し、互恵関係の構築が加速することに期待しています。
最後に
EU CRAについてはLinux Foudationが提供しているTrainingコースがありますので、そちらもご覧ください。
Understanding the EU Cyber Resilience Act(CRA)(LFEL1001)
最後までご覧いただきありがとうございました。