サイバーレジリエンス法遵守と Application Security 

サイバーレジリエンス法（CRA）に対応しようとしている組織の多くは、投資すべき層を間違えている。パイプラインの強化、スキャン範囲の拡大、リスク評価の詳細な文書化などを行っているが、これらはすべて製品リリース前に行われる活動だ。しかし、この規制は、製品が既に流通し、製造元が制御できない環境で稼働しているリリース後に法的責任を課すものだ。 

CRAはこれを明確に定めています。デジタル要素を含む製品は、市場投入時だけでなく、脆弱性の対処方法、インシデントの検出と報告方法を含め、運用期間全体を通して必須のサイバーセキュリティ要件を満たす必要があります。これは、ほとんどのチームが想定しているものとは異なる障害モードを生み出します。コンプライアンスは、開発中に脆弱性が特定されたかどうかによって決まるのではなく、製品が悪用に耐え、影響を限定し、悪用が発生した場合に証拠を提示できるかどうかによって決まります。

CRAは、所在地に関わらず、EU域内で「デジタル要素を含む製品」（ハードウェアまたはソフトウェア）を開発、輸入、または販売するあらゆる組織に適用されます。

タイムライン：サイバーレジリエンスが運用可能になる時期 

サイバーレジリエンス法は既に施行されており、2024年12月10日に発効しました。この法律は、デジタル要素を含む製品の製造業者に対する負担を段階的に増加させる明確な実施計画を定めています。最初の主要な運用上の節目は2026年9月11日で、この日に第14条に基づく報告義務が発効します。規制の全範囲は、主要条項が施行される2027年12月11日から適用されます。 

この一連の流れは、コンプライアンスのあり方における構造的な変化をもたらします。組織は、かつて成熟度の指標であった機能が、定められた対応期間に紐づいた強制的な要件へと移行する過程を経ます。2026年の節目までは、チームは脆弱性の可視化と脆弱性への対応を改善すべき領域として扱うことができます。しかし、それ以降は、これらの機能は厳格な期限内に運用されなければならず、検出、分類、および対応を実証する証拠によって裏付けられる必要があります。 

2027年までに、この標準は製品ライフサイクル全体に適用される。安全な開発手法、テスト範囲、リスク評価は、製品が実際の環境でどのように動作するかに直接結びつく必要がある。求められるのは設計意図だけではない。組織の管理外の環境で製品が動作している際に、厳密な検証に耐えられるか、また、サポートプロセスが検証可能な証拠を生成できるか、といった点も含まれる。 

多くの準備活動がここで方向を見失い始める。チームは、文書化、リリース前検証、制御範囲の確保といった要素に集中しがちだ。なぜなら、これらの要素はカタログ化や監査が容易だからだ。しかし、期限というプレッシャーは別のところに及ぶ。製品が悪用されにくく、悪用を検知し、リリース後も防御可能な状態を維持できることを証明する必要がある。コンプライアンスは、準備だけでなく、実行時の動作と観測可能な証拠によって左右されるようになる。 

攻撃者はバイナリファイルとやり取りし、あなたの制御システムとは直接関係ありません。 

附属書IパートIでは、製品が攻撃対象領域を制限し、不正な改ざんを防止し、完全性を保護し、インシデントの影響を軽減することを要求しています。これらの要求は、攻撃者と展開されたソフトウェアとの直接的なやり取りを前提としています。 

モバイルアプリケーションがダウンロードされ、解凍されます。そのクラスとメソッドが再構築されます。APIエンドポイントと認証ロジックが抽出されます。同じセッション内で、実行を傍受および変更するためのランタイム計測フレームワークがアタッチされます。関数の戻り値をオーバーライドすることで、検証チェックがバイパスされます。リクエストは構造的に有効なままであるため、サーバー側の異常は発生しません。これが、CRAが記述されているベースライン実行環境です。 

Digital.ai Application Security コンパイル済みのアプリケーションを改変することで、リバースエンジニアリングではロジックの有用な表現が得られなくなります。制御フローが変換され、識別子が削除され、実行パスが非線形になります。これにより解析が不可能になるわけではありませんが、ほとんどの攻撃にとって実用的な閾値を超える労力が必要になります。この手法は、アプリケーションが既に構築済みであることを前提とし、攻撃者がアプリケーションに完全にアクセスできる場合の動作に焦点を当てています。  

標準的なモバイルバンキングアプリケーションを使用すれば、これらの手順を数分で再現できます。ビジネスロジックはコンパイル済みのアプリケーションから直接再構築されます。静的解析によってクライアント側の制御が可視化されます。その後、実行時にランタイム計測を使用して検証ロジックをオーバーライドします。 

一般的な実装では、アプリケーションはサーバーが発行したトークンをデバイス上にローカルに保存することでユーザーセッションを維持します。アーキテクチャの観点から見ると、このモデルは制御され安全であり、アプリケーションとバックエンドサービス間の通信は認証されています。ユーザーの視点から見ると、アプリケーションは設計どおりに動作し続けます。バックエンドに送信されるリクエストは、構造的に有効で認証されており、想定される動作と一致しています。インフラストラクチャの観点から見ても、異常は検出されません。侵害は完全にアプリケーションの境界内で発生し、想定されるリクエストパターンを損なうことなく、実行が変更され、機密データが漏洩しています。 

悪用はアプリケーション内部で発生する 

銀行アプリケーションは、安全な開発手法に従い、認証を強制し、サーバー側の検証に依存することができますが、デプロイ後はセキュリティ上の脆弱性が残ります。モバイルバンキングアプリケーションは、デバイスにローカルに保存されたサーバー発行のトークンを介してユーザーセッションを維持します。アプリケーションは、ログイン、残高照会、および取引のためにバックエンドエンドポイントと通信します。アーキテクチャの観点から見ると、このモデルは制御され、安全に見えます。 

攻撃者はインフラストラクチャを標的にするのではなく、アプリケーションのバイナリを抽出し、そのロジックを再構築します。標準的なリバースエンジニアリングツールを使用して、攻撃者はAPIエンドポイント、認証フロー、およびセッショントークンの保存場所を特定します。その後、アプリケーションは改ざんされたコードで再パッケージ化され、正規のサービスを模倣したフィッシングサイトを通じて再配布されます。ユーザーがこの改変版をインストールして実行すると、アプリケーションはユーザーの視点からは期待どおりに動作します。同時に、セッショントークンが取得され、攻撃者へ送信されます。 

そのトークンを使って、攻撃者はバックエンドに直接有効なリクエストを発行します。サーバーは、構造と認証が正当に見えるため、異常を検知することなくこれらのリクエストを処理します。インフラストラクチャ監視の観点からは、異常は発生しません。しかし、アプリケーションの観点からは、実行が変更され、機密データが漏洩しています。これが、サイバーレジリエンス法が想定する運用環境です。製品はもはや製造元の管理下にありません。攻撃者はアプリケーションと直接やり取りし、その動作を変更し、正当な経路を利用して悪用します。 

リスク評価は、アプリケーションにリスク評価が含まれている場合にのみ適用されます。 

第13条では、デジタル要素を含む製品の製造業者に対し、サイバーセキュリティリスクを評価し、設計、開発、製造、保守の各段階でこれらのリスクに対処することを義務付けている。また、この評価結果を文書化し、維持管理し、製品の動作に反映させることも義務付けている。実際には、評価は文書として存在するものの、その実施は外部の統制に依存している。リバースエンジニアリングはリスクとして認識されているが、それを防止する仕組みは存在しない。実行時操作は認識されているものの、その検出は、それを監視できないインフラストラクチャ信号に依存している。 

Digital.ai AppSecは、リスク評価の結果をアプリケーション自体に組み込むことで、このギャップを埋めます。評価でリバースエンジニアリングが脅威と特定された場合、難読化によってその活動に対する耐性が直接的に強化されます。改ざんが特定された場合、アンチタンパー機能によって変更された実行パスが検出され、ブロックされます。機密性の高い資産がリスクにさらされている場合、それらはアプリケーション内で保護され、静的解析や動的解析によって抽出されることはありません。 

これにより、CRA（信用リスク評価）の要件と製品の動作との間に直接的な関係が生まれます。この規制では、リスクを最小限に抑え、インシデントを防止するか、またはその影響を軽減することが求められています。この要件は、アプリケーション自体が実行時にこれらの条件を強制する場合にのみ満たされます。 Digital.ai AppSecはリスク評価やコンプライアンス文書の維持管理は行いません。AppSecは、その評価結果が実際の運用環境においてアプリケーション内で確実に実施されるようにします。規制が最終的に検証されるのは、まさにその運用環境においてです。 

規制はパッチギャップを認識しているが、ほとんどのアーキテクチャは認識していない 

附属書IパートIIでは、脆弱性を遅滞なく修正し、セキュリティアップデートを効果的に配布することが求められています。また、継続的なテスト、協調的な情報開示、およびアップデート配信のための仕組みも要求されています。この規制は、脆弱性が存在し、時間をかけて対処する必要があることを認識しており、即時修正を前提としていません。そのため、脆弱性の開示から完全なパッチ適用までの間に、既知の脆弱性暴露期間が生じます。この期間中、脆弱性は一般に公開され、悪用手法が利用可能となり、展開されたインスタンスはパッチが適用されないままとなります。 

Digital.ai AppSecはこの期間中、脆弱性の悪用可能性を低減します。悪用が脆弱なロジックの理解を必要とする場合、難読化によってそのロジックの特定と解釈に必要な時間が増加します。悪用が実行の変更を必要とする場合、アンチタンパーによって変更された動作がブロックされます。悪用がランタイム動作の監視に依存する場合、保護機能はその監視に使用されるツールを妨害します。これにより、脆弱性の実際的な影響が変化します。脆弱性自体は存在しますが、大規模に悪用することがより困難になります。 

Digital.ai AppSecは、脆弱性管理、SBOM生成、パッチ配布に取って代わるものではありません。これらの機能は、CRAの義務を果たすために依然として必要です。AppSecは、これらの機能ではリスクを十分に迅速に排除できない期間に対応するものです。 

第14条は証拠を要求するものであり、憶測を要求するものではない 

CRAは、悪用された脆弱性および重大なインシデントについて明確な報告義務を導入し、通知およびフォローアップの期限を定めています。悪用された脆弱性とは、悪意のある使用の確実な証拠がある脆弱性と定義されます。重大なインシデントには、悪意のあるコードが導入された場合、または製品のセキュリティが重大な影響を受けた場合が含まれます。ほとんどの組織は、既存のテレメトリではこの要件を満たすことができません。インフラストラクチャログにはリクエストが表示されます。ネットワーク監視にはトラフィックパターンが表示されます。どちらも、メモリ内で関数がオーバーライドされたことや、計測によって実行が変更されたことを示しません。 

標準的なモバイルバンキングアプリケーションを例にとると、クライアント側の検証関数が実行時にオーバーライドされ、通常であればブロックされるはずのトランザクションが処理されてしまう可能性があります。アプリケーションは、バックエンドの期待に完全に合致するリクエストを発行し続けます。リクエストは構造的に有効で、認証済みであり、正当なトラフィックと区別がつきません。インフラストラクチャやネットワークログには異常は現れません。アプリケーションレベルでの検出が行われない限り、悪用が発生したという証拠は得られません。 Digital.ai AppSecは、攻撃が発生した時点でシグナルを提供します。デバッガがアプリケーションに接続すると、それが検出されます。メモリが変更されると、その変更が特定されます。実行が想定される動作から逸脱した場合、アプリケーションはそれを異常としてフラグ付けできます。これにより、第14条に必要な開始点が確立されます。 

アプリケーション内部で異常な動作が検出されます。その動作は、既知のエクスプロイト手法または脆弱性と関連付けられます。イベントは、CRA（脆弱性評価）の定義に基づきエクスプロイトとして検証されます。そして、実際に悪用されている脆弱性、または重大なインシデントとして分類されます。その後、必要な24時間および72時間以内に報告が行われます。アプリケーションレベルでの検出がなければ、この一連のプロセスは開始されません。 Digital.ai AppSecは、インシデント対応システムや規制報告ワークフローに取って代わるものではありません。それらのワークフローに必要な証拠を提供するものです。 

サポート期間はエンジニアリング制御の範囲を超えてリスクを拡大させる 

CRA（コンピュータリスク評価）では、製造業者に対し、サポート期間を定め、その期間中に脆弱性に対処することを義務付けており、ほとんどの場合、最低5年間と定められています。また、セキュリティアップデートが常に利用可能であり、その期間中に脆弱性への対応が継続されることも義務付けています。しかし実際には、展開されたソフトウェアは最新バージョンに収束するわけではありません。古いバージョンは、デバイス、環境、ユーザーの行動を問わず、存続します。攻撃者は、これらのバージョンの動作が安定していて既知であるため、標的とします。 

Digital.ai AppSecは、これらのバージョン内で保護機能が維持されることを保証します。アプリケーションが更新されない場合でも、整合性チェックの実施、リバースエンジニアリングへの対策、改ざんの試みの検出を継続します。これにより、長期にわたって運用されるシステムにおける既知の脆弱性の悪用を抑制します。 

Digital.ai AppSecはサポート期間を延長したり、アップデートの配信を管理したりするものではありません。サポート期間が実際の使用状況と合致した場合に発生するリスクを軽減するものです。 

サプライチェーンのリスクは最終製品においてのみ悪用可能となる 

CRAは、製造業者に対し、サードパーティ製部品に対するデューデリジェンスを実施し、製品全体にわたる脆弱性に対処することを義務付けています。また、SBOMなどの仕組みを通じて部品を特定し、それらの部品で発見された脆弱性を修復することも義務付けています。この規制では、製品の組み立て方法に関わらず、製品を単一の責任単位として扱います。 

Digital.ai アプリケーションセキュリティは、まさにその収束点において機能します。攻撃者がアプリケーションを分析して脆弱なコンポーネントを特定しようとする場合、難読化によってコード構造の可視性が制限されます。また、実行時にこれらのコンポーネントを操作することで悪用しようとする場合、改ざん防止機能と実行時保護機能がそのプロセスを妨害します。これはサプライチェーンの脆弱性を完全に排除するものではありません。しかし、展開された環境における脆弱性の悪用可能性を低減します。 

Digital.ai AppSecは依存関係を追跡したり、SBOMを管理したりはしません。AppSecは、それらの依存関係がリスクをもたらす場合でも、アプリケーションが攻撃者に容易にリスクを晒さないようにすることを保証します。 

境界線こそが最も混乱を招く場所だ 

サイバーレジリエンス法は、設計要件、脆弱性への対応、報告、適合性評価、市場監視など、複数の領域にまたがる。 

Digital.ai Application Security このツールは、これらのドメインのいずれかにおいて、高い精度で動作します。実行時にアプリケーション内のセキュリティを強化し、実行可能ファイルを解析から保護し、改ざんを検知し、エクスプロイトの成功を制限します。また、エクスプロイトイベントの検証に使用できるシグナルを生成します。  

静的解析、依存関係インベントリの管理、SBOMの生成、リリースパイプラインの調整、パッチの配布、適合性文書の作成などは行いません。これらのシステムは、コンプライアンス義務を定義し、管理します。 Digital.ai アプリケーションセキュリティは、アプリケーションが攻撃的な状況にさらされた場合でも、これらの義務が有効であることを保証します。 

最終的な展望 

サイバーレジリエンス法は、脆弱性が存在し、攻撃者がそれを悪用する可能性があり、製品はそのような状況下でも安全でなければならないという前提に立っています。この規制は、設計、ライフサイクル管理、報告に関する要件を定めていますが、その適用は実行時に行われます。アプリケーションが攻撃者の手に渡り、その動作が検査・変更され、脆弱性が積極的に悪用される時、そこでコンプライアンスが判断されるのです。 

Digital.ai Application Security その段階で動作します。アプリケーションが解析に耐え、整合性を維持し、悪用を検知し、実際の運用中に脆弱性の影響を軽減することを保証します。これがCRAが実際にテストされる層です。