米政府機関によるソフトウェアサプライチェーンのセキュア化ガイダンス
2020年12月に公になったSolarWinds事件をきっかけに、ソフトウェアのサプライチェーンのリスクに対する関心が高まっています。しかし、ソフトウェアの脆弱性を悪用するのではなく、ソフトウェアの開発元や配布元を侵害し、ソフトウェアそのものに悪意のあるコードを仕込むという、いわゆる「サプライチェーン攻撃（の一種）」自体は、SolarWinds事件が世界初というわけではありません。例えば、2009年には韓国で、広く使われているソフトウェアのアップデートプログラムを何者かが改ざんし、当該ソフトウェアの自動更新機能を介してユーザーのPCにボットを感染させ、大規模なDDoS攻撃を起こした事件「7・7大乱（テラン）」がありました。韓国ではこの事件以降も自動更新機能を悪用した攻撃の被害が数年にわたって続いたことを踏まえ、2014年に政府が「更新システムのセキュリティガイドライン」を公開しています。このような韓国での事例が既にある一方で、2020年のSolarWinds事件が世界中で大きく注目されたのは、被害組織の数が多く、その中に米連邦政府機関や大手企業が含まれるなど、影響が広く世界中に及んだためでしょう。
SolarWinds事件を踏まえ、米政府は既にさまざまな動きを見せていますが、その一環としてソフトウェアサプライチェーンをセキュア化するためのガイダンスを作成しており、その全3部で構成されるガイダンスの第1部が「Securing the Software Supply Chain – Recommended Practices Guide for Developers」として公開されました。これはソフトウェアの開発者向けのガイダンスで、よりセキュアなソフトウェアサプライチェーンを確保するための推奨事例を紹介しています。なお、第2部はソフトウェアのサプライヤー向け、第3部はソフトウェアのカスタマー向けになるとのことです。また、このガイダンスは米国土安全保障省（NSA）と同サイバーセキュリティ・インフラセキュリティ庁（CISA：Cybersecurity & Infrastructure Security Agency）が主導する官民合同のワーキンググループ「Enduring Security Framework（ESF）」によって作成され、NSAとCISAに加え、米国家情報長官室（ODNI：Office of the Director of National Intelligence）との連名で公開されています。
今回公開されたガイダンスはあくまで開発者向けの「助言」であり、少なくとも現時点では何らかの法的な規制ではないことに注意してください。
今回の開発者向けのガイダンスは全3章で60数ページ。1章は「Introduction」、3章は「Appendices」、本文となる2章は全34ページで、以下のような構成となっています。
2. 開発者
2.1 セキュアな製品の基準と管理
2.2 セキュアなコードの開発
2.2.1 内部の人間によるソースコードの改ざんまたは悪用
2.2.2 オープンソースの管理手法
2.2.3 セキュアな開発手法
2.2.4 コードの統合
2.2.5 不具合/脆弱性、顧客から報告された問題
2.2.6 外部で開発された拡張機能
2.3 サードパーティ製コンポーネントの検証
2.3.1 サードパーティ製バイナリ
2.3.2 選択と統合
2.3.3 既知の信頼できるサプライヤーからのコンポーネントの入手
2.3.4 コンポーネントの保守
2.3.5 ソフトウェア部品表（SBOM:Software Bill of Materials）
2.4 ビルド環境の堅牢化
2.4.1 ビルドチェーンの悪用
2.4.2 署名サーバーの悪用
2.5 コードの配布
2.5.1 最終パッケージの検証
2.5.2 ソフトウェアパッケージとアップデートを侵害する可能性のある手口
2.5.3 流通システムの侵害
基本的に各項目は想定される脅威や検討すべき課題となっており、それぞれについて「推奨される緩和策（Recommended Mitigations）」が紹介されています。今回はこの中からいくつかを抜粋して簡単に紹介します。なお、原文ではより詳細な説明がなされていますので、分かりづらい点があれば原文を参照してください。
「2.2.1 内部の人間によるソースコードの改ざんまたは悪用」
内部の人間による意図的または非意図的な行為について想定されるシナリオとして例えば以下の5つが挙げられる。
- エンジニアが外部からの影響や不満によって侵害されている（≒セキュリティ上問題のある状態になっている）場合
- エンジニアの訓練が不十分な場合
- エンジニアが製品にバックドアを仕込んだ場合
- リモート開発システムのセキュリティが確保されていない場合、または保護が解除された場合
- 退職者、または休職中の従業員のアカウントや認証情報が有効なまま残っている場合
これらの問題に対して推奨される緩和策としては以下の7つが挙げられる。
- バランスのとれた認証済みソースコードのチェックイン・プロセスを実装する
- 自動的な静的および動的セキュリティ/脆弱性スキャンを実施する
- ナイトリービルドを実施する際にはセキュリティテストおよび回帰テストを含める
- 機能を要件にマッピングする
- コードレビューの優先順位を決めて重要（critical）なコードをレビューする
- セキュアなソフトウェア開発/プログラミングのトレーニング
- 開発環境の堅牢化
「2.3.3 既知の信頼できるサプライヤーからのコンポーネントの入手」
信頼でききるサプライヤーとは以下のようなものである。
- そのサードパーティ製コンポーネントは採用を検討している製品の全ての要件を満たしている。
- 採用する側の組織によるテストの結果に基づいて、そのサードパーティ製コンポーネントの品質が検証されている。
- 例えばSBOMの検証など、提供されたアーティファクトの品質に誤りがないことが検証されている。
- そのサードパーティ製コンポーネントで報告された既知の脆弱性に対して、そのコンポーネントの所有者がタイムリーに対応した前歴（実績）がある。
- 脆弱性を報告するための当該サードパーティの仕組みが使いやすい。採用されたコンポーネントの全ての利用可能なアップデートは、そのサードパーティと開発グループの間で明確に定義されて理解されているアップデート手順を使用して、開発環境に容易に統合することができる。
「2.4.1 ビルドチェーンの悪用」
ビルド環境はサプライチェーンの侵害における主要な標的である。このシナリオでは、脅威者が次のような場合に侵害が発生する可能性がある。
- 開発ネットワークに潜入する。
- スキャンを実行して、リポジトリとビルドシステムの場所を突き止めて脆弱性を特定する。
- ビルドシステムまたはリポジトリ（あるいはその両方）を侵害するための攻撃ツール（exploit）を作り上げる。
- その攻撃ツールをデプロイ（配置）する。
この場合、その攻撃ツールは以下のものに含まれることになる。
- コンパイルされたソースコード
- 含まれるライブラリ
- ライブラリが脆弱性のある古いサードパーティ製ライブラリに戻ると再導入される
- 常駐メモリ（ルートキットを介してコンパイル時にソースに埋め込まれ、ソースはリポジトリ上では変更されない）
- ネットワーク中間者（MITM）攻撃（ビルドシステムにプルダウンされる際にソースが変更される）
[推奨される緩和策]
ビルドパイプラインのインフラストラクチャには、ソースコードリポジトリ、エンジニアリングワークステーション、ビルドシステム、署名サーバー、オンプレミスおよびクラウドでホストされているマシンの両方に対するデプロイメントサーバーなど、開発やビルドのプロセスに関わる全てのシステムが含まれる。これらのシステムは、それぞれ以下のようにする必要がある。
- 完全にロックダウンされる（各システムの役割に固有のオペレーションのみが実行可能な状態にできる）こと
- 外部およびローカルエリアネットワーク（LAN）外の活動から保護されること
- データ漏えいを監視すること（特にコードリポジトリとエンジニアリングワークステーション）
- 潜入と窃取を防止するように設定されていること
さらに
- ビルドスクリプトと設定ファイルを、2.2.1節「内部の人間によるソースコードの改ざんまたは悪用」に記載されているのと同じコードレビュープロセスの対象とすること。
- パイプラインの設定にバージョン管理を使用する。
- 各システムで多要素認証を確実に必須にする。
- エンジニアリングネットワークを企業ネットワークから分離する。
- サービスアカウントを最小限にして定期的に監査する。
- ビルドパイプラインへのアクセスは全てログに記録する。
- ビルドパイプラインに関連するいかなる機密情報も保護する。
繰り返しになりますが、今回のガイダンスは法的な義務ではなく、あくまで「助言」に過ぎないことに注意が必要です。実際、紹介されている推奨事項の全てを実践するのは少なくとも現時点では容易ではないでしょう。それでも、開発者はこれらの推奨事項のうちのいくつかが今後セキュリティ要件として求められるようになる可能性があることは知っておく必要があります。今回はガイダンスのごく一部のみの紹介にとどまっていますが、開発者には全文に目を通しておくことをお勧めします。また、開発者でなくても、ソフトウェアを採用する側にとっては開発者側に求めるセキュリティ要件を検討する際の参考資料にはなるはずです。うまく活用してください。