サイバー攻撃は散発的な妨害行為を超えて、システム的なリスクへと進化した。
今日、単一の脆弱性がサプライヤーや上流ライブラリからソフトウェアベンダーやクラウドサービスに至るデジタルエコシステム全体に波及することがあり、多くの組織が対応できる速度をはるかに上回る速さで広がる。
この相互依存性の高まりにより、英国はもはやサイバーセキュリティを、組織が善意と非公式なベストプラクティスで対応できるものとは見なしていない。
サプライチェーン侵害、侵害されたコンポーネント、デフォルトで不安全な製品の増加は、高度に接続されたデジタル経済を保護するには自主的なセキュリティ対策だけでは不十分であることを明らかにした。あまりにも多くのシステム停止、データ侵害、レジリエンスの失敗が、単一の脆弱なリンクがいかに迅速に産業全体を混乱させるかを示している。
サイバーセキュリティ・レジリエンス法案は、この現実に対応するため、簡潔に述べられるが実施には困難を伴う要件を定めている：
- ソフトウェアは最初からセキュリティを組み込んで設計しなければならない。
- サプライチェーンにおけるサイバーリスクについて透明性を確保しなければなりません。
- 製品は、ユーザーの注意に依存しない安全なデフォルト設定で出荷しなければなりません。
- 脆弱性を特定し、優先順位付けを行い、修正するための運用プロセスを確立する必要があります。
- 規制当局に対して、これらの期待に応えているという確かな証拠を示すことができなければなりません。
この変化が明らかにするのは、もはやスプレッドシートや孤立したスキャナー、事後対応型のチェックリストに頼ることはできないということだ。継続的な可視性、自動化、そして厳密性は今や最低限の要件であり、任意の改善策ではない。
TL;DR
Aikido 、英国サイバーセキュリティ・レジリエンス法案への準拠に必要なツールを提供します。同法案は法的拘束力を有し、設計段階からのセキュリティ確保、デフォルト設定によるセキュリティ保護、SBOMの完全な透明性、脆弱性管理の義務化、サプライチェーンのセキュリティ保証、規制当局への証拠に基づく報告を要求しています。
ここでは、本法案が提出された理由、EUサイバーレジリエンス法との相違点、開発者やセキュリティチームにとっての意味、そして統一された可視性と自動化なしではこれらの要件を満たすことが困難な理由について説明します。
Aikido 、継続的なスキャン、自動化されたリスク相関分析、SBOM生成、サプライチェーン分析、監査対応レポート、GitHub、GitLab、Bitbucket、Azureなどにおける統合された修復ワークフローを通じて、これらの義務を果たすAikido 。
英国およびEUのセキュリティ要件に継続的に準拠する必要がある場合、Aikido 明確なAikido 。
英国サイバーセキュリティ・レジリエンス法案が導入された理由
サイバーセキュリティ・レジリエンス法案は、2018年NIS規制の改革および拡大版である。デジタルシステム、クラウドサービス、依存関係チェーンの複雑化に伴い生じたギャップに対処し、国家のサイバーレジリエンスを強化するために導入された。本法案は、規模・高度化・経済的影響が増大するサイバー攻撃に対応し、「英国の国家安全保障における根本的な変革」をもたらすことを目指す。 多くの攻撃は上流サプライヤー、ソフトウェア依存関係、またはマネージドサービスプロバイダーを悪用しており、ある組織の脆弱性が業界全体に波及する危険性を示している。
エネルギー、水道、医療、交通、金融といった重要な公共サービスは、今やデジタルシステムに大きく依存している。単一のサイバーインシデントが数百万人に影響を及ぼす可能性がある。本法案は明示的に「国民が依存するサービス」——照明の点灯から国民保健サービス（NHS）へのアクセスまで——を保護することを目的としている。クラウドコンピューティング、SaaSエコシステム、相互接続されたサプライチェーンの台頭は、特にマネージドサービスプロバイダー（MSP）周辺において、規制上の盲点を露呈した。
通信、金融、医療、地方自治体における注目すべきインシデントは、不適切なデフォルト設定、未修正の脆弱性、サードパーティリスクへの可視性の低さといった体系的な弱点を浮き彫りにした。これらの進化する脅威に対処するには、自主的なセキュリティ対策ではもはや不十分であった。
これに対し、本法案は指針から強制力のある義務へと転換する。より明確なセキュリティ要件を定め、インシデント報告を強化し、規制監督を拡充し、サプライチェーン保証を強化し、執行権限を更新する。要するに、相互接続が進んだデジタル環境において、英国の重要サービスを保護し経済的安定を維持するための、更新された強制力のある基盤を提供するものである。
法案が開発者とセキュリティチームに意味するもの
サイバーセキュリティ・レジリエンス法案は、広範な政策目標を設定する以上の役割を果たします。ソフトウェアの開発とセキュリティ確保に携わる人々の日常業務のあり方を変えるのです。以下に、開発者とセキュリティチーム双方に対する期待事項を示します。
開発者にとっての意味
開発者はソフトウェア供給チェーンにおいて他のどのグループよりも密接に関わっているため、この法案はコードの記述、保守、リリース方法に直接影響を及ぼします。
1.セキュアコーディングに関する明確な期待：法案は、設計段階からのセキュリティ確保（Secure-by-Design）の原則がコードベースに反映されることを求めています。これは、定期的なコードレビュー、入力データの検証、安全なデフォルト設定、および全サービスにわたる予測可能で安全なパターンを意味します。
2.脆弱性修正の必須タイムライン：「時間が許せば」セキュリティ問題を修正する時代は終わりました。脆弱性は定められた時間枠内で修正し、そのタイムラインが遵守されている証拠を示すことが求められます。
3.依存関係リスクの追跡責任の増大：現代のアプリケーションはオープンソースライブラリに大きく依存しています。自身で記述したコードだけでなく、それらの依存関係のセキュリティ態勢を理解する責任が課せられています。
4.SBOM（ソフトウェア部品表）の認識の必要性：ソフトウェア部品表はコンプライアンス要件となりつつあります。コードベースに含まれる内容（推移的依存関係を含む）を把握し、その在庫を正確に維持する必要があります。
5.証拠に基づくコーディングとコミットの衛生管理：作業内容は追跡可能でなければなりません。これには、クリーンなコミット履歴、変更内容の文書化、セキュリティ関連の決定に対する明確な根拠が含まれます。監査担当者がリポジトリをレビューした場合、脆弱性がどのように管理されたか、また特定の変更がなぜ行われたかを理解できる必要があります。
セキュリティチームにとっての意味
セキュリティチームにとって、本法案は助言的監督から強制的な説明責任へと期待を高める。コンプライアンスは年次的な取り組みではなく、継続的なワークフローとなる。
1.継続的なコンプライアンス要件：セキュリティチームは、すべてのシステム、リポジトリ、依存関係、インフラストラクチャにわたる最新の可視性を維持しなければならない。制御は監査サイクル中だけでなく、継続的に機能しなければならない。
2.自動化された脆弱性ワークフローへの圧力増大：手動スキャンだけでは不十分です。問題を検知し、優先順位付けを行い、適切な担当者に通知し、修正完了まで追跡する自動化されたパイプラインが必要となります。
3.義務的な報告体制：脆弱性情報の明確な受付プロセスを維持し、チーム間での情報共有を促進するとともに、規制当局の要請に応じて提出可能な文書を作成することが求められます。
4.合理的なセキュリティ対策の立証責任：プロセスを有していると言うだけでは不十分です。実際の運用セキュリティを実証する指標、タイムライン、チケット履歴、ログ、SBOM、監査証跡を示す必要があります。
5.エンジニアリングチームとの連携強化：セキュリティ対策がデリバリーパイプラインとエンジニアリングの速度に影響を与えるようになりました。本法案は、DevOps、プラットフォームエンジニアリング、セキュリティ機能間の緊密な連携を促進します。
6.セキュリティ態勢が規制対象となる：セキュリティはもはやベストプラクティスではない。本法案の下では、レジリエンスとセキュアな開発が法的要件となる。かつては内部判断であった決定が、今や規制上の結果を伴う。
英国サイバーセキュリティ・レジリエンス法案 vs EUサイバーレジリエンス法（CRA）
多くの組織は、英国のサイバーセキュリティ・レジリエンス法案がEUサイバーレジリエンス法の単なる地域版に過ぎないと見なしている。
両者ともデジタル製品・サービスのセキュリティ強化を目的としているが、規制対象となる責任範囲は異なる。これらを混同すると、チームが誤った管理措置を適用したり、不適切な報告書を作成したり、いずれの規制枠組みにも適合しない証拠に依存する結果を招きかねない。
EUサイバーレジリエンス法が対象とする範囲
EUの消費者製品安全規制（EU CRA）は、デジタル要素を含む製品を対象とし、EU単一市場全体に適用されます。製造業者、輸入業者、流通業者に焦点を当て、製品がリリース前後で同じ安全基準を満たすことを保証します。
1.設計段階からのセキュリティとデフォルトでの安全性：メーカーは、ユーザーの専門知識を必要とせず、箱から出してすぐに安全な製品を構築しなければならない。
2.リスク評価の義務：製品は市場に流通させる前に、体系的なリスク評価を受けなければならない。
3.必須の脆弱性対応プロセス：脆弱性の受付、リスク評価、および修復は、定められた手順に従わなければならない。
4.市販後監視義務：製造業者は製品リリース後の安全性を監視し、製品の全ライフサイクルにわたって脆弱性への対応を継続しなければならない。
英国サイバーセキュリティ・レジリエンス法案とEUサイバーレジリエンス法の重複部分
両方のフレームワークは、適用方法は異なるものの、類似した原則を共有している。
- セキュア開発要件
- 必須の脆弱性管理
- ソフトウェア・サプライチェーン全体における透明性
- 市場投入後または導入後のセキュリティ監視
- 文書化と証拠に基づくコンプライアンス
例えば、サードパーティの依存関係に重大なCVEが導入された場合、両フレームワークは迅速な可視化、調整された修復、検証可能な文書化を期待します。
主な相違点
英国サイバーセキュリティ・レジリエンス法案の要件を満たすことが困難な理由
サイバーセキュリティ・レジリエンス法案の要求事項は、文書上では単純明快に見える。しかし実際には、ほとんどの組織が苦戦している。その理由は、エンジニアリング環境が複雑で変化が激しく、サードパーティ製コンポーネントへの依存度が高いからだ。成熟したチームでさえ、コミットやデプロイ、依存関係の更新のたびに新たなリスクが生じる状況では、継続的なコンプライアンス維持が困難である。
以下に、これらの要件が実環境で満たしにくい主な理由を挙げます：
- 現代のアプリケーションは、膨大なオープンソースライブラリのネットワークに依存している。ほとんどのチームは、自動化なしではすべての依存関係と間接的な依存関係のセキュリティ態勢を追跡できない。
- セキュリティ対策はコードスキャンで止まることが多い。コンテナイメージ、インフラストラクチャ定義、ランタイムワークロードは同じ精度で監視されないため、監視の死角が生じる。
- チームは異なるスキャナーを使用しており、それらが矛盾する深刻度レベルと一貫性のないガイダンスを生成します。これにより修正が遅延し、優先順位付けが信頼できなくなります。
- 監査用スプレッドシートや定期チェックリストでは、日々のコード変更、依存関係の更新、毎週公開される新たな脆弱性に対応しきれない。
- チームは脆弱性が修正されたことを証明するだけでなく、いつ報告されたか、誰が対応したか、修正にどれだけの時間がかかったか、そしてどのような決定がなされたかも証明しなければならない。ほとんどの組織では、こうした記録が欠けている。
- アーキテクチャの選択、コーディングパターン、設定決定は、追跡可能な根拠によって裏付けられる必要がある。構造化された文書化がなければ、コンプライアンス審査時にこれを提示することは困難となる。
- 調査結果は特定のツールに留まり、チケットは別のツールで管理されることが多いため、課題が適切に分類・優先順位付け・割り当て・解決されたことを確認することが困難になる。
これらの課題は、組織がリスクを監視し、是正措置を調整し、証拠を自動的に生成するための統一された方法が必要な理由を説明しています。これはまた、Aikido 中核的な可視化およびコンプライアンスエンジンとして関連性を発揮する自然なポイントでもあります。
Aikido 英国サイバーセキュリティ・レジリエンス法案の要件遵守をAikido 方法
サイバーセキュリティ・レジリエンス法案の要件を満たすには、組織は定期的なスキャンや孤立したセキュリティツールだけでは不十分です。継続的な可視性、一貫したリスク評価、そしてスプレッドシートを慌てて確認することなく規制当局に提出できる証拠を提供する、最高水準のツールを備えたプラットフォームが必要です。Aikido 、現代のエンジニアリングチーム向けに中央管理ポイントを提供することで、この領域に適合します。
Aikido クラウドネイティブのセキュリティAikido 、あらゆるセキュリティシグナルを一元管理します。コードベース、オープンソース依存関係、インフラストラクチャ・アズ・コードのテンプレート、コンテナイメージ、シークレット、継続的インテグレーションパイプライン全体にわたる可視性を提供します。
チームが別々のスキャナーを管理することを強いる代わりに、Aikido これらのレイヤーにまたがる脆弱性をAikido 、実際に悪用可能なものを強調表示し、修復作業を遅らせるノイズを除去します。
Aikido 多くの要件を満たすのにAikido 一方で、インシデント報告や継続的な運用レジリエンスへの期待など、他の供給者によって満たされる必要がある要件がいくつか存在する。
以下は、Aikido 英国サイバーセキュリティ・レジリエンス法案における中核的義務の達成にどのようにAikido かの詳細です。
1. 要件：設計段階でのセキュリティ対策
問題点：ソフトウェアは最初のコード行から安全であることが求められています。これは、不安全な設定を早期に特定し、依存関係のリスクを低減し、開発者が無関係な発見に埋もれないようにすることを意味します。
Aikido それをAikido する方法
- コードベース、依存関係、インフラストラクチャ構成を継続的にスキャンします。
- 重要な領域を見逃さないよう、安全なデフォルトのスキャン範囲を適用します。
- 複数のソースにわたる問題を相関分析し、開発者のノイズを低減し、真のリスクを浮き彫りにする。
- CIおよびCDパイプラインにおいて安全なワークフローを強制し、脆弱性が黙って本番環境に移行するのを防ぎます。
2. 要件：SBOMの透明性と正確なソフトウェアインベントリ
問題点：正確かつ最新のソフトウェア部品表を維持する必要があります。新しい依存関係が追加されたり、推移的ライブラリが変更されたりすると、手動での追跡は即座に破綻します。
Aikido それをAikido する方法
- ワンクリックでSBOMを生成
- AikAikidoのSBOMジェネレーターを通じて各リポジトリの完全なSBOMを構築し、依存関係を明確に可視化します。
- 直接および間接的なライブラリに対する完全な可視性を提供します。
- SBOMコンポーネントが新しいCVEを受信した際に通知します。
- 監査担当者や内部レビュー向けに、SBOMをワンクリックでエクスポートできます。
3. 要件：必須の脆弱性対応プロセス
問題点：法案は、脆弱性の検出、優先順位付け、責任者の割り当て、そして是正措置の期限遵守を証明することを求めています。ツールが断片化されているため、自動化なしではこれを達成することはほぼ不可能です。
Aikido それをAikido する方法
- リポジトリ、コンテナイメージ、レジストリ全体にわたる脆弱性を検出します。
- 悪用可能性データ、CVSS、脅威インテリジェンスを用いて発見事項を優先順位付けし、チームが重要な課題に集中できるようにします。
- JiraまたはSlackとの連携により、修正作業フローを自動化します。
- タイムスタンプとログで全ての操作を記録し、監査担当者向けの明確な証拠の痕跡を作成します。
- 文書修復のタイムラインを自動的に記録し、規制当局の期待に応える。
4. 要件：サプライチェーンのセキュリティ保証
問題点：ほとんどの組織は上流パッケージやサードパーティの依存関係に大きく依存しています。たとえそれらを作成していなくても、これらのコンポーネントによって導入されるリスクについては、あなたが責任を負うことになります。
Aikido それをAikido する方法
- マルウェアの侵害を早期に特定・分析し、拡散前にAikido 。Aikido 、サプライチェーンに壊滅的な影響を与え得る悪意のあるパッケージ動作、侵害されたリリース、不審な依存関係の変更をいち早くAikido 。
- セキュリティ履歴、保守パターン、およびエコシステムの評判に基づいて依存リスクをスコアリングする。
- コードベースに侵入する前に、潜在的に悪意のあるパッケージやタイポスクワッティングの試みを検出します。
- フラグは、放棄された、時代遅れの、または侵害されたライブラリを示し、チームが本番ワークロードに公開する前にそれらを置き換えられるようにします。
- エンドツーエンドのトレーサビリティを提供し、コンプライアンスチェック時に依存関係がどこから来たのか、どのサービスに影響を与えたのか、そしてどのように修正されたのかを正確に示すことを可能にします。
5. 要件：英国規制当局に対するエビデンスに基づく保証
問題点：優れたセキュリティ対策を実施していると主張するだけでは不十分です。体系的な証拠、過去の記録、透明性のあるリスク報告を通じてそれを証明しなければなりません。
Aikido それをAikido する方法
- 調査結果を規制要件に照らし合わせた、自動生成のコンプライアンス対応レポートを作成します。
- 長期的なリスク管理を示す、過去の脆弱性のタイムラインを表示します。
- 文書修正の活動内容を記録し、監査担当者が変更内容とその理由を理解できるようにする。
- 組織全体で講じられている合理的なセキュリティ対策について、明確な見通しを提供します。
- リスク情報を集約し、経営陣が説明責任を果たすのに役立つ、リーダーシップに適した視点を提供する。
ISO27001、SOC2、NIS2、CISを超えて：英国サイバーセキュリティ・レジリエンス法案が追加する内容
ほとんどの組織は既に、ISO 27001、SOC2、CISベンチマーク、NIS2、PCIなどの確立されたフレームワークへの準拠を維持しています。これらのフレームワークは組織のセキュリティ管理に焦点を当てています。これらは、リスクを管理する方法、ポリシーを文書化する方法、アクセスを制御する方法、イベントを監視する方法、インシデントに対応する方法を定義しています。
Aikido これらの基準をサポートしています：
- ISO 27001:2022 準拠
- SOC2準拠
- OWASP トップ10 コンプライアンス
- CISコンプライアンス
- NIS2準拠
- NIST 800-53 準拠
- PCI準拠
- HIPAA準拠
- DORAコンプライアンス
- HITRUST
- LVL3 コンプライアンス
- ENSコンプライアンス
- GDPR
英国サイバーセキュリティ・レジリエンス法案は、新たな種類の要件を導入する。組織的な管理を超えて、構築・運用するソフトウェアとサービスのセキュリティに厳格な期待を課すものである。 具体的には、設計段階からのセキュリティ確保（Secure-by-Design）、安全なデフォルト設定、検証可能なSBOM（ソフトウェア構成部品表）の透明性、継続的な脆弱性対応、サプライチェーン保証、修正措置のタイムラインに関する証拠の提示が求められます。これらの義務は、エンジニアリング手法、CIパイプライン、コードベース、依存関係、コンテナ、クラウド資産、運用ワークフローに直接適用されます。
これにより新たなギャップが生じます：ISO 27001やSOC2の要件を満たしていても、製品に悪用可能な脆弱性、古いライブラリ、脆弱なサプライチェーン管理、または文書化されていない修復フローが含まれている場合、英国法案の要件を満たせない可能性があります。従来のフレームワークではこれらの領域を十分にカバーできていません。
Aikido 、法案の製品およびサービスレベルの義務を満たすために必要な技術的制御、自動化、リアルタイム可視性を提供することで、このギャップを埋めるのにAikido 。
Aikido ：確信を持って継続的にコンプライアンスを達成する道
英国サイバーセキュリティ・レジリエンス法案は、組織がセキュリティにどう取り組むべきかについて明確な転換点を示す。これは勧告ではなく法的拘束力を持ち、チームは意図ではなく証拠をもってレジリエンスを実証することが求められる。EUサイバーレジリエンス法はこれと並行して異なる範囲と責任を定めており、複数地域で事業を展開する組織は両枠組みを互換性のあるものとして扱うのではなく、それぞれを尊重した微妙な対応が必要となる。
Aikido 、こうした期待に応えるための運用基盤Aikido 。コード、依存関係、インフラストラクチャ、パイプライン全体にわたる継続的な可視性を獲得できます。一貫したリスク評価、自動化された修復ワークフロー、規制当局が信頼できる監査証跡が得られます。コンプライアンスは、ストレスの多い年次チェックポイントではなく、日々維持するものと変わります。
適切なレベルの自動化と適切なレベルの可観測性を実現することで、リスクを低減し、デリバリー速度を向上させ、一般的な規制対応準備に伴う不確実性を排除します。Aikido 、複雑な要件を管理可能で再現性のあるプロセスに変換し、エンジニアリングチームの規模拡大に合わせて拡張することをAikido 。
英国法案に準拠し、EUのCRA要件を満たし、開発ワークフローに自然に統合されるコンプライアンスを実現したいなら、今すぐAikido を導入しましょう。
こちらもおすすめ：
- 欧州企業がAikido を選ぶ理由EU企業とそのサイバーセキュリティ選択
- Aikido デロイトが企業に開発者中心のセキュリティをもたらす方法— より優れた企業開発者体験とセキュリティのためのAikido デロイトの提携
- Aikido によるサイバーレジリエンス法（CRA）への準拠—Aikido でEUのCRAに準拠する
今すぐソフトウェアを保護しましょう
.avif)
