コンピュータのセキュリティが難しい理由

⚠️ 一部の箇所では、より詳しい技術的な仕組みを説明しています。⚠️ の付いた段落や節は補足的な内容です。技術的な詳細が不要な場合は読み飛ばしても、記事の中心的な主張は理解できます。

導入

ソフトウェアは、悪条件下での動作が確立されるずっと前に完成したように見えることがあります。AI支援ツールはインターフェースや機能の開発を迅速に進めるのに役立ちますが、デモンストレーションでは選択されたパスしか実行されません。間違ったアカウントからのリクエストが拒否されるかどうか、不正なファイルが深刻な欠陥を引き起こすかどうか、依存関係の失敗によって情報が漏洩するかどうかについては、ほとんど何もわかりません。有用な動作を実証し、信頼できる限界を確立するには、別の証拠が必要です。

システムは、誤った指示、盗まれた認証情報、状態の変化、意図的な妨害行為などにもかかわらず、その限界を厳守しなければなりません。これらの限界は、アプリケーションの目に見える機能にとどまらず、IDシステム、特権サービス、ライブラリ、オペレーティングシステム、ハードウェア、保守といった領域にまで及びます。各コンポーネントは一見正しく動作しているように見えても、それらの間の判断ミスによって有害な結果が生じる可能性があります。

セキュリティは一般的に、機密性、完全性、可用性という観点から議論されます。これらは、不正な開示の防止、不正な改ざんの防止、および定義された条件下でのサービスの利用可能性の維持を意味します。これらのラベルは結果を示すものであり、保護策を示すものではありません。医療記録、口座残高、交通機関の時刻表はそれぞれ異なる規則と結果を持ちます。作業は、保護すべきもの、その要件に違反する可能性のある行為、およびそれらの行為がたどる可能性のある経路を特定することから始まります。アクセス制御が適切に行われている場合でも、機密性の低い情報を収集して保持することで、後々の侵害による被害を軽減することもできます。[1]

セキュリティ対策の有効性は、その対策が実際にどの操作を制限しているかによって決まります。ウェブサイトは不正なダウンロードをブロックする一方で、エクスポート機能は同じレコードを公開してしまう可能性があります。暗号化によってファイルは保護されていても、復号鍵が意図しない第三者に渡ってしまうこともあります。アプリケーションは1つのファイルを承認した後、同じ名前の別のファイルを開く可能性があります。いずれの場合も、ローカルの保護機能によって、実際には保護されていない操作全体が保護されているかのように見せかけてしまう可能性があります。

脅威モデルは、保護が必要な対象、攻撃者が変更できるもの、特権的な決定が行われる場所、そしてどの前提が成り立たない可能性があるかを特定します。あらゆる攻撃を予測できると主張することなく、潜在的な被害経路を明らかにするのに役立ちます。[2]

これらの経路を特定することで、システムの攻撃対象領域、つまり攻撃者が入力を送ったり、操作を要求したり、情報を取得したりする可能性のある場所が明らかになります。ネットワークサービス、サインインおよび管理インターフェース、ファイルインポート機能などは、画面上では分かりにくい場合でも、すべて侵入経路になり得ます。この攻撃対象領域を縮小するには、不要な機能やサービスを無効化し、残りの機能やサービスにアクセスできるユーザーやサービスを制限し、不要な権限を付与しないようにする必要があります。露出した経路が少なくなれば攻撃の機会は減りますが、残りの経路についても健全なチェックとメンテナンスが依然として必要です。

セキュリティが最初に失敗する場所

多くの深刻なインシデントは、特別な技術を必要としません。製造元から提供されたパスワード、人々の間で共有されたパスワード、または無関係なサービス間で再利用されたパスワードを使用しているアカウントが依然として存在します。攻撃者がそのようなパスワードを知ると、システムは設計どおりにログインを受け入れる可能性があります。パスワード推測、他の場所で漏洩した認証情報を使用した自動化された試行、ワンタイムコードの不正な要求は、パスワードをチェックするコードのエラーではなく、IDに関する脆弱性を悪用します。固有で推測しにくい認証情報、確実なアカウント復旧、レート制限、より強力なサインイン方法によって、これらの機会を減らすことができます。多要素認証とパスキーは重要な保護を提供しますが、サインイン方法によって、ログイン後に発行された指示が妥当または正当かどうかを独自に判断することはできません。[3] [4]

ユーザーはパスワードを忘れたり、ログインに使用するデバイスを紛失したりすることがあります。サービス側は、ユーザーがアクセスを回復できるよう支援する手段を提供する必要がありますが、同時に、正当なアカウント所有者とアカウントを乗っ取ろうとする人物を区別しなければなりません。アクセスをリセットするために必要な情報が他者が容易に入手できる情報のみである場合、なりすまし犯は強力なログイン保護さえも回避できてしまう可能性があります。したがって、アカウント復旧は、攻撃者にとって容易な経路を提供することなく、正当なユーザーにとって実用的な復旧手段を提供する必要があります。

サインインはアカウント保護の始まりに過ぎません。あらゆる操作でパスワードやパスキーを要求することを避けるため、多くのサービスは認証済みセッションを表すセッション識別子またはアクセストークンを発行します。攻撃者がそのような再利用可能な認証情報を入手した場合、サービスは元のログイン要素を再度要求することなく、サインインしたアカウントとしてリクエストを受け入れる可能性があります。これがセッションハイジャックです。したがって、セキュリティは、特に侵害が疑われる場合やアカウント復旧後のセッションの発行、保存、制限、期限切れ、および取り消しの方法に依存します。強力なサインイン保護と、サインイン後に保持される権限の保護は、別々の責任です。[5]

ソーシャルエンジニアリングは、意思決定における人間の部分を攻撃します。メッセージは、サプライヤーが銀行口座情報を変更した、アカウントを緊急に確認する必要がある、またはサインインページの背後にドキュメントが待っている、などと主張する可能性があります。悪意のあるリンクは、正規のサービスを巧妙に模倣したり、ダウンロードによって脆弱なアプリケーションを悪用しようとしたりする可能性があります。単にウェブアドレスを開いただけでは、アカウントを放棄したり、コンピュータを感染させたりすることにはなりません。結果は、アクセス先、ブラウザとデバイスの保護、ソフトウェアのバージョン、そしてその後に何が起こるかによって異なります。重要な違いは、保護された接続を介してページが到着することと、そのページが信頼できるものであることとの違いです。暗号化は、実際にアクセスしたサイトへの転送中のデータを保護できますが、そのサイトがユーザーが訪問しようとしたサイトであることを証明することはできません。[3]

フィッシングは、単に人が不審なメッセージを認識できるかどうかのテストではありません。Zhuo氏らが2023年に発表したSoK（知識体系）では、52件の実証研究をレビューし、個人特性、状況条件、メッセージ受信時の状況など、フィッシングにだまされやすい傾向に関連する要因を整理しました。その総合的な分析では、誰が騙されるかという普遍的なプロファイルは示されていません。したがって、保護対策は、警戒心だけで常に成功すると想定するのではなく、適切な認証、インターフェース設計、重要な指示の確認手順、トレーニングを組み合わせる必要があります。[6]

設定によっては、システムが不必要に危険にさらされたり、攻撃者がアクセスできる範囲が狭まったりする可能性があります。特定のチーム専用のフォルダが公開されていたり、内部アクセスのみを許可すべき管理インターフェースがインターネットからアクセス可能になっていたり、データベースにデフォルトの認証情報が残っていたり、テスト環境に実際のデータが緩い制限で保存されていたりする場合があります。これらは設定ミスです。ソフトウェアはプログラムどおりに動作するものの、設定によって意図しないアクセスや操作が許可されてしまう可能性があります。安全でないデフォルト設定、コピーされた設定、蓄積された例外処理はすべてリスクを高めます。

意図的な設定によって、攻撃対象領域を縮小することができます。これはハードニングと呼ばれ、必要なサービスと機能のみを有効にし、それらへのアクセス方法を制限し、制限が有効であることを確認します。たとえば、サーバーをリモートで管理するために使用される SSH サービスは、承認されたアカウントと承認されたネットワーク パスに限定し、Unix 系システムでは直接 root ログインを禁止するように設定し、適切な場合はパスワードの代わりにキーベースのサインインを使用するように設定できます。リモート管理が不要な場合は、SSH を完全に無効にすることができます。これらの対策により、サービスへのアクセス経路が排除または制限されますが、残りのコードに脆弱性がないことを保証することはできません。ハードニングは、正当なアクセスを維持し、実際に展開されたシステムで検証する必要もあります。[4]

認証情報はパスワードよりも広範です。ソフトウェアサービスは秘密鍵とアクセストークンを使用して相互に通信し、従業員や契約社員は強力な管理者アカウントを持っている場合があります。コードリポジトリに誤って公開された鍵、ログに含まれた鍵、またはサプライヤーとの契約終了後も保持された鍵は、暗号化を解読しようとしなくてもアクセスを許可してしまう可能性があります。攻撃者が必要な復号鍵を入手したり、平文を開示する権限を持つサービスを制御したりすれば、暗号化によって情報漏洩を防ぐことはできません。したがって、保存された情報の保護は、アルゴリズムだけでなく、鍵の取り扱いと復号へのアクセスにも依存します。組織は、日常業務を行う従業員に、職務に必要な範囲をはるかに超えるアクセス権限を与えている場合もあります。適切な対応策としては、認証情報の保管場所を管理し、その範囲を制限し、不要になった場合は削除し、不審な使用を特定できるようにすることなどが挙げられます。ログは発生した事象の特定に役立ちますが、ログ記録だけでは悪用を防ぐことはできず、不注意に設計すると機密情報が含まれる可能性があります。根本的な懸念は、デフォルトパスワードの場合と同じです。技術的に有効な認証情報は、本来発行されるべき目的をはるかに超えた権限を与える可能性があります。[2]

これらの事例には重要な共通点があります。それは、承認された認証情報、もっともらしいメッセージ、あるいは許可された設定によって、誰も意図していなかったアクションが実行されてしまう可能性があるということです。意思決定を保護するには、単に注意を促すだけでは不十分です。サービス側で推測を制限し、リスクの高い権限を例外的に付与し、重大な変更に対して独立した確認を提供する必要があります。さらに難しいのは、より強力なコンポーネントが他者の代理として動作する場合も含め、これらの制御が実際の運用を確実に管理できるようにすることです。

身元確認、許可、および委任された権限

認証は、リクエストがどのアカウントまたはその他のIDから発信されたものかを特定します。認可は、そのIDが特定のレコードまたは操作に対して何を実行できるかを決定します。従業員が正しくサインインしていても、他の従業員のファイルを読む権限がない場合があります。レコード番号を知っていることやリンクを持っていること自体は、レコードを取得する許可にはなりません。エクスポートボタンを非表示にしながら、同じ情報をエクスポートできる基盤となるインターフェースを自由に使えるようにしているシステムは、操作ではなく画面を保護していることになります。直接リクエスト、バックグラウンドジョブ、内部サービスなど、関連するすべての経路は、保護された効果が発生する時点まで必要な許可決定を伝達する必要があります。[7]

Confused Deputy 問題は、ソフトウェアが呼び出し元に権限のない要求を実行するために、自身のより広範な権限を使用するときに発生します。たとえば、レコードサービスがすべてのファイルを読み取る権限を持っている一方で、一般ユーザーは自分のファイルのみを取得する必要がある場合があります。サービスが呼び出し元の権限を確認せずに任意のレコード識別子を受け入れると、他人の情報が返される可能性があります。ユーザーはサービスのマスター権限を取得することはなく、サービスがユーザーに代わってそれらを悪用します。したがって、特権を持つ仲介者が要求した人なら誰でも保護レコードを取得できる場合、保護レコードを隔離するだけでは不十分です。[8]

適切な委任インターフェースは、特権コンポーネントが引き受ける作業を限定します。無制限のファイルパスを受け入れるのではなく、呼び出し元の権限に関連付けられた特定の許可された操作、または特定のリソースに対する権限を証明する用途を限定したケーパビリティを受け入れることができます。これは最小権限の原則の適用です。アカウント、コンポーネント、およびサービスは、その職務に必要なアクセスと操作のみを受け取ります。また、ミスの影響範囲も制限します。つまり、他のコンポーネントが代行して実行する場合を含め、障害によって影響を受ける情​​報とアクションの範囲が制限されます。コンポーネントはプライベートファイルに直接アクセスできない場合でも、要求が十分に制限されていない場合は、より強力なサービスを介して間接的にそれらのファイルを公開する可能性があります。[9] [10]

権限は技術的な身元情報だけで判断できるものではありません。正当な従業員が不正な支払い情報変更指示を受け取る可能性があり、正当な管理者が危険な設定を承認してしまう可能性もあります。コンピュータは従業員のアカウントを正しく認証しても、業務要求の発信元を信頼する根拠がない場合があります。重大な変更については、独自に確立された連絡先情報を用いた確認によって、指示が意図した相手から発信されたものであることを保証できます。このような手順は不正な指示への対策には役立ちますが、アプリケーション内の認証チェックの不備を解消するものではありません。異なる脆弱性には、それぞれ異なる保護策が必要です。

さらに危険なのは、正当に付与されたアクセス権を意図的に悪用することです。正しくログインして機密記録の閲覧を許可されている人物が、それを権限のない第三者に開示したり、管理機能を悪用したりする可能性があります。認証と認可はどちらも設定どおりに機能するかもしれませんが、個人の意図を立証することはできません。権限を限定し、機密性の高い職務を分離し、結果的な行動を適切に記録し、独立したレビューを行うことで、このような内部者による悪用を制限または明らかにすることができます。[11]

操作を実行する許可は、その操作がより大きなプロセスのすべての段階で有効であることを保証するものではありません。必要な支払い条件が満たされるまで、注文は履行段階に進んではなりません。1回の使用を目的としたバウチャーは、各リクエストが適切に作成され、対象となるアカウントから送信されたという理由だけで、繰り返し使用されてはなりません。これらはビジネスロジックの欠陥です。アプリケーションは、関連するアクションを規定する前提条件、有効なシーケンス、または制限を適用していません。このようなルールは、表示された画面や要求者が主張するステップから推測するのではなく、結果として生じる遷移において権威ある状態と照合してチェックする必要があります。この欠陥は、競合状態、悪意のあるコマンド、またはアカウントの盗難がなくても存在し得ます。[12]

正しいチェックが適用されなくなった場合

権限チェックは実行時には正しくても、後続の操作を保護する役割を果たさなくなることがあります。ファイルが承認された後、プログラムがファイルを開く前に置き換えられる場合があります。2人の作業者がそれぞれ十分な在庫を確認した後、両方ともそれを消費してしまう場合もあります。これらは、チェック時と使用時（TOCTOU）の問題です。検査された状態は、結果的な操作が実行される状態とはもはや一致しません。これらの問題は、別の当事者がそのギャップを利用して必要な規則に違反できる場合に、セキュリティ上の脆弱性となります。並行操作から生じるものもあれば、作業中にIDや権限が変化するリソースに関するものもあります。[13]

ファイルパスを承認済みの場所と照合し、後でそのパスを開くプログラムを考えてみましょう。攻撃者がその期間中にパス名を変更できる場合、プログラムは承認済みのファイルとは異なるファイルを処理してしまう可能性があります。対策としては、実際に使用されるリソースと状態に決定を適用することです。システムによっては、既に開いて検証済みのファイルハンドルを操作する、アトミック操作またはトランザクションを使用する、適切なロックを保持する、あるいは既に開始された作業に対する取り消しの影響を定義するといった方法が考えられます。次のギャップを閉じずにチェックを繰り返しても、安全性は保証されません。

並行処理は、ファイルアクセス以外にも関連する障害を引き起こします。個別に有効な複数のリクエストが、古い状態に対してチェックされると、合計でアカウントの制限を超える可能性があります。長時間実行されるジョブの実行中に権限が取り消されたり、別のコンポーネントが同じオブジェクトを参照していると想定している間に識別子が再割り当てされたりする可能性があります。安全な設計では、どの状態が権限を持つのか、そしてチェックとそれに続く操作がどのように一貫性を保つのかを明確に指定する必要があります。

情報が作業の方向性を定めることを許可した場合

プログラムは、ユーザー要求、インポートされたファイル、ネットワークメッセージ、その他のサービスを通じて提供されるデータを処理します。値は正しく構成されている場合でも、それが制御する操作には不適切な場合があります。ファイル名が意図したフォルダの外を指し示す可能性があります。レコード識別子が他人のデータを選択する可能性があります。小さな圧縮ファイルでも、展開時に膨大な処理負荷が発生する可能性があります。このような素材を信頼できない入力と呼ぶことは、その特定の用途に必要な特性がまだ確立されていないことを意味します。これは、すべての送信者が悪意を持っているという意味ではありません。同じ欠陥は、意図的な操作、破損したファイル、または通常のミスによって発生する可能性があります。[14]

データが命令になることを許容すると、危険な遷移が発生します。プログラム テキストと外部値を組み合わせて組み立てられたデータベース クエリまたはオペレーティングシステム コマンドでは、その値がコマンド自体を変更してしまう可能性があります。これはインジェクションの脆弱性です。Web ページも同様に、外部から提供されたテキストが、ブラウザがテキストとして表示するのではなくコードとして解釈するコンテンツに組み込まれている場合に失敗する可能性があります。これはクロス サイト スクリプティングです。これを防ぐには、ブラウザが解釈する特定のコンテキストに合わせてコンテンツを処理する必要があります。より安全なインターフェースでは、意図した操作を変数データから分離します。たとえば、インターフェースがサポートしている場合は、パラメータ化されたデータベース クエリを使用します。解決策は疑わしい文字の一般的なリストではありません。プレーン テキストとして安全な値でも、コマンド、ファイル パス、または別の言語の一部として解釈されると安全でない場合があります。正しく構築されたデータベース クエリであっても、要求者がその結果を取得する権限を持っているかどうかを別途チェックする必要があります。[15] [16]

有害な入力の中には、コマンドが全く含まれていないものもあります。メディアデコーダーは、意図したよりも多くのメモリを割り当てるように要求される可能性があり、複雑なドキュメントは過剰な処理時間を消費する可能性があり、許可されたリクエストが繰り返されると、共有サービスが過負荷になる可能性があります。リソース制限は、コストのかかる作業の前と作業中に強制する必要があり、コストが既に支払われた後に強制するべきではありません。結果として生じる障害は、制御された拒否、クラッシュ、または他のユーザーが利用できなくなるサービスになる可能性があります。これが、セキュリティがシステムが正当な作業を継続できるかどうかにも関係する理由です。サービスが利用可能であり続けることを約束する条件と、その約束の制限は、アクセスルールと同様に正確であるべきです。[14]

これらの障害は、信頼できない情報が境界を越える場所によって異なる。時には命令として解釈され、時にはリソースを枯渇させ、時には自身のメモリを安全に管理できないコードによって処理される。最後のケースは、入力にコマンドが含まれていない場合でも、不正なファイルやメッセージがプログラムのデータ格納およびアクセス方法を悪用する可能性があるため、特に注意が必要である。

メモリ安全性とプログラミング言語の保証

実行中のプログラムはすべて、メモリと呼ばれる作業用記憶領域を必要とします。プログラムは、割り当てられた領域に値を格納し、それらの値を使用し、最終的に不要になった記憶領域を解放します。基本的な要件として、1つの操作が割り当てられた領域外への読み書きを行ってはならないという点があります。また、オブジェクトのライフサイクルが終了した後も、そのオブジェクトに属しているかのように記憶領域を使用し続けてはならないという点もあります。これら2つの保護は、メモリの安全性において極めて重要です。これらは、そもそも操作を要求する権限があったかどうかではなく、メモリ操作の正当性に関わるものです。

ファイリング係（「コンピュータの仕組み：ファインマンの高速ファイリング係」を参照）は、直接的な類推を提供している。ファイリングトレイには100枚のカードを入れるスペースがあるが、命令では120枚挿入するように要求されている。トレイの境界を強制するルールがなければ、余分なカードは他のレコードが置かれるべき場所に置かれてしまう可能性がある。コンピュータでは、割り当てられた領域を超えてチェックされない書き込みを行うと、無関係なデータが破損する可能性がある。チェックされない読み取りを行うと、別の領域の情報が漏洩する可能性がある。プログラムと周囲の保護機能によっては、クラッシュや誤った結果から、攻撃者が悪用できる脆弱性まで、さまざまな結果が生じる可能性がある。チェックされた操作は、代わりに不正なアクセスを阻止する。要求されたファイリング作業は失敗するかもしれないが、この特定の境界は維持される。カードはメモリ位置の比喩であり、オーバーフローが発生するたびに攻撃者に制御権が与えられるという主張ではない。

プログラムがオブジェクトのストレージが解放された後もそのオブジェクトへの参照を保持し続けると、別のメモリエラーが発生します。同じ領域が後で別のオブジェクトに再利用された場合、古い参照によって無関係な情報が読み取られたり上書きされたりする可能性があります。これは解放後使用エラーです。境界チェックだけではアクセスを有効にすることはできません。アドレスは割り当て済みの領域内に収まるかもしれませんが、参照を意味のあるものにしていたオブジェクトはもはや存在しないからです。空間保護とライフタイム保護は、それぞれ異なる障害に対処します。

CやC++といった古くから広く使われているシステム言語では、プログラマが必要な境界とライフタイムルールを設定することで、直接メモリ操作を行うことができます。こうした制御によって重要なソフトウェアが開発されてきましたが、安全でない経路でのミスは深刻な結果を招き、検出も困難です。慎重な実装、コードレビュー、自動分析、保護コンパイラオプション、そしてテストによってリスクは軽減されますが、あらゆる実行が定義上安全になるわけではありません。また、製品にCやC++が含まれているからといって、その製品が脆弱であるとは限りません。重要なのは、関連する入力を処理する特定のコード、そのコードが使用するチェックや保護機能、そしてエラーが発生した場合にそのコードが持つ権限です。

メモリセーフ言語機能は、言語またはそのランタイムによって強制されるルールに負担の一部を移します。Safe Rust は、プログラムの実行前に多くの無効な参照を拒否し、必要に応じてインデックス付きアクセスをチェックします。通常の安全な Swift 機能は、境界と管理されたライフタイム制約を強制します。Python アプリケーション コードは通常、生のポインタ演算を行うのではなく、管理対象オブジェクトを操作します。これらの言語は、正しいセキュリティ決定の必要性をなくすものではなく、その保護がすべてのネイティブ コンポーネントに必ずしも及ぶわけではありません。Rust には明示的に安全でない領域があります。Swift は C ライブラリを呼び出したり、安全でないポインタを使用したりする場合があります。Python はネイティブ拡張機能をロードする場合があります。メモリセーフ アプリケーションがメモリ安全でないコードにデータを渡す場合、その境界とそれを超えるコードを検査する必要性を継承します。言語の選択は重要なリスクの種類を変えますが、製品は実際に実行される操作によって判断されなければなりません。[17] [18] [19]

Szekeres、Payer、Wei、Songによる2013年のSoKは、メモリ破損攻撃がどのように発生し、さまざまな防御策が何を阻止しようとしているのかを検証した。彼らの分析では、無効なメモリ操作の防止、破損の検出、欠陥発生後の攻撃の困難化を区別している。これらは本質的に異なる保証である。この論文は、より新しいコンパイラやハードウェアによる緩和策よりも前に発表されたものだが、その分類は、攻撃手法をブロックしても根本的なメモリ欠陥が除去されたとは限らない理由を説明している。[20]

より安全な言語は役立ちますが、既存のシステムを一夜にして置き換えることはできません。C と C++ はオペレーティングシステム、ファームウェア、専門ライブラリに深く組み込まれており、その多くはパフォーマンス、ハードウェア、互換性の制約に直面しています。それらを書き換えると、それ自体に欠陥が生じる可能性があり、チームは代替案を検証するためのスキルとツールを必要とします。だからといって、安全でないメモリ処理を無期限に受け入れることが正当化されるわけではありません。実際の評価では、信頼できないデータがチェックされていない操作に到達する場所、どのネイティブ依存関係が残っているか、それらのコンポーネントがどのような権限を持っているか、そしてテスト、緩和策、保守がリスクにどのように対処するかを検討する必要があります。言語ラベルだけでは、これらの質問に答えることはできません。[2]

設計そのものに脆弱性があるとき

設計上の脆弱性は、メモリ処理やサンドボックスの適用における欠陥と全く同様に深刻な問題となり得ます。これは、ソフトウェアが本来のルールやワークフローを正しく遵守しているにもかかわらず、それらのルールやワークフローが有害な結果を許容してしまう場合に発生します。メモリセーフなコード、厳密に制限されたコンポーネント、強力な暗号化といった対策を講じても、保護された操作へのアクセスを誤った人物に許してしまうような設計上の欠陥を補うことはできません。

架空の暗号化バックアップサービスを想像してみてください。このサービスの復旧機能では、ユーザーはログインする必要がありますが、ログイン後、ユーザーが指定したバックアップ識別子に対応する復旧キーを返します。ただし、バックアップがユーザーのものであるかどうかは確認しません。通常のユーザーアカウントを持つ攻撃者が、別の顧客の識別子を知った場合、その顧客のキーを取得できてしまいます。暗号化が破られることも、メモリが破損することも、サンドボックスから脱出することもありません。このシステムは、必要な認可チェックを設計上求めていなかったために、秘密情報を渡してしまうのです。

暗号化は、不完全なセキュリティ決定に適用される適切な保護策のもう1つの例を提供します。暗号化は、相手側がどのサービスであるか、または要求を受け入れるべきかどうかを判断することなく、コンピュータ間でやり取りされる情報を保護できます。これらは別途チェックが必要です。プロトコルは、通信システムが使用することが期待されるメッセージとチェックを規定します。実装は、これらの規則に従うソフトウェアです。実装は必要なチェックを省略する可能性があり、プロトコル自体が必要な要件を省略する可能性もあります。したがって、1つの保護策が正しく機能しても、完全な操作のセキュリティが確立されるわけではありません。[21]

ウェブサイトに接続するプログラムを考えてみましょう。暗号化された接続を確立し、信頼できる発行者からの証明書を受け入れるかもしれませんが、その証明書がアクセスしようとしているウェブサイトを識別しているかどうかは確認しません。暗号化は機能しますが、プログラムは偽者と通信している可能性があります。同様の間違いは、一部のサービスがリクエストを受け入れるかどうかを決定するために使用するデジタル認証情報である署名付きアクセス トークンでも発生します。プログラムはトークンの署名を検証するかもしれませんが、それが承認された発行者からのものであるか、このサービス向けであるか、まだ有効であるかは確認しません。どちらの場合も、1 つの正しいチェックによって、もう 1 つの必要な決定が未解決のままになります。どちらの失敗も、暗号化の破綻や署名の偽造を必要としません。ロス アンダーソンの「なぜ暗号システムは失敗するのか」は、暗号化による保護と実際のシステムの失敗との間のより広範なギャップを検証しています。[22] [23] [24]

Clarkとvan Oorschotによる2013年のSSLとHTTPSのSoKは、証明書の発行、ブラウザの信頼判断、インフラストラクチャの慣行が暗号化された接続のセキュリティにどのように影響するかを調査した。彼らの研究は、暗号化をそれ自体で十分とみなすのではなく、より広いシステムの中にIDと証明書の信頼を位置づけた。この研究は、今日のTLSの展開やその後導入された保護ではなく、当時のメカニズムを検証したものであり、現在の実装は現在の標準に照らして評価する必要がある。[25]

秘密情報は、意図された回答ではない動作によっても漏洩する可能性があります。異なるエラーメッセージによって、アカウントが存在するかどうかが明らかになる場合があります。秘密情報に応じてチェックにかかる時間が異なる場合、その差が確実に観測できれば、タイミングサイドチャネルを通じて情報が漏洩する可能性があります。これらの漏洩は、秘密情報を直接要求したり、暗号化アルゴリズムが破られたりすることなく発生する可能性があります。測定可能なすべての差が悪用可能というわけではありません。信号、条件、そして推測できる内容がすべて重要です。[26]

セキュリティは、攻撃者が設計者が想定していなかった状況を意図的に作り出す可能性があるため、通常の障害処理とは異なります。不正な入力、異常なリクエストシーケンス、または侵害された依存関係は、目的の効果が得られるまで繰り返し試行される可能性があります。ルーチンテストは既知のケースの動作を示しますが、すべての悪意のある組み合わせが排除されていることを証明するものではありません。問題は、想定が外れた場合にどの安全対策が有効に機能するかということです。

設計上の脆弱性はプロトコルに組み込まれることもあります。実装は、ルールが有効なメッセージを再生、リダイレクト、または悪用する方法を残していても、そのルールに忠実に従う可能性があります。ロス・アンダーソンとロジャー・ニーダムは、Programming Satan’s Computerでこの敵対的な視点を探求しました。[27] 正しく仕様が定められ実装されたソフトウェアでさえ、ハードウェアが期待する境界を維持することに依存しています。

ハードウェア自体に脆弱性がある場合

ソフトウェアは、ハードウェアが基本的な制約を強制することに依存している。あるプログラムが別のプログラムの保護されたメモリを変更できないようにし、プロセッサによって制限された情報にはアクセスできないようにし、デバイスは信頼できる状態から起動する必要がある。しかし、プロセッサ、メモリチップ、そしてデバイスを起動する低レベルコード自体が複雑なエンジニアリングシステムである。それらの動作は、上位のアプリケーションが正しく記述されていても、セキュリティルールを損なう可能性がある。

⚠️ Rowhammerは、予期せぬ物理的な弱点を示しています。一部のメモリチップでは、特定のメモリ位置に繰り返しアクセスすると、保存されているビットが変化するまで隣接するセルが電気的に影響を受けることがあります。ソフトウェアはこれらの変更を要求していません。研究者たちは、脆弱なシステムで特定の条件下では、この効果を利用してメモリ保護を回避し、より高い権限を取得できることを示しました。プログラムは書き込みが許可されている場所に関するルールに従うかもしれませんが、物理メモリはこれらの制限外の情報を変更する可能性があります。Rowhammerはすべてのメモリ設計に均等に影響を与えるわけではなく、その実用的な悪用可能性と対策はハードウェアとシステムに依存します。[28] [29]

⚠️ その他のハードウェアの脆弱性によって、情報を変更することなく情報が漏洩する可能性があります。最新のプロセッサは、時間を節約するために、必要な命令を予測して事前に作業を実行することがあります。これは投機的実行と呼ばれます。予測が間違っていることが判明した場合、暫定的な結果は破棄されますが、その作業の痕跡はキャッシュ（プロセッサが最近使用した情報をすばやく取得するのに役立つ小さなストア）に残る可能性があります。これらの痕跡を測定すると、プログラムが読み取ることを許可されていない秘密が明らかになることがあります。Spectreは、操作された予測を利用してこのような情報漏洩を引き起こします。Meltdownは、アクセス違反が発生する前に一部のプロセッサが保護されたデータを処理する方法の別の脆弱性を悪用しました。これらはプロセッササイドチャネルであり、前述のタイミングリークに関連しています。これらは、ソフトウェアが要求できる操作を記述する公開された命令セットだけでなく、プロセッサが内部で命令を実行する方法に関係します。影響を受けるプロセッサ、条件、および対策は異なります。[30] [31] [32]

セキュリティは、オペレーティングシステムが起動する前に失敗することもあります。セキュアブートは、起動の各段階が実行される前に承認されていることを確認することで信頼の連鎖を確立します。一部のデバイスは、最初のブートコードを読み取り専用メモリ（ROM）に保存しますが、これは通常、製造後に書き換えることはできません。これにより、後からの改ざんは難しくなりますが、元の検証ルーチンまたはリカバリルーチンの欠陥がROMで修復できない可能性があることも意味します。

⚠️ 2018年に公表されたTegra X1のリカバリモードの脆弱性「Fusée Gelée」は、リモートネットワークサービスではなく、物理的なUSBアクセスを介して到達可能な欠陥を示しています。ソフトウェアの変更と運用上の制限によりリスクを軽減できますが、真に不変のブートROMを書き換えることはできません。セキュアブートは、信頼の基点の保証と、それがカバーする攻撃条件の範囲内で依然として価値があります。[33] [34] [35]

⚠️ GlosnerとMachiryによる2026年のSoKでは、ハードウェアルートのハンドオフに続くソフトウェアブートチェーン内の43個のブートローダーを調査しました。BOOTBENCHデータセットには、報告された3,658件の脆弱性と関連する変更が収集されており、著者らは既存の検出および強化技術の限界を特定しました。これらの数値は、すべてのブートローダーが悪用可能であること、または特定のデバイスが脆弱であることを証明しているわけではありません。これらの数値は、ブートソフトウェアが正規のソースから提供されたことを検証することと、正規の実装に悪用可能な欠陥がないことを立証することとの違いを示しています。[36]

ハードウェアは、単層セキュリティの限界を如実に示している。アプリケーションのセキュリティは、プロセッサのメモリ制御、ブートチェーン、そして謳われているハードウェア保護機能の実装に部分的に依存する。これらの依存関係は、ハードウェアによる防御を無意味にするものではなく、ソフトウェアがそれらに依拠できる条件を規定するものである。

失敗が広がる前に食い止める

セキュリティ エンジニアリングは、防止できなかった欠陥の影響も制限します。見慣れないファイル形式を扱うプログラムは、呼び出し元のアプリケーションと同じプライベート レコード、ネットワーク サービス、強力な操作へのアクセス権を自動的に取得すべきではありません。オペレーティングシステムは、実行中のプロセス間の境界を強制し、その権限を制限できます。サンドボックスは、そのような強制された制限の集合です。重要なのは、どの実行中のコンポーネントがどのリソースから排除されているかということです。ファイルを別のソース フォルダーに配置したり、異なるプログラミング言語で関数を呼び出したり、ライブラリを隔離されていると記述したりしても、それだけではオペレーティングシステムの境界を確立することはできません。[10]

メインアプリケーションにロードされたネイティブデコーダは、通常、そのアプリケーションのプロセス、メモリ、および権限の大部分を共有します。デコード処理を別のプロセスに移動すると、ワーカーは独自のアドレス空間を持つことになります。ワーカーに適切な範囲の制限を追加することで、欠陥や侵害が直接影響を与える範囲を縮小できます。どちらのバージョンも同じ外部アプリケーションサンドボックス内に配置できます。追加の保護は、ワーカー自身の境界と権限によって実現されます。この構成には、通信、タイムアウト、およびリカバリにコストがかかり、ホストはワーカーの結果を検査する必要があります。ホストから任意の特権ファイル操作を要求できる制限付きワーカーは、プロセス境界を越えて混乱した代理人の問題を再現する可能性があります。

これらの境界が実際にどのように成功または失敗するかについては、多くの研究が行われています。Lefeuvre らによる 2025 SoK では、211 の研究と 61 の主流の区分化システムが分析されました。この分析では、使用可能な分離ポリシーの定義、研究の実運用への応用、Confused Deputy 問題やハードウェアの制約に関連する脅威の評価において、依然として困難が残っていることが明らかになりました。権限が過剰であったり、特権を持つホストがそこからの無制限の要求に応答したりする場合、別のプロセスは効果的な封じ込めの証明にはなりません。関連するエンジニアリング タスクは、インターフェースの両側で使用可能な権限を定義し、強制された境界がその設計と一致していることを実証することです。[37]

封じ込めは、予防と被害軽減の役割が異なるという一般的な原則を示しています。入力チェックは、有害な操作が開始される前に拒否することを目的としています。メモリ安全規則は、特定の無効なアクセスを阻止します。サンドボックスは、欠陥のあるコードがアクセスできるリソースを制限します。監視と復旧は、サービスが起こりうる障害を認識して対応するのに役立ちます。複数の保護によって1つのミスの影響を軽減できますが、それらの独立性は想定するのではなく、確立する必要があります。したがって、悪用された欠陥は制限されたコンポーネント内に留まる可能性があり、システム全体へのアクセスを自動的に許可するわけではありません。誠実なセキュリティ主張は、技術の数を数えたり、「安全」という言葉を宣伝したりするのではなく、禁止されている影響と関連する制限を強制するメカニズムを特定します。[38]

⚠️ 封じ込めとハードウェア保護の限界

保護機能の中には、名前や設定が異なるため独立しているように見えるものもありますが、実際には同じ権限に依存しています。アプリケーションサンドボックス、プロセス分離、強制アクセス制御などは、一般的にオペレーティングシステムのカーネルに依存して制限を適用します。カーネルは、プログラム、メモリ、権限を管理する中心的なコンポーネントです。攻撃者がカーネルを十分に制御できるようになった場合、これらの保護機能が依存するルールを変更したり無視したりできる可能性があります。複数の保護層は、必ずしも複数の独立した防御線を意味するものではありません。[39]

ハードウェアによる緩和策は、カーネルの侵害をより困難にすることができます。ポインタ認証（PAC）は、選択されたポインタに署名して認証することで、ポインタの破損に依存する一部の制御フロー攻撃を阻止します。Memory Integrity Enforcement（MIE）をサポートするAppleシステムでは、ハードウェアメモリタグ付け、型付き割り当て、および関連するオペレーティングシステムの制限により、保護されたシステムコードに対する攻撃を含む、メモリ破損の悪用クラスが阻止されます。どちらのメカニズムも、攻撃者がカーネルを十分に制御できるようになると、アプリケーションサンドボックスポリシーを維持できる独立した機関にはなりません。[40]

一部の保護機能は、カーネルの通常の制御範囲外で動作します。サポートされているAppleシステムでは、セキュアページテーブルモニタ（SPTM）が信頼できる実行モニタと連携して、攻撃者がカーネル書き込み権限を取得している場合でも、選択されたページテーブルの変更を制限します。これらは、ハードウェアでサポートされているメモリとコードの整合性に関する限定的な制限であり、ユーザー、ファイル、またはネットワークアクセスに関するカーネルの決定に対する継続的な信頼ではありません。どのプロパティが維持されるかは、プラットフォームと攻撃者の能力によって異なります。[39]

Secure Enclave（セキュアエンクレーブ）は、独立した強制境界の一例です。サポートされているAppleデバイスでは、セキュアエンクレーブは独自のセキュア起動、保護されたメモリ、マイクロカーネルを備えたセキュリティプロセッサです。メインのオペレーティングシステムカーネルが侵害された場合でも、選択された秘密情報を保護するように設計されています。アプリケーションは、セキュアエンクレーブによって処理される操作の秘密鍵を生成し、鍵自体を受け取ることなく許可された暗号化作業を要求できます。保護される内容は、単にチップの存在ではなく、鍵のアクセス ポリシーとエンクレーブが強制する操作によって決まります。[41] [42]

他のシステムでは、ハードウェアによって強制される異なる境界が使用されます。独立したデバイスとして、またはプロセッサ内に実装されるトラステッド プラットフォーム モジュール (TPM) は、選択された暗号鍵を保護し、その使用をシステムの起動方法の測定に紐付けることができます。これは、アプリケーション コードを実行するための汎用環境ではありません。Arm TrustZone は、サポートされているプロセッサ上でセキュアな実行状態と通常の実行状態を分離するため、システムが正しく設計されている場合、指定されたソフトウェアとリソースは通常のオペレーティングシステムからアクセスできない状態を維持できます。Intel Software Guard Extensions (SGX) は、サポートされているプロセッサ上で、選択されたアプリケーション コードとデータを特権ソフトウェア (オペレーティングシステム カーネルを含む) からエンクレーブ内に分離します。Apple の Secure Enclave とは異なり、TrustZone と SGX は、別のセキュリティ プロセッサを必要としません。また、保護するリソースが異なるため、互換性があるものとして扱うことはできません。[43] [44] [45]

セキュリティ権限の一部をメインカーネルから独立させておくことで、カーネル侵害後のプラットフォームの信頼回復にも役立ちます。カーネルの制御範囲外にアンカーされた信頼できる起動または回復パスにより、デバイスがサービスに復帰する前に、承認されたファームウェアとオペレーティングシステム ソフトウェアをチェックできます。保護されたキーとブート プロセスの測定は、これらのチェックをサポートする可能性があります。NIST は、不正な変更の検出、更新の承認、および破損したプラットフォーム ファームウェアの回復のための信頼のルートを区別しています。これらの要素は、機能する回復プロセスに組み込む必要があります。TPM、Secure Enclave、TrustZone 環境、または SGX エンクレーブだけでは、侵害されたオペレーティングシステムを回復することはできません。[35] [38]

このような復旧は、定義された脅威モデルの範囲内でのみ可能です。復旧ファームウェア、ハードウェアの信頼の基点、および代替ソフトウェアのソース自体が信頼できる状態を維持する必要があります。侵害されたカーネルが置き換えられるまで、攻撃者は、一部のキーやエンクレーブメモリにアクセスできない場合でも、コンポーネントの保護要求を操作したり、サービスを拒否したり、保護前またはリリース後に情報を検査したりする可能性があります。復旧によって既に開示された情報を元に戻すことはできません。重要なのは、侵害中に選択された状態を保護することと、その後信頼できる動作を再確立することの違いです。

Zinkus、Jois、Greenによる2022年のSoKは、物理的なデバイスアクセスや関連するクラウドサービスへのアクセスを持つ攻撃者を含む、強力な抽出攻撃者に対するモバイルデバイス上のデータ機密性を検証した。その範囲は鍵の保護にとどまらず、情報は保護される前、復号後、または依存サービスを通じて漏洩する可能性もある。この過去の分析は、現在のSPTMやSecure Enclaveの動作を正当化するものではない。どの情報がどの機能から保護され、どこで信頼できる境界を越えるのかを明確にする必要があることを強調している。[46]

カーネル依存の保護機能の限界

SPTMはカーネル侵害後も特定のメモリ制限を維持する可能性があり、セキュアエンクレーブは指定されたキーを保護する可能性があります。しかし、どちらも単独ではオペレーティングシステムの信頼性を回復するものではありません。

iPhoneはMIEとPACをサポートしているかもしれませんが、だからといって、その上で動作するすべてのアプリが両方の保護機能を使用しているとは限りません。Appleは、カーネルを含む選択されたシステム攻撃対象領域にMIEを自動的に展開します。このカバレッジは、すべてのサードパーティ製アプリ、拡張機能、ヘルパープロセス、ライブラリに自動的に適用されるわけではありません。そのため、同じサポート対象のiPhone上で動作する2つのアプリでも、異なる保護機能を持つ場合があります。MIEは、Appleが設計したハードウェア、セキュアメモリ割り当て機能、およびオペレーティングシステムの制御機能を組み合わせたものであり、一般的なArm Memory Tagging Extension（MTE）とは異なります。

開発者が独自のアプリでハードウェア メモリ タギングを使用するには、関連する Xcode ターゲットでそれを有効にし、ハードウェアがそれをサポートしていることを確認する必要があります。 エンタイトルメントとランタイム設定も重要です。シミュレートされた障害を報告する診断モードは、チェックを強制することとは異なります。 PAC は別の緩和策です。互換性のあるハードウェアだけでは、すべてのアプリ バイナリが PAC を使用するとは限りません。関連するコードは適切な arm64e アーキテクチャ用にビルドする必要があり、外部ネイティブ ライブラリは互換性のあるビルドが必要です。開発者は、コンポーネントと依存関係を含め、実際のリリースでどの保護が有効になっているかを確認し、サポートされている物理デバイスでテストする必要があります。デバイス仕様は、特定のアプリで保護が機能していることの証明にはなりません。[47] [48] [49]

アーキテクチャ図や機能一覧だけでは、リリースされた製品においてどの安全対策が有効であるかを立証することはできません。重要なのは、実際にどのプロセスが保護されているか、各制限をどの機関が執行しているか、そして想定される障害発生時に何が保護されたままになっているか、といった点です。

安全対策が失敗した場合

必要なチェックや操作が失敗した場合でも、セキュリティ制限は維持されなければなりません。認可サービスが利用できない場合、決定が得られなかったとしても、続行の許可は得られません。複数ステップの変更が途中で停止した場合、部分的に更新されたレコードは、操作が維持しようとしていたルールに違反する可能性があります。特定のタスクに対して、応答を定義する必要があります。未検証のアクションを拒否または延期し、一貫性のある状態を維持し、中断された作業を回復可能にする必要があります。エラーを承認として扱うことは、フェイルオープンの欠陥であり、すべてのエラーを永続的な停止として扱うことも適切な設計ではありません。[50]

侵害は、最初に到達したアカウントやプロセスで必ずしも止まるわけではありません。攻撃者はその足がかりを利用して、特権昇格と呼ばれるより高い権限を取得したり、横方向移動と呼ばれる追加のシステムに侵入したりする可能性があります。その後の各ステップは、別の使用可能な脆弱性、認証情報、または信頼関係に依存します。1 つのサービスを制御したからといって、自動的に隣接するサービスを制御できるわけではありません。これが、最初の足がかりで利用可能な権限、システム間の分離、および特権要求に対するチェックが、攻撃がどこまで広がるかを決定する理由です。封じ込めは、最初のコンポーネントが侵害された後でも、進行を阻止することができます。[51] [52]

予防と封じ込めだけでは不十分な場合、運用復旧が重要になります。管理者権限を取得した攻撃者は、記録を変更したり、ファイルを消去したり、データを使用不能にするランサムウェアを展開したりする可能性があります。バックアップは破壊や破損による被害を軽減できますが、既に盗まれた情報を元に戻すことはできません。侵害された権限で保持されているバックアップも、攻撃者によって変更または消去される可能性があります。そのため、セキュリティパッチと並んで、復旧可能で適切に保護されたコピーと、復元を検証する演習が重要になります。監視によって異常なアクティビティを検出し、証拠を保全できます。インシデント手順では、影響を受けたシステムを隔離し、認証情報を取り消し、信頼できるサービスを復旧できる人物を定義します。これらの対策は、セキュア設計が失敗したことを認めるものではありません。システムの保護には、依然として発生する可能性のある障害による被害を制限し、正当な作業を既知の良好な状態に戻すことが含まれることを認識しています。[38]

サプライチェーンがセキュリティを損なう場合

小規模なアプリケーションであっても、オペレーティングシステムのコンポーネント、ライブラリ、開発ツール、外部サービスなど、他者が作成、構築、保守するソフトウェアに依存している。報告された欠陥は、影響を受けるバージョンが存在し、関連する操作が公開されている場合にのみ意味を持つ可能性があるが、異なるスケジュールで維持されている依存関係全体にわたってそれを特定することは困難な場合がある。したがって、製品名は、その動作に実際に関与するコンポーネントやサービスについてほとんど何も語っていない。[53]

有用な比較対象は成分表です。製品の成分を特定できない製造業者は、新たに発見された問題がその製品に関係するかどうかを容易に判断できません。ソフトウェアも同様の困難を抱えています。ソフトウェア部品表（SBOM）は、コンポーネントとバージョンを記録し、他の依存関係を通じて得られる依存関係を含め、可視性を向上させます。これは、報告された脆弱なライブラリが存在するかどうかを組織が判断するのに役立ちますが、安全性の証明書ではありません。インベントリは不完全である可能性があり、脆弱なコードにアクセスできない可能性があり、あるリリースには存在しないコンポーネントが次のリリースに登場する可能性があります。インベントリは、維持され、実際に展開されたものと関連付けられ、影響を受けるシステムの評価と修復のプロセスが続く場合に有用になります。[54]

アブ・イシュガイル氏らが作成した2026年のSoKは、AStRAモデルを用いて、ソフトウェアの製造と配布に関わる関係者、手順、リソース、成果物を検証しています。SBOMで回答できる質問と、ソースコードの変更、ビルドの整合性、リリース権限、納品に関する証拠を必要とする質問を区別しています。完全なインベントリがあっても、ビルドが信頼できるものであるとは限らず、出所情報があっても、結果として得られたプログラムに欠陥がないとは限らないのです。証拠は、評価対象となる特定のサプライチェーンリスクに合致していなければなりません。[55]

どのコンポーネントが存在するかを知っていても、その内容や配布が信頼できるとは限りません。攻撃者は、依存関係、ソースリポジトリ、ビルドプロセス、またはソフトウェアアップデートに悪意のある動作を仕込むことで、ユーザーが一見正当なリリースの一部として有害なコードを受け取るようにすることができます。これは、コンポーネントの偶発的な脆弱性の発見とは異なり、ソフトウェアサプライチェーンの侵害です。パッケージの出所と完全性を確認することで、不正な置換を検出するのに役立ちますが、サプライヤーまたはそのビルドプロセスが侵害されている場合、正しく署名されたリリースであっても悪意のあるものである可能性があります。したがって、ソフトウェア配信を保護するには、コードやリリースを変更できる人物、ビルド資格情報の処理方法、配信された成果物が意図されたソースとどのように結び付けられるかについての制御も必要です。SBOMは構成要素を特定しますが、その内容や配信経路が安全であることを保証するものではありません。[53]

ソフトウェアはプログラマのエディタからユーザーのデバイスに直接届くわけではありません。コードは、メンテナー、リポジトリ、ビルドツール、自動化サービス、署名キー、リリース承認者、配布チャネルを経由します。レビュー担当者がソースコードを調べても、パッケージング中に導入された悪意のある変更を見落とす可能性があります。厳密に管理されたビルドツールであっても、侵入者がビルドしたものを承認できる場合は、ほとんど保護になりません。これらの責任を分離して検証することは重要です。なぜなら、正当に見えるリリースでも、エンドユーザーには見えない段階で変更されている可能性があるからです。[56]

2024年のxz Utilsバックドアは、この問題を異例の明瞭さで露呈させた。悪意のあるファイルがリリースアーカイブに隠蔽され、特定のLinuxパッケージビルドに影響を与えるように配置されており、特定の依存関係を持つシステムでのリモートログイン認証を損なう可能性があった。配布されたリリースアーカイブは、レビュー担当者が公開リポジトリで検査するソースと単純に同等ではなかった。ビルドプロセスによって、最終的にソフトウェアに含まれるものが決定された。この攻撃は、影響を受けるバージョンが安定したLinuxディストリビューションで一般的になる前に検出されたが、一見承認されたアップストリームリリースが、意図的に導入された悪意のある機能をダウンストリームパッケージに運ぶ可能性があることを示した。そのため、馴染みのあるプロジェクトやその公式ダウンロードパスを信頼するだけでは十分ではない。これはサプライチェーンの侵害であり、偶発的なプログラミングの欠陥ではなかった。[57] [58]

ビルド履歴は、提供された実行可能ファイルを、それを生成したソース、ツール、設定、およびサービスにリンクしようとします。再現可能なビルドは、独立した関係者が同じソースから一致する結果を生成した場合に、追加の証拠を提供できます。SLSA などのフレームワークは、この履歴を記録して検証する方法を説明しています。しかし、記録の信頼性は、それを生成するシステムと、誰かがそれをチェックする独立した期待値に依存します。侵害されたソースは再現可能にビルドできます。破損したビルドサービスは、誤った保証を生成する可能性があります。誰も検証しない署名付きステートメントはほとんど役に立ちません。履歴は、管理チェーンの一部を確立することはできますが、基盤となるソフトウェアが安全に動作するかどうかは確立できません。[59] [60]

リリース署名と配布は、別の境界を形成します。有効なデジタル署名は、成果物が特定の鍵を使用して署名され、その後変更されていないことを示すことができます。署名者が信頼できる人物であること、鍵が盗まれていないこと、署名されたプログラムが安全であることを証明するものではありません。署名されたリリースは、鍵による認証の証拠であり、無害性の証明書ではありません。HTTPSはダウンロードWebサイトへの接続を保護しますが、Webサイト、その発行者アカウント、またはダウンロード自体が侵害されていないことを保証するものではありません。侵害された同じページに表示されるチェックサムは、独立した保証をほとんど提供しません。そのため、安全な更新システムでは、想定される発行者、信頼できるメタデータ、バージョン、および許可された署名機関も検証し、古い脆弱なリリースへのロールバックに対する保護も行います。これらのチェックは、リリースプロセスを信頼して保護する必要性を排除することなく、特定の攻撃を軽減します。[61]

ハードウェアサプライチェーンでは、検査がより困難な関連問題が発生します。チップは、綿密にレビューされた設計から始まり、他のサプライヤーからの回路や設計コンポーネントを組み込み、製造、テスト、パッケージング、輸送、統合を経て製造されます。理論上の設計は健全かもしれませんが、顧客に出荷されるシリコンがそれに忠実であるとは限りません。関連する段階にアクセスできる攻撃者は、原則として、製造または配送中に回路を変更したり、隠れたハードウェアトロイの木馬を挿入したり、コンポーネントを交換したり、関連するファームウェアを変更したりすることができます。これらは評価すべき既知の脅威であり、特定のメーカーやデバイスが侵害された証拠ではありません。[62] [63]

検証済みの設計図は、検証済みのチップではありません。正常な動作の確認、サンプルのテスト、製造記録の調査、信頼できるサプライヤーの使用、保管記録の維持、コンポーネントの認証はすべて、ハードウェアの保証を強化することができます。しかし、まれな、または意図的に隠された回路の動作は、通常のテストをすり抜ける可能性があり、デバイス自身のIDまたは認証メカニズムは、その出所も信頼できる必要があるハードウェアとキーに依存します。セキュアブートは、その検証の製造された開始点が信頼できる範囲でのみ、後続のソフトウェアを検証できます。単一の証明書または検査では、チェーン全体にわたる悪意のある変更がないことを証明することはできません。[62] [63]

保守と脆弱性修正の競争

アップデートは、既に十分に理解され修正可能な欠陥を解消することが多いため、特に注意を払う必要があります。欠陥の詳細が公開されると、攻撃者は影響を受けるバージョンを実行しているシステムを探す可能性があります。一部の脆弱性は、修正プログラムが利用可能になる前に既に悪用されています。したがって、アップデートを遅らせると、攻撃者が独自の調査を必要としない手法に対してシステムが脆弱なままになる可能性があります。必要な作業は、アップデートボタンをクリックするだけにとどまりません。組織は、所有するコンピュータとサービス、それらが実行しているバージョン、ベンダーの修正プログラムが存在するかどうか、影響を受ける機能が公開されているかどうか、変更が正常に展開されているかどうかを把握する必要があります。ベンダーのサポートが終了したデバイスとサービスは、セキュリティ修正プログラムがまったく提供されなくなる可能性があるため、別の問題となります。[64]

アップデートの責任範囲は、目に見えるアプリケーションだけでなく、オペレーティングシステム、ブラウザ、ルーター、プラグイン、サーバーソフトウェア、ファームウェアにも及びます。消費者向けデバイスは自動的にアップデートされる場合もありますが、組織は使用頻度の低いマシン、継承されたサービス、バージョンが分かりにくいサードパーティ製システムなども運用しています。これらは正常に動作しているように見えるため、見落としやすいものです。正確なインベントリ、所有者の明示、そしてアップデートが実行中のシステムに到達した証拠があれば、パッチ適用プロセスは単なる修正プログラムのリストとは区別されます。

脆弱性を報告することと、それを修復することは同じではありません。対応の重要な部分はセキュリティトリアージです。影響を受けるソフトウェアが存在するか、脆弱な部分にアクセスできるか、攻撃者がそれを使って何ができるか、そして既に誰かがそれを悪用しているかどうかを調べます。これにより、問題の緊急度、誰が行動する必要があるか、そしてまだ確認する必要のある証拠が明らかになります。深刻度スコアは役立ちますが、それだけで特定の製品に対する危険性を判断することはできません。新しい事実やソフトウェアの変更が明らかになった場合は、トリアージの決定を見直す必要があります。悪用が進行中の場合は、評価が完了する前に保護措置を開始する必要があるかもしれません。[65]

修正プログラムがまだ存在しない場合もあります。たとえ迅速にリリースされたとしても、製品との互換性を確認し、重要な機能が損なわれないようにテストし、実際にユーザーが使用するバージョンに配信して検証する必要があります。この期間中、既知の脆弱性が悪用される可能性があります。アクセスを制限したり、影響を受ける機能を無効にしたり、サービスを隔離したり、必要に応じてオフラインにしたりする必要があるかもしれません。これらの暫定的な措置は、欠陥が修正されるまで監視およびレビューする必要があります。パッチをインストールしても、既に発生した攻撃を元に戻すことはできません。[65]

攻撃者は、修正プログラムが必要な人々に届くよりも速く攻撃を仕掛けてくる可能性があります。実際に悪用されている脆弱性の調査で、Mandiant は、2018～2019 年の平均悪用時間として 63 日、2021～2022 年は 32 日、2023 年は 5 日を報告しました。2026 年の報告では、2025 年はマイナス 7 日と推定されており、これは調査対象となったケースでは、平均して最初の悪用がパッチの提供開始よりも前に確認されたことを意味します。これらは、選択された悪用された脆弱性の測定値であり、すべての欠陥のタイムラインや顧客がアップデートをインストールする速さの測定値ではありません。ゼロデイ攻撃は平均値に影響を与えます。また、この加速は、今日の生成型 AI システムよりも前から始まっていました。[66] [67] [68]

AI 支援分析は、この既に困難な競争にさらにプレッシャーを加える。公開されたパッチやソースコードの変更により、脆弱なバージョンと代替バージョンの違いが明らかになる可能性がある。自動化ツールは、バージョンを比較し、候補となるテストを開発し、露出したシステムを特定するのに役立ち、既知の弱点を追求するために必要な作業を減らすことができる。2024 年の研究では、LLM ベースのエージェントが、説明を与えられた場合、制御された条件下で以前に開示されたいくつかの脆弱性を悪用できることが実証された。2026 年 9 月、Google 脅威インテリジェンスは、以前に開示された高リスクの脆弱性の悪用が増加していることを報告し、AI 支援分析が原因の可能性があると指摘したが、これは AI がすべてのインシデントを引き起こした証拠ではない。[69] [70]

この機能は、オペレーターがリクエストを監視または制限できるモデル サービスに限定されません。強力な言語モデルの中には、ダウンロード可能な重みとともにリリースされ、作成者の制御外で実行または変更できるものがあり、その保護措置は存在しない、変更されている、または削除されている可能性があります。2026 年の公開評価では、サイバー セキュリティ タスクにおいて、ますます高性能なオープン ウェイト モデルが見つかりました。これは、すべてのモデルが効果的な攻撃者になるわけではなく、既知のすべての脆弱性が簡単に悪用できるわけでもありません。AI は、防御者がコードをレビューし、欠陥を発見し、対応を準備するのにも役立ちます。変化するのは、モデル プロバイダーの制限を遵守する必要のないアクターによるものも含め、弱点を探すコストと潜在的な速度です。[71] [72]

修正プログラムを公開したからといって、ユーザーがそれを受け取ったとは限りません。下流の保守担当者、販売業者、運用担当者は、変更の統合、テスト、承認、展開を行う必要がある場合があります。攻撃者は、残されたインストール環境を探し出す可能性があり、また、拙速な展開は新たな障害を引き起こす可能性があります。したがって、迅速なトリアージ、一時的な保護、検証済みの展開は、互いに補完し合う責任であり、競合する代替手段ではありません。

セキュアな設計が重要なのは、脆弱性の発見から修正の適用までの危険な期間を、常になくせるとは限らないからです。メモリセーフなコードは、ある種のメモリエラーを防ぐことができます。厳格なアクセス権限と独立したサンドボックスは、侵害されたコンポーネントがアクセスできる範囲を制限できます。入力とリソースの制限は、他の攻撃を困難にすることができます。このような保護は、脆弱性が発見される前だけでなく、修正プログラムの準備とテスト中にも役立ちます。ある程度の障害に耐え、被害を最小限に抑え、復旧できる能力は、セキュリティの回復力の一部です。このような状況を想定して設計されたシステムは、障害下でも機能を維持・回復できる（survivable）と表現されます。これは、脆弱なソフトウェアが安全であることの証明ではなく、欠陥の修正と検証の作業に取って代わるものでもありません。[38]

アウトソーシングによってこれらの責任がなくなるわけではありません。サプライヤーはアプリケーションの構築、クラウドサービスの運用、職場デバイスの管理、ウェブサイトの保守などを行うかもしれませんが、作業を委託する組織は、どの程度のリスクを受け入れるかを決定する責任を負います。サプライヤーの中には非常に有能で規律正しいところもありますが、多くの顧客に限られた注意を分散させたり、最初の納品以降の保守の証拠をほとんど示さないところもあります。関連する弱点は、外部の請負業者が存在することだけではありません。システムの依存関係を明確に特定したり、アクセスを承認したり、欠陥を発見したり、変更を適用したり、リリースを検証したり、問題が発生したときに対応したりすることが誰にもできないような体制になっていることが問題なのです。契約書、サービスの説明、バッジは期待値を割り当てるのに役立ちますが、安心させる言葉よりも、目に見える保守と責任ある所有者の存在の方が重要です。[2]

オープンソースソフトウェアは、開発チーム以外の人々もコードを検査し、検証できるため、貴重な検証手段となります。しかし、多くの人がコードを検証できるというよくある議論は、十分な資格を持った人が実際にそうしていることや、報告された欠陥が迅速に解決されることを保証するものではありません。オープンソースプロジェクトは、資金が豊富な組織から、広く利用されているコンポーネントを保守する小規模チームまで多岐にわたります。プロプライエタリソフトウェアも、レビューと保守の方法が大きく異なります。PHPの2026年10月のセキュリティリリースは、この違いをよく示しています。PHP Foundationは、2つの重大な脆弱性を修正した後、技術的なトレードオフの難しさ、経験豊富な保守担当者の不足、意思決定プロセスによって、根本的な問題の1つへの対応が遅れた経緯を説明しました。また、修正を完了する上で、資金提供を受けたエンジニアや外部の研究者が果たした役割も認めました。これらの欠陥は、リソース枯渇後のメモリ破損とリクエスト間での内部状態の劣化に関わるもので、先に述べたメモリとエラー処理メカニズムと、広く利用されているランタイムを修復するために必要な専門的な保守作業が結びついています。重要なのは、オープンソースが本質的に脆弱であるとか、クローズド製品の方が安全であるということではないのです。ソースコードが利用可能になることで精査の機会が生まれ、継続的な専門知識、明確な責任、効果的なメンテナンスによって発見が保護へと変わる。[73]

ソフトウェアは、実際に使用される環境下でテストされる必要があります。主要機能のデモンストレーションが成功したとしても、誤ったアカウントがレコードを要求した場合、2つの操作が競合した場合、ファイルが不正な形式の場合、または特権ヘルパーが予期しないコマンドを受け取った場合に何が起こるかについてはほとんど何もわかりません。セキュリティ検証は、実際に展開されたバージョンと構成で定義された要件が満たされているかどうかを確認します。コードと依存関係のレビューを、禁止されている操作と正当な操作のテスト、および障害からの復旧と組み合わせることができます。テストは脆弱性が存在しないことを証明するものではなく、開発者のコ​​ンピュータからのテスト結果がリリースされた製品の制限を確立するとは限りません。逆に、公開監査がないことは、サービスが安全でないという証明にはなりません。信頼できる証拠は、何が調査されたか、どのバージョンと構成が使用されたか、何が発見されたか、そして何が不明であるかを具体的に示すものです。[2]

セキュリティ警告の判断方法

ニュース報道では、しばしば複数の異なる状態を同じ不安を煽るような言葉で表現します。弱点とは、特定の状況下で損害を与える可能性のある欠陥または安全でない状態のことです。脆弱性とは、セキュリティ特性を損なうために使用できる弱点であり、エクスプロイトとは、それを使用する方法です。欠陥によってリモートコード実行が可能になるという主張は、特定の条件下で攻撃者がソフトウェアにコードを実行させることができる可能性があることを意味します。それ自体では、特定の組織が攻撃されたことや、その組織のすべてのデータが盗まれたことを証明するものではありません。侵害が確認されたということは、不正アクセスやその他の侵害行為が発生した証拠ですが、その全容は調査中である可能性があります。深刻度ラベル、エクスプロイトのデモンストレーション、およびインシデントの調査結果は、それぞれ異なる質問に答えるものであり、同義語として扱うべきではありません。

公開されている脆弱性識別子（多くの場合、CVE 番号として表記される）は、異なる組織が同じ報告された欠陥について議論するのに役立ちます。これは、影響を受けるすべてのインストールの記録ではなく、悪用が成功したことの証明でもありません。深刻度スコアは、明示されたスコアリング モデルを使用して欠陥の特性を推定します。運用上の緊急性は、環境と攻撃者が到達できる範囲に依存します。ゼロデイという用語は、効果的な修正が利用可能になる前、または防御側がそれを知る前に悪用される欠陥に対してよく使用されますが、報告の慣習は異なります。その重要性は、防御側が事前に弱点を修正する機会が限られていることにあり、その名前の神秘性にあるのではありません。パッチが公開されている何年も前の脆弱性でも、更新されていない露出したマシンに対して悪用されている場合は、緊急の事態となる可能性があります。[74] [75]

実際の深刻度を判断する最初の要素は到達可能性です。ロックされたマシンを物理的に制御できる攻撃者は、公開サービスにリクエストを送信できる攻撃者とは異なる状況に直面します。めったに使用されないオプション機能の欠陥は、インターネットに接続されたサービスの同じ欠陥とは異なりますが、どちらも修復が必要になる可能性があります。2番目の要素は権限です。影響を受けるコードが公開情報を読み取ることができるか、プライベートレコードにアクセスできるか、アカウントを変更できるか、コマンドを実行できるか、委任されたサービスを通じて管理者に影響を与えることができるかによって、結果が異なります。3番目の要素は露出と証拠です。影響を受けるバージョンが実際に存在し、脆弱な経路が関連する条件下で使用可能でなければならず、実際に悪用されているという報告は、理論上の可能性だけよりも、より直接的な意味を持ちます。[1]

修復は4番目の要素です。ベンダーが既に修正プログラムを発行している場合、サービスがそれを展開している場合、または組織がどのシステムが影響を受けているかをまだ調査している場合があります。パッチは、潜在的に侵害されたすべてのシステムが検査されたことを証明することなく、目先の欠陥を取り除くことができます。修正プログラムの前に悪用が発生した可能性がある場合は、調査、認証情報の変更、および信頼できる状態の復元も必要になる場合があります。信頼できる声明は、発見された脆弱性、阻止された攻撃の試み、確認された不正アクセス、および実際に確立された損害を区別します。インシデント中は不確実性があるのが普通です。裏付けのない確実性は証拠の代わりにはなりません。[65]

これらの区別により、サプライヤーや請負業者によるセキュリティに関する主張の評価も容易になります。コンポーネントの在庫管理、明確なパッチの所有権、意味のあるリリース テスト、制御された特権アクセス、および実行可能なインシデント対応プロセスの証拠は、完全なセキュリティを約束するよりもはるかに有益です。この作業が大規模なテクノロジー企業、小規模な開発チーム、または外部機関によって行われる場合でも、同じ疑問が生じます。組織の規模は、能力の証明でも怠慢の証拠でもありません。重要なのは、問題を特定し、それがどこに影響を与えるかを説明し、問題を修正し、人々が実際に依存しているシステムに修正が適用されていることを確認できる能力です。[2]

結論

ソフトウェアのセキュリティは、技術的には有効な操作であっても、誤った条件下で実行される可能性があるため、困難です。システムがなりすまし犯からのパスワードを受け入れたり、特権サービスが不正な呼び出し元のために動作したり、チェックが古くなったり、悪意のあるデータがコードとして解釈されたり、メモリの欠陥によって他の場所で適用されているルールが回避されたりする可能性があります。依存関係、ビルドプロセス、ファームウェア、メンテナンスは、セキュリティ対策が欠落したり無効になったりする可能性のある機会をさらに増やします。それぞれの障害には異なる原因があるため、信頼性を確保するには、攻撃者の影響から結果的な行動に至るまでの経路を理解する必要があります。

最も有用なセキュリティに関する主張は具体的であるべきです。それらは、保護すべき対象、想定される攻撃者の能力、影響を受けるコンポーネントの動作、独立して機能する保護策、そしてリリースされた構成のテストから得られた証拠を明確に示します。また、依存関係の監視方法、報告された脆弱性のトリアージ方法、アップデート準備中のリスク制限方法、そして展開の検証方法についても説明します。開発者と運用担当者は、これらの保護策を提供する責任を負います。ソフトウェアに依存するユーザーは、ラベル、証明書、または成功したデモンストレーションを証拠として受け入れるのではなく、信頼できる回答を求めるためにセキュリティ研究者になる必要はありません。

知っておくべきこと：

参考文献

番号付きの出典は本文中で引用されています。n.d.は出版日が明記されていないことを示します。

1. National Institute of Standards and Technology (2012). Guide for Conducting Risk Assessments. NIST Special Publication 800-30 Rev. 1. DOI: 10.6028/NIST.SP.800-30r1.
2. National Institute of Standards and Technology (2022). Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities. NIST Special Publication 800-218. DOI: 10.6028/NIST.SP.800-218.
3. OWASP Foundation (n.d.). Authentication Cheat Sheet. OWASP Cheat Sheet Series.
4. Cybersecurity and Infrastructure Security Agency and Federal Bureau of Investigation (2025). Product Security Bad Practices: Updated Guidance. CISA/FBI advisory, 17 January 2025.
5. OWASP Foundation (n.d.). Session Management Cheat Sheet. OWASP Cheat Sheet Series.
6. Zhuo, S., Biddle, R., Koh, Y. S., Lottridge, D. and Russello, G. (2023). SoK: Human-centered Phishing Susceptibility. ACM Transactions on Privacy and Security, 26(3), Article 24. DOI: 10.1145/3575797.
7. OWASP Foundation (n.d.). Authorization Cheat Sheet. OWASP Cheat Sheet Series.
8. Hardy, N. (1988). The Confused Deputy (or Why Capabilities Might Have Been Invented). ACM SIGOPS Operating Systems Review, 22(4), pp. 36–38. DOI: 10.1145/54289.871709.
9. OWASP Foundation (n.d.). Authorization Patterns Cheat Sheet. OWASP Cheat Sheet Series.
10. The Chromium Project (n.d.). Sandbox Design. Chromium design documentation.
11. National Institute of Standards and Technology (n.d.). Insider Threat. NIST CSRC Glossary.
12. OWASP Foundation (n.d.). Business Logic Security Cheat Sheet. OWASP Cheat Sheet Series.
13. MITRE (n.d.). CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition. Common Weakness Enumeration.
14. OWASP Foundation (n.d.). Input Validation Cheat Sheet. OWASP Cheat Sheet Series.
15. OWASP Foundation (n.d.). SQL Injection Prevention Cheat Sheet. OWASP Cheat Sheet Series.
16. OWASP Foundation (n.d.). Cross Site Scripting Prevention Cheat Sheet. OWASP Cheat Sheet Series.
17. The Rust Project (n.d.). The Rust Programming Language: References and Borrowing; Unsafe Rust. Rust language documentation.
18. The Swift Project (n.d.). Memory Safety. The Swift Programming Language, Swift.org.
19. Python Software Foundation (n.d.). Extending and Embedding the Python Interpreter. Python 3 documentation.
20. Szekeres, L., Payer, M., Wei, T. and Song, D. (2013). SoK: Eternal War in Memory. IEEE Symposium on Security and Privacy, pp. 48–62. DOI: 10.1109/SP.2013.13.
21. Anderson, R. (1993). Why Cryptosystems Fail. Proceedings of the 1st ACM Conference on Computer and Communications Security, pp. 215–227. DOI: 10.1145/168588.168615.
22. Internet Engineering Task Force (2023). Service Identity in TLS. RFC 9525.
23. Internet Engineering Task Force (2020). JSON Web Token Best Current Practices. RFC 8725.
24. Rescorla, E. (2018). The Transport Layer Security (TLS) Protocol Version 1.3. IETF RFC 8446. DOI: 10.17487/RFC8446.
25. Clark, J. and van Oorschot, P. C. (2013). SoK: SSL and HTTPS: Revisiting Past Challenges and Evaluating Certificate Trust Model Enhancements. IEEE Symposium on Security and Privacy. DOI: 10.1109/SP.2013.41.
26. National Institute of Standards and Technology (n.d.). Side Channel. NIST CSRC Glossary.
27. Anderson, R. and Needham, R. (1995). Programming Satan's Computer. In Computer Science Today, pp. 426–440. DOI: 10.1007/BFB0015258.
28. Kim, Y., et al. (2014). Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors. Proceedings of the 41st International Symposium on Computer Architecture, pp. 361–372. DOI: 10.1109/ISCA.2014.6853210.
29. Seaborn, M. and Dullien, T. (2015). Exploiting the DRAM Rowhammer Bug to Gain Kernel Privileges. Google Project Zero research, March 2015.
30. Kocher, P., et al. (2018). Spectre Attacks: Exploiting Speculative Execution. arXiv:1801.01203, security research preprint.
31. Lipp, M., et al. (2018). Meltdown: Reading Kernel Memory from User Space. 27th USENIX Security Symposium.
32. Intel (n.d.). Analysis of Speculative Execution Side Channels. Intel Software Security Guidance.
33. NVIDIA (2018). Security Notice: NVIDIA Tegra RCM Vulnerability. NVIDIA Product Security Notice, 24 April 2018.
34. Temkin, K. and ReSwitched (2018). Fusée Gelée: Boot ROM Vulnerability Disclosure. Research disclosure.
35. National Institute of Standards and Technology (2018). Platform Firmware Resiliency Guidelines. NIST Special Publication 800-193. DOI: 10.6028/NIST.SP.800-193.
36. Glosner, C. and Machiry, A. (2026). SoK: All You Ever Wanted to Know About Bootloader Security but Were Afraid to Ask. IEEE Symposium on Security and Privacy. DOI: 10.1109/SP63933.2026.00163.
37. Lefeuvre, H., Dautenhahn, N., Chisnall, D. and Olivier, P. (2025). SoK: Software Compartmentalization. IEEE Symposium on Security and Privacy. DOI: 10.1109/SP61157.2025.00075.
38. Ross, R., Pillitteri, V., Graubart, R., Bodeau, D. and McQuaid, R. (2021). Developing Cyber-Resilient Systems: A Systems Security Engineering Approach. NIST Special Publication 800-160, Vol. 2 Rev. 1. DOI: 10.6028/NIST.SP.800-160v2r1.
39. Apple (n.d.). Operating System Integrity. Apple Platform Security.
40. Apple Security Research (2025). Memory Integrity Enforcement: A Complete Vision for Memory Safety in Apple Devices. Apple Security Research technical blog.
41. Apple (n.d.). Secure Enclave. Apple Platform Security.
42. Apple Developer (n.d.). Protecting Keys with the Secure Enclave. Apple Developer Documentation, Security.
43. Microsoft (n.d.). Trusted Platform Module (TPM) fundamentals. Microsoft Learn.
44. Arm (n.d.). TrustZone for Cortex-A. Arm Technologies.
45. Intel (n.d.). Intel Software Guard Extensions SDK for Linux OS. Intel Developer Documentation.
46. Zinkus, M., Jois, T. M. and Green, M. (2022). SoK: Cryptographic Confidentiality of Data on Mobile Devices. Proceedings on Privacy Enhancing Technologies, 2022(1), pp. 586–607. DOI: 10.2478/popets-2022-0029.
47. Apple Developer (n.d.). Enabling Enhanced Security for Your App. Apple Developer Documentation, Xcode.
48. Apple Developer (n.d.). Preparing Your App to Work with Pointer Authentication. Apple Developer Documentation, Security.
49. LLVM Project (n.d.). Pointer Authentication. Clang Compiler Documentation.
50. OWASP Foundation (2025). A10: Mishandling of Exceptional Conditions. OWASP Top 10: 2025.
51. MITRE (n.d.). Privilege Escalation (TA0004). MITRE ATT&CK knowledge base.
52. MITRE (n.d.). Lateral Movement (TA0008). MITRE ATT&CK knowledge base.
53. OWASP Foundation (2025). A03: Software Supply Chain Failures. OWASP Top 10: 2025.
54. Cybersecurity and Infrastructure Security Agency and international partners (2026). 2026 Minimum Elements for a Software Bill of Materials (SBOM). Joint government guidance.
55. Abu Ishgair, E., Gomez, J., Melara, M. S., Cárdenas, A. A. and Torres-Arias, S. (2026). SoK: A Defense-Oriented Evaluation of Software Supply Chain Security. IEEE European Symposium on Security and Privacy, pp. 836–859. DOI: 10.1109/EuroSP68448.2026.00059.
56. Boyens, J., et al. (2024). Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations. NIST SP 800-161 Rev. 1, Update 1.
57. Arasaratnam, O., et al. (2024). xz Backdoor CVE-2024-3094. Open Source Security Foundation, 30 March 2024.
58. Cox, R. (2024). Timeline of the xz Open Source Attack. Research note, 2024.
59. Supply-chain Levels for Software Artifacts (n.d.). Provenance. SLSA Specification, version 1.2.
60. Supply-chain Levels for Software Artifacts (n.d.). Build: Verifying Artifacts. SLSA Specification, version 1.2.
61. The Update Framework (2024). Overview. TUF Documentation, last updated October 2024.
62. Rekhi, S., Amberiadis, K., Akib, A. A., and Srivastava, A. (2025). Analyzing Collusion Threats in the Semiconductor Supply Chain. NIST Cybersecurity White Paper 46. DOI: 10.6028/NIST.CSWP.46.
63. National Institute of Standards and Technology (n.d.). Supply Chain. NIST Mobile Threat Catalogue.
64. Cybersecurity and Infrastructure Security Agency (n.d.). Known Exploited Vulnerabilities Catalog. CISA vulnerability catalogue.
65. UK National Cyber Security Centre (n.d.). Vulnerability Management: Carry Out Assessments. NCSC vulnerability management guidance.
66. Charrier, C., and Semrau, J. (2023). Analysis of Time-to-Exploit Trends: 2021–2022. Mandiant / Google Threat Intelligence, 28 September 2023.
67. Charrier, C., and Weiner, R. (2024). How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends. Mandiant / Google Threat Intelligence, 15 October 2024.
68. Mandiant (2026). M-Trends 2026: Data, Insights, and Strategies From the Frontlines. Google Threat Intelligence.
69. Fang, R., Bindu, R., Gupta, A., and Kang, D. (2024). LLM Agents Can Autonomously Exploit One-Day Vulnerabilities. arXiv preprint 2404.08144.
70. Grunewald, R., Mazumdar, S., and Vanderlee, K. (2026). Vulnerability Discovery and Exploitation Trends in the AI Era. Google Threat Intelligence Group, 1 October 2026.
71. UK AI Security Institute (2026). How Far Behind the Frontier Are Leading Open-Weight Models on Cyber? AISI Work.
72. International AI Safety Report (2026). International AI Safety Report 2026. Section 3.4, Open-weight models.
73. The PHP Foundation (2026). Today's PHP Security Release, and How We're Strengthening PHP Security. The PHP Foundation Blog, 21 October 2026.
74. CVE Program (n.d.). Common Vulnerabilities and Exposures: CVE Program Mission and Records. CVE Program.
75. FIRST (n.d.). Common Vulnerability Scoring System (CVSS) v4.0: User Guide. FIRST.org, document version 1.2.