26年2月号 セキュリティコラム「Cyber Resilience Act施行に備えて」～スマホアプリ提供者に求められる対応について～

JSSEC セキュリティコラム

26年2月号「Cyber Resilience Act施行に備えて」
～ スマホアプリ提供者に求められる対応について ～

JSSEC副会長・理事
KDDI株式会社　本間 輝彰

EU（欧州連合）では、デジタル要素を備えた製品（ソフトウェアを含む）について、サイバーセキュリティの水準を底上げし、利用者が安心して利用できる環境を整えることを目的に、Cyber Resilience Act（CRA）※1が制定されました。CRAは段階的に適用が始まる予定で、全面適用は2027年12月11日から開始とされています。

CRAの適用が始まると、日本国内のスマホアプリ事業者であっても、App StoreやGoogle Playなどを通じてEU圏内のユーザーに向けてアプリを提供している場合には、CRAの対象となり、対応が求められる可能性があります。EU圏内でアプリを配信している提供者にとっては、施行（適用開始）までに、CRAが求めるポイントを把握し、準備を進めておくことが重要になってきます。

本コラムでは、CRAの概要を紹介した上で、スマホアプリ提供者が意識しておきたい要求事項を、ポイントを絞って説明します。CRAには違反時の制裁（行政制裁金等）に関する規定もあるため、万一インシデント等が発生した際に「対応が不十分だった」と見なされないよう、早めに備えておくことが望ましいでしょう。

なお、CRA対応を進めるにあたっては、「自社のアプリがCRAの対象になり得るか」「どのような対応が必要か」を、社内の法務部門（必要に応じて外部専門家）とも連携しながら確認していくことをおすすめします。

※1 https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act

Cyber Resilience Act（CRA）とは

Cyber Resilience Act／サイバー・レジリエンス法（CRA）は、EUが制定した、デジタル製品のサイバーセキュリティを底上げするための規制枠組みです。対象は大まかに言えば、ソフトウェアを含む「デジタル要素を備えた製品」であり、EU域内で流通・提供される製品について、設計・開発段階から安全性を確保し、提供後も継続的に脆弱性へ対応することを事業者に求めます。

これまでEUでは、製品安全や個人データ保護（GDPR）等は強い規制がある一方で、ソフトウェアを含む幅広いデジタル製品に対して、「最低限満たすべきサイバーセキュリティ要件」や「脆弱性対応の責務」が一律に定められているとは言いにくい状況がありました。CRAはこのギャップを埋め、EU域内市場に出回る製品のセキュリティ水準を平準化することを狙っています。

CRAでは、規制の対象となる「デジタル要素を備えた製品（ソフトウェアを含む）」の中でも、附属書（Annex）に “Important products（重要製品）”として挙げられているタイプに当てはまるものについて、リスクの大きさなどに応じて Class I と Class II に分けて整理しています。

一方で、附属書に並ぶ「重要製品」の類型に当たらないソフトウェア（スマホアプリを含む）は、CRA上はひとまず “重要製品（Class I/II）ではない製品”として扱われることになります。つまり、スマホアプリかどうかよりも、そのアプリがどんな役割（機能）を担っているかが、Class I/IIに該当するかを考える際の出発点になります。

次に、CRAで区分される「重要製品（Class I/II）かどうか」によって、求められる適合性評価（適合していることを確認・示すための進め方）がおおむね次のように整理されます。

なお、デジタル要素を備えた製品であっても、すべてが一律にCRAの対象になるわけではありません。条件によっては、CRAの適用対象外になったり、他のEU法との関係で適用範囲が調整されたりすることがあります。代表例としては次のようなケースが挙げられますが、最終的な判断は個別事情に左右されるため、「対象外だと思い込まず」一度立ち止まって確認することをおすすめします。

● 軍事または国家安全保障のみを目的として使用される製品
● 商業活動として提供されないオープンソースソフトウェア（FOSS）
　⇒このようなOSSを商用ソフトウェアや製品に組み込み、EU市場に提供する場合には、組み込んだ側が製品全体として適切に管理**していく必要があります。
● 他のEU法（セクター別法：EU 2017/745、2017/746 など）により、同等のサイバーセキュリティ要件が課され、CRAとの適用関係が調整される製品
　⇒該当可否は、個別規制との関係も含めて適用範囲を確認しておくと安心です。
● クラウド上のみで提供され、利用者にソフトウェアとして配布されない形態のサービス（いわゆるSaaS等）は、CRAの「製品」という考え方との関係で、対象外となり得ます。
　⇒SaaSであってもスマホアプリなどのクライアントソフトウェアを提供している場合には、CRAの対象となる可能性があります。

スマホアプリに求められるCRAの対応要件

スマホアプリ提供者にとってCRA対応は、細かなチェック項目をこなすというよりも、まず次の3つの考え方を押さえておくと理解しやすくなります。

1つ目は、リリース時点での基本的な安全性を底上げすること（いわゆる“出荷時点の安全性”の確保）。2つ目は、リリース後に見つかる脆弱性やインシデントに対して、継続的に対応し続けること（“継続的なセキュリティ維持”）。そして3つ目は、EU域内で流通する製品として、セキュリティに関する説明や情報提供を通じて、信頼性と透明性を高めることです。

こうした考え方を踏まえると、スマホアプリをEU向けに提供する場合、少なくとも次に挙げるような対応をあらかじめ意識しておくことが重要になります。

● セキュリティ・バイ・デザイン / バイ・デフォルト
企画・設計の段階から、攻撃を「想定外」にせず、脅威やリスクを前提にアーキテクチャへ対策を織り込みます（例：権限設計、認証方式、暗号化、データ最小化、ログ設計）。また、初期設定（デフォルト設定）は“便利側”ではなく“安全側”に寄せ、ユーザーが特別な操作をしなくても一定水準の安全性が確保される状態を目指します。結果として、リリース後の改修コストや事故時の影響も抑えやすくなります。

● 脆弱性リスクの低減（設計・実装・検証）
実装面では、安全なコーディング、入力値検証、認可チェックの徹底、秘密情報の安全な保管（端末内・サーバ側双方）など“基本の積み上げ”が重要になります。検証面では、レビューやセキュリティテスト（例：静的解析・動的解析、依存ライブラリ診断、ペネトレーションテスト等）を開発プロセスに組み込み、脆弱性を早期に潰す流れを作ります。さらに、不要機能・未使用API・過剰な権限要求を減らすことで、攻撃面（Attack Surface）そのものを小さくする考え方も有効です。

● 脆弱性取扱い（Vulnerability handling）プロセスの整備・運用
脆弱性は「見つかること」が前提です。そこで、外部からの報告を受け付ける窓口（連絡先、報告手順、受付範囲）を明確にし、受付→切り分け→影響評価→修正→リリース→周知→記録、までの一連の運用手順を整備します。いわゆる協調的脆弱性開示（CVD）を想定し、タイムライン管理や再発防止まで含めて“回る仕組み”にしておくことがポイントです。

● セキュリティアップデートの提供
脆弱性が判明した際に、修正を「作る」だけでなく「確実に届ける」必要があります。スマホアプリの場合、App Store/Google Play経由の配布、アップデート促進（強制アップデートの可否、サポート対象OSの方針、周知方法）まで含めて設計しておくと、対応が現実的になります。あわせて、どの程度の期間アップデートを提供するのか（サポート期間、EOL方針）も、ユーザー・取引先に説明できる形にしておくことが望まれます。

● サプライチェーン／依存関係管理（第三者コンポーネントを含む）— SBOMを含む
いまのアプリ開発は、OSSや外部SDK、広告・解析ライブラリ、暗号ライブラリ等の依存関係の上に成り立っています。CRA対応としては、これら第三者コンポーネントを“把握していない”状態を避け、SBOM（Software Bill of Materials：ソフトウェア部品表）を作成・維持して、どのコンポーネントをどのバージョンで使っているかを追えるようにすることが重要です。SBOMは作って終わりではなく、更新・保管し、脆弱性情報（CVE等）との突合、アップデート判断、影響範囲の特定に使える状態にしておくのが実務的です（フォーマットはSPDXやCycloneDX等がよく使われます）。加えて、調達先・開発委託先の管理、ビルドの完全性（署名、改ざん耐性、CI/CDの管理）といった“供給網全体”の観点もセットで押さえます。

● 適合性評価（Conformity Assessment）と技術文書（Technical Documentation）の整備
CRAでは「やっている」だけでなく、「要件を満たしていることを説明できる」ことが重視されます。そこで、設計方針、リスク評価の考え方、採用したセキュリティ対策、テスト結果、脆弱性管理の運用、アップデート方針などを、技術文書として整理・更新・保管することが必要になります。スマホアプリでも、後から問われたときに根拠を示せるよう、開発プロセスに“文書化の型”を組み込んでおくと負担が減ります。

● EU適合宣言（DoC）の作成、およびCEマーキングの表示（該当する場合）
CRAの枠組みでは、要件適合を宣言する文書（DoC）や、場合によってはCEマーキング等の対応が論点になります。スマホアプリ単体でどこまで該当するかは提供形態や分類によって変わり得るため、コラムでは「該当する場合がある」位置づけにしておくのが安全です。いずれにせよ、形式対応ではなく、前項の適合性評価・技術文書とセットで整備していくイメージになります。

● 重大インシデント／悪用されている脆弱性等の報告義務
重大なインシデントや、実際に悪用されている（され得る）脆弱性が判明した場合、当局等への通知や関係者への周知が求められる場面があります。特徴は、対応のスピードが重視され、初動では「分かっている範囲」で迅速に共有し、続報で精度を上げていく運用が想定される点です。したがって、社内のエスカレーション、判断基準、対外窓口、利用者向け告知テンプレートなどを事前に準備しておくと現実的です。

● リリース後の是正措置・当局協力（Post-market）
リリース後も、脆弱性情報や事故兆候を継続的に監視し、問題が見つかった場合はパッチ提供、設定変更の案内、必要に応じた提供停止等の是正措置を取れる体制が求められます。また、当局から情報提供を求められた場合に備え、調査に必要な記録（変更履歴、SBOM、影響分析、テスト結果等）を提示できる状態にしておくことも重要です。平時から“追跡可能性（トレーサビリティ）”を整えておくと、有事対応の質が大きく変わります。

まとめ

2027年末に予定されているCRAの適用開始（段階適用を含む）を見据え、本コラムでは、スマホアプリ提供者が押さえておきたいポイントを中心に解説しました。

CRAは、EU域内で提供されるソフトウェアを含む幅広いデジタル製品について、サイバーセキュリティの水準を底上げし、利用者がより安心して利用できる環境を整えることを目的としています。そのため、スマホアプリであってもEU向けに提供している場合には、製品の位置づけや提供形態によってCRA対応が必要となる可能性があります。

日本国内では、CRA対応というとIoTデバイス側が先に話題になりやすく、JC-STARとの比較を含めて議論も進んでいます。一方で、アプリ（特にスマホアプリ）については、整理された情報がまだ多いとは言えず、「アプリは対象外だろう」と判断してしまうリスクもあります。スマホアプリかどうかにかかわらず、提供する機能や役割によっては、CRA上の重要製品（Class I/II）に該当し得る点は、あらためて意識しておきたいところです。

もっとも、CRAで求められる内容は、突き詰めれば「安全に作り、運用し、説明できるようにしておく」という、スマホアプリ提供における基本的なセキュリティ実務とも重なります。CRA対応の有無にかかわらず、SBOMを含む依存関係管理や脆弱性対応のプロセス整備などを進めておくことは、事故の予防や信頼性向上という点でも有益でしょう。

スマホアプリの安全性を一段高めるためにも、CRAが求める要件を自社サービスに照らして取捨選択し、優先度の高い対策から計画的に進めることをおすすめします。あわせて、適用対象や必要な手続きの判断に迷う場合は、法務部門（必要に応じて外部専門家）とも連携しながら整理していくと安心です。