今年のサイバーセキュリティ意識向上月間のテーマは「Securing the Next 250(次の250年を守る)」です。脆弱性だけにとどまらず、デジタルシステムを何世代にもわたって強靭に保つために何が必要かを考えるよう、私たちに促しています。
オピニオン
1998年、私は L0pht の仲間たちとともに米議会で証言し、安全でないソフトウェアが社会を支えるシステムを危険にさらしかねないと警告しました。それ以来、技術は劇的に変化しましたが、セキュリティの根本的な問いは今も変わりません。信頼できないデータはどこから入り込むのか。コンポーネントはどのような権限を持つのか。誰がリスクを負うのか。そして、対策が機能したことをどう確かめるのか、という問いです。
2276年の技術スタックを予測することはできません。しかし、技術が進化してもソフトウェアの信頼性を保てるような実践を、今から確立することはできます。次の10項目は、その出発点として適しています。
-
セキュリティをアーキテクチャの一部にする。セキュア・バイ・デザインとは、システムをどう設計・構築するかを示す考え方です。安全な初期設定、承認済みのパターン、明確な信頼境界、そして安全でない結果を招きにくくする制御から始めます。開発の終盤になってセキュリティを導入すると、すでにアーキテクチャに組み込まれた判断に逆らって作業することになります。一方、最初から組み込まれた制御は、システムの運用と進化の一部になります。
-
自社が何を保有しているかを正確に把握する。あらゆる組織には、アプリケーション、オープンソースの依存関係、開発ツール、AIモデル、外部サービスを網羅し、継続的に更新されるインベントリーが必要です。重要なシステムについては、責任者も明確にしておかなければなりません。深刻な脆弱性が見つかったとき、影響を受けるコンポーネントがどこで稼働し、何にアクセスでき、誰が対処の責任を負うのかを、チームがすぐに特定できる状態が望まれます。
-
すべてのコードを検証する。コードは、従業員が書いたものでも、AIアシスタントが生成したものでも、サードパーティーから入手したものでも、信頼に値することを示す必要があります。私たちの調査では、AIによるコーディング作業の44%で既知の脆弱性が持ち込まれていました。こうしたツールを導入する組織には、開発と同じ速度で動き、本番環境に届く前にコードを検証する独立したセキュリティテストが欠かせません。
-
安全な道を最も楽な道にする。開発者は常にリリースへのプレッシャーにさらされています。ノイズが多すぎたり、ビルドを遅らせたり、普段使うツールから引き離したりするセキュリティ制御は、いずれ回避されてしまいます。組織は、的確なフィードバック、承認済みのコンポーネント、検証済みの修正を、リポジトリやパイプライン、コーディングのワークフローに直接組み込むべきです。そうすれば、安全な方法が作業を終えるうえで最も効率的な方法になります。
-
セキュリティの速度を開発の速度に合わせる。AIの普及で、ソフトウェアの安全性の問題は処理能力(スループット)の問題に変わりつつあります。チームは、手作業のレビューが追いつかない速さでコードを生み出し、変更できるようになったからです。そのため、テスト、ポリシーの適用、修正は開発ライフサイクル全体で継続的に実行する必要があります。反復的な作業は自動化に任せ、人はビジネスの文脈や判断力が求められる複雑な意思決定に集中すべきです。
-
ソフトウェアサプライチェーンへの流入を管理する。現代のアプリケーションは、組織が自ら書いていない大量のコードを組み合わせて作られています。依存関係が増えるたびに、理解し維持すべき関係が一つ増えます。チームは、コンポーネントがビルドに加わる時点で評価し、その由来を記録し、悪意のあるパッケージや放置されたパッケージを検出して、安全なアップグレードを計画する必要があります。インベントリーだけでは、リスクのあるソフトウェアの持ち込みを防げないためです。
-
セキュリティ負債は、返済期限が来る前に返す。Veracodeの調査によると、セキュリティ負債は現在82%の組織に影響を及ぼしています。1年以上未解決のまま残る脆弱性は、増え続けています。AIによる発見手法が、何年分もの脆弱性調査をわずか数カ月に圧縮しつつあります。経営層は、修復を継続的なエンジニアリング機能として予算化し、最もリスクの高い欠陥への対応基準を定めるべきです。あわせて、新たなリスクがチームの解消速度を上回るペースで積み上がっていないかを追跡する必要があります。
-
取り除いたリスクを測定する。多くのセキュリティプログラムは、見つけた脆弱性や解決した脆弱性の数を報告できます。しかし、こうした活動量の指標では、組織が実際に安全になったかどうかは分かりません。より有用な指標は、悪用可能な重大な欠陥がどれだけの期間さらされたままか、修正の処理能力が新たなリスクの流入に追いついているか、機密データや重要な業務に関わるアプリケーションの露出をチームがどれだけ速く減らせるか、といったものです。
-
AIシステム全体を対象に脅威モデリングを行う。AIエージェントは、モデルだけでは成り立ちません。ID、権限、ツール、メモリ、データ、ランタイム、ネットワークアクセスのすべてが、エージェントが最終的に何をできるかを左右します。組織は、機密性の高い操作が発生する場所で認可を行い、侵害されたコンポーネントが到達できる範囲を制限する必要があります。データフロー分析にはランタイムも含めます。問題が起きたときにエージェントが何をしたかを判断できるよう、十分な証拠も残しておくべきです。
-
人間の説明責任を維持する。重要なアプリケーションと受容したリスクには、いずれも責任を負う担当者が必要です。その裏付けとして、ソフトウェアのライフサイクル全体で適用した制御、実施したテスト、下した判断の証拠を残します。コードの作成や修正で機械が担う役割が大きくなるほど、人間には、出力を疑い、予期しない挙動に気づき、合理的な予防措置を講じたことを示せるだけの理解が求められます。
適応できるサイバーセキュリティの実践
今後250年のあいだに、今は名前も付けられない技術が登場するでしょう。ただ、それらを使って作られるシステムにも、入力、権限、依存関係、そして結果が存在することに変わりはありません。持続的なセキュリティは、規律あるエンジニアリング、継続的な検証、明確な責任によって実現します。それを支えるのは、複雑なシステムがどのように破綻するかを理解し、その前提を疑う方法を知っている人々です。
こうしたハッカーの思考様式は、業界に大きく貢献してきました。今後も開発者、防御者、そして次世代のセキュリティ研究者に教え続ける必要があります。ツールやアーキテクチャは変わり続けますが、信頼に値するシステムを作るという私たちの責任は、これからも変わりません。