Digital.ai（デジタルエーアイ）は、多くの組織がサイバーレジリエンス法（CRA）への対応において、リリース前の対策にばかり注力し、法的な責任をリリース後の行動に負わせていると指摘している。同社は、開発パイプラインの強化、静的スキャンの拡大、詳細なリスク評価の策定は依然として必要ではあるものの、それだけでは不十分だと主張している。なぜなら、CRAは、製品が展開され、攻撃者によって悪用される可能性があった後のパフォーマンスに基づいて、コンプライアンスを判断するからだ。
CRAは2024年12月10日に施行され、段階的に義務が強化されるスケジュールが設定されている。Digital.aiは、2つの短期的なマイルストーンを挙げている。第14条に基づく報告義務は2026年9月11日に発効し、CRAの主要条項は2027年12月11日に完全施行される。段階的な実施は、多くの成熟度に関する取り組みを、期限付きの義務的な運用上の義務へと転換するものと説明されている。検出、分類、対応のプロセスでは、規定された期間内に検証可能な証拠を提出することが求められる。
付属書Iは、コンプライアンスの焦点をランタイム特性へと移行させるものとして挙げられている。攻撃対象領域の制限、不正な操作の防止、整合性の維持、インシデントの影響軽減といった要件は、攻撃者がバックエンド制御ではなく、デプロイされたバイナリーと直接やり取りできるという現実に基づいて策定されている。Digital.aiは、アプリケーションのリバースエンジニアリング、ランタイム計測の挿入、検証ロジックのバイパス、侵害されたクライアントからのリクエストが構造的に有効かつ認証されたままとなるなど、一般的な攻撃シナリオを特徴づけている。そのため、機密データやフローが侵害されていても、インフラストラクチャーのテレメトリには異常は検出されません。
Digital.ai Application Security（AppSec）は、CRAがテストされるレイヤー、すなわち現場の実行可能ファイルに対応するものとして提示されている。この製品は、コンパイル済みコードを変換してロジックの静的再構築を阻害し、識別子を削除し、制御フローを変更し、有意義な分析に必要な労力の閾値を引き上げることで、セキュリティーを強化すると説明されている。AppSecは、改ざん防止機能とランタイム検出機能を提供し、デバッガのアタッチ、メモリーの改変、想定される実行からの逸脱を検知し、第14条に基づくインシデントの検証と報告のきっかけとなるイベントを生成すると説明されている。
第13条で要求されるリスク評価に関して、Digital.aiは、文書化と強制力のある管理策との間にギャップがあることを強調している。規制では、文書化されたリスク評価が維持され、製品の運用に反映されることが求められている。しかし、多くの評価では、リバースエンジニアリングとランタイム操作を脅威として特定しているものの、実行ファイルに緩和メカニズムを組み込んでいない。Digital.aiは、AppSecが評価結果を運用化することでこのギャップを埋めると主張している。具体的には、分析を困難にする難読化、変更された実行パスをブロックする改ざん防止機能、機密情報の抽出を防ぐ資産保護機能などです。ただし、評価自体やコンプライアンス関連の書類作成は行わないことを明確にしている。
CRAの脆弱性管理に関する見解は、永続的なパッチギャップを現実的に捉えているとされている。附属書IパートIIでは、タイムリーな修復と効果的なアップデート配布が求められているが、同時に、公開された脆弱性が展開済みのインスタンスで悪用可能な状態が続く期間があることも認めている。Digital.aiは、AppSecが脆弱なロジックの特定に必要な労力を増加させ、ランタイム操作を阻害し、監視ツールを妨害することで、これらの期間中の脆弱性の悪用可能性を低減すると主張している。ただし、同社はAppSecがSBOM生成、協調的な情報開示、パッチ配布の代替ではなく、補完的なものであることを強調している。
第14条の通知要件は、証拠に基づく義務として強調されている。この規制は、特定の期間内に実際に悪用された脆弱性および重大なインシデントを報告することを義務付けている。実際に悪用された脆弱性は、悪意のある使用の確実な証拠によって定義される。Digital.aiは、一般的なインフラストラクチャーログやネットワーク監視では、クライアント側の関数オーバーライドやメモリー内実行の変更を検出できないため、多くの組織がCRAの定義に基づく悪用を立証できないと指摘している。AppSecは、操作を検出し、異常な実行を既知の手法と関連付けることで悪用イベントを検証できるアプリケーション内シグナルのソースとして提示されており、これにより規制報告チェーンが実現する。
サポート期間に関する規則は、エンジニアリングによる制御を超えたリスクを拡張するものと指摘されている。CRAでは、製造業者に対し、サポート期間（多くの場合、最低5年間）を設定・維持し、その期間を通じて脆弱性への対応を継続することを義務付けている。Digital.aiは、AppSecについて、長期サポート版に保護機能を保持することで、パッチ未適用の古いシステムでもリバースエンジニアリング、改ざん、悪用攻撃に対する耐性を維持できると説明している。ただし、このソリューションは公式サポート期間を延長したり、アップデートの展開を管理したりするものではないと強調している。
CRAにおけるサプライチェーンの義務は、内部コンポーネントの出所に関わらず、完成品を責任の単位として扱うことと要約される。Digital.aiは、AppSecは最終収束点において機能すると説明している。難読化によってコンポーネント構造が静的解析から隠蔽され、ランタイム保護によって展開された成果物におけるサードパーティーの脆弱性を悪用しようとする試みが困難になる。同社は、依存関係インベントリーの維持やSBOM（部品表）の作成は行わないものの、最終バイナリーに保護機能を組み込むことで、サプライチェーンの脆弱性の運用上の有用性を低減できると述べている。
同社は、混乱は通常、設計時の制御と運用上の現実との境界に集中していると警告している。CRAは、設計要件、ライフサイクル管理、脆弱性処理、適合性評価、市場監視に及ぶが、その執行は、製品が敵対的な現場環境でどのように動作するかに基づいている。Digital.aiは、アプリケーション層の保護をより広範なコンプライアンス機能の補完的なものとして位置付け、実行時防御、改ざん検出、証拠信号は、アプリケーションが製造元の制御外で実行される場合に適合性を証明するために必要な特定の機能であると主張している。
出典：Digital.ai
この製品の詳細については、Digital.ai製品ページをご覧ください。
