前回、EO 14028の第4条を受けて作られたSecure Software Development Framework（SSDF）のnoteを書きました。
今回は、SSDFを適用するための手引きとなるガイダンス「Securing the Software Supply Chain」を読みます。
何の本？
NISTからSSDFが出た後に、OMBが米政府機関に対し、ソフトウェア製品を提供するベンダーにこのフレームを採用させる旨の指示を出しました。
そうは言ってもSSDFって抽象度の高い要件が多いのにどうすりゃいいのってところを具体化するために作られたのが本ガイダンスのようです。
NSAとCISAが主導する官民合同のワーキンググループ「Enduring Security Framework （ESF）」が作成し、NSAとCISA、米国家情報長官室（ODNI：Office of the Director of National Intelligence）の連名で公開されています。
本ガイダンスは3部作で、今回読むのは第1部です。
- 第1部：ソフトウェア開発者向け
- 第2部：ソフトウェアサプライヤ向け
- 第3部：ソフトウェアカスタマー向け
構成は？
全60ページ、Appendixを除けば36ページです。
以下3セクションの構成です。本記事はメインである2.を読みます。
- Introduction
- Developer
- Appendices
2.の中に、2.1～2.5の5セクションに分けて開発者が考慮すべき対策が書かれています。
- 2.1 Secure product criteria and management （8ページ）
- 2.2 Develop Secure Code（14ページ）
- 2.3 Verify Third-Party Components（4ページ）
- 2.4 Harden the Build Environment（8ページ）
- 2.5 Deliver Code（3ページ）
各セクションには開発プロセスに関する脅威と、それに対する推奨緩和策（Recommended mitigations）が示されます。
本書はこの推奨緩和策の集合体であり、とりあえず何すればいいの？を知るには緩和策を読めばよい仕組みです。
本書の日本語訳
翻訳版が見当たらなかったので作りました。ただし、機械翻訳したものを少し手直しした程度なので、読む分には支障はないと思いますが正確性は保証できません。
以下の点は諦めています。
- 脚注は削除しています。
- ですます、である調の統一はしていません。
- 組織名の訳がおかしいまま（CISAの日本語訳とか）です。
前提知識
3部作のガイダンスがそれぞれ対象とする登場人物は以下を意味します。
- カスタマー：サードパーティのソフトウェアを購入して使用する組織
- 開発者：カスタマーから見たサードパーティの組織にいる開発部隊
- サプライヤ：カスタマーから見たサードパーティの組織にいる開発者とカスタマーの橋渡し役
つまり、サプライチェーンの状況により、同一人物が開発者にもカスタマーにもなりえると考えられます。
（自分が開発するソフトウェアにサードパーティのコンポーネントを組み込む時はカスタマーの立場であり、それらを含めた最終的なソフトウェアを提供する意味では開発者の立場）
図1、2がこの3者の関わり方を理解するのに役立ちます。
2 Developer
本書が想定する脅威シナリオは大きく以下の4つです。
- 敵が意図的に悪意のあるコードを注入したり、開発者が意図せずに脆弱なコードを製品に含めたりする。（2.2セクションに対応）
- サードパーティの脆弱なソースコードやバイナリを、故意または無意識のうちに製品に組み込む。（2.3セクションに対応）
- 製品のコンポーネント内に悪意のあるソフトウェアを注入するために使用されるビルドプロセス内の弱点を悪用する。（2.4セクションに対応）
- 配信メカニズム内で製品を改変し、その結果、カスタマーによって導入されたオリジナルのパッケージ、アップデート、またはアップグレードバンドル内に悪意のあるソフトウェアを注入する。（2.5セクションに対応）
2.1 安全な製品の基準と管理
本セクションでは上記の脅威によらない、組織の体制やプロセス面の緩和策を挙げています。
推奨緩和策は以下です。
- アーキテクチャ文書と設計文書を作成する
- トレーニングを受け、資格を有し、信頼できる開発チームを集める
- ソフトウェア製品の脅威モデルを作成する
- セキュリティテスト計画を策定し、実施する
- リリース基準を定め、それに照らして製品を評価する
- 製品サポートと脆弱性対応の方針と手順を確立する
- 開発者の能力とセキュアな開発プロセスに関する理解度を評価し、トレーニングを実施する
- 各ソフトウェアリリースのセキュリティ手順とプロセスを文書化し、公表する。
要件を決め、チームを集め、設計段階からセキュリティを考慮し、テスト計画をたてて実施し、リリース基準に基づき品質を評価する。
緩和策のタイトルだけ読むと目新しさのない記載に見えますが、本書では緩和策１つ１つに細かい補足説明が続きます。
例えば、「アーキテクチャ文書と設計文書」はカスタマーから集めた要件や業界のセキュリティ基準、ゼロトラストの原則などを考慮して作成すべし。「セキュリティテスト計画」はQAチームが計画策定し、開発者が実施すべし（QAも追加でやるような記載もある）、計画にはテストで確認するコードカバレッジや利用するテストツールの種類を含めるべし。といった形です。
セクションのタイトルに含まれる「基準」については、リリース準備基準、リリース基準の2つが言及されています。
リリース準備基準には、リリースごとにSASTやDASTでチェックするとか、ペネトレーションテストを最低年1以上で実施するといったテストの要件が含まれます。
リリース基準には、許容できない脆弱性が残っていないこと、定めた成果物（DFDやUML、脅威モデル、テスト結果、脆弱性のリスト等）があること、SBOMを作っていること、信頼できる暗号鍵でバイナリを署名していること、組織の暗号化標準に沿っていること等を含めるべきとしています。
2.2 安全なコードの開発
2.1～2.5のうち、このセクションが最も分量が多いです。
本書では2.2の中で更に2.2.1～2.2.6の6つに分けて安全なコードの開発を実現するための推奨緩和策を示していますが、この記事では以下にまとめて書きます。
まず、脅威シナリオとして、開発者が開発する際に危険なコードや設計上の欠陥が紛れ込むきっかけとして以下が挙げられています。
- 組織に不満を持つ内部のエンジニアや、そうした人を利用しようとする外部の攻撃者による不正
- 悪意はないがスキル不足なエンジニアによる脆弱性の作りこみ
- 開発中にデバッグのために仕込んだ隠し機能の消し忘れ
- リモートの開発拠点（自宅など）を起点とした侵入とコードの改ざん
- 残存したままの不要な開発アカウントを悪用されたコードの改ざん
- 利用していたOSSに脆弱性が含まれる
- 当初の製品開発チームとは異なる開発チームがメンテナンスを担った際の脆弱性の作りこみ
推奨緩和策は以下です。
型安全性のようなメモリ保護機構が組み込まれた言語を選ぶことや、Saltzer and Schroederの原則に従うことがセクションの冒頭に挙げられた上で、以下について解説されています（非常に多いです）。
- バランスよく認証されたソースコード・チェックイン・プロセスを実装する
- 多要素認証を用いたソース管理システムへのアクセス制御
- アクセスした人やファイルの変更、チェックインのログ取得
- ピアレビューやリードレビューを受けたコードだけがチェックインを認められるプロセス
- 開発ブランチでQAチームが検証したコードだけが本番ブランチに移行できるプロセス
- 必要最小限の原則に沿った本番ブランチのアクセス制御
- 静的及び動的なセキュリティ／脆弱性スキャニングの自動実行
- セキュリティテストとリグレッションテストを伴う夜間ビルドの実施
#開発者自身がコーディングの際に行う単体テストとは別に、QAチームやビルドチームによって作りこまれたテストとビルドのサイクル - 機能を要件に適合させる
- コードレビューの優先順位付けと重要コードのレビュー
- コードの中でも重要なもの、つまり、暗号化に関わるもの、権限昇格を行うもの、保護されたリソースにアクセスするもの、ミッションクリティカルなもの、全体の部品の中で利用頻度が高いもの等は重点的なレビューが必要
- 非公式のコードレビューは開発グループ内で実施されるもの
- 公式のコードレビューはQA、ビルドチーム、デザイナー、アーキテクトを含むチームが実施。レビューのアウトプットはリリース基準の確認に用いられる
- セキュアなソフトウェア開発／プログラミングのトレーニング
- 開発環境の強化
- 開発者が外部からダウンロードしたコンポーネントに対する、SCA等を用いた構成管理と継続的な脆弱性スキャン
- コンパイラやアセンブラ、インタープリタに備わるセキュリティ機能の活用
- GSオプション等のStack Cookiesの指定、ASLRやDEP、SEHOPのようなOS標準のセキュリティ機能の活用
- ソフトウェアの利用者の実行環境を保護する手法として、アンチウイルスソフトが備えるヒープスプレー攻撃やスタックピボット対策機能、あるいはルートキットを検出する機能を活用
- カスタマーや機関（CISAなど）から脆弱性の報告を受け付けるプロセスの準備
- 報告された脆弱性に対する分析と是正、およびアップデート版の安全な配布プロセスの準備
- 当初の製品から変更したコードやサプライヤの情報が分かるようにSBOMを公開
2.3 サードパーティコンポーネントの検証
EO 14028自体がSolarwinds事件を背景に発行されたことからも分かるように、本書全体を通してサードパーティソフトウェア経路での脅威の侵入に警戒していることが分かります。
このセクションはまさにそうしたリスクを低減するために、外部から入手したコンポーネントを徹底的にチェックすることを求めています。
このセクションはカスタマー向けのようにも見えますが、サードパーティ製品を自社が開発するソフトウェアに組み込む際に、開発者が行うべき対策という位置づけかと思いました。
推奨緩和策は以下です。
なお、ここでの「コンポーネント」の表記は全てサードパーティ製のコンポーネントを指します。
- コンポーネントがバイナリ形式で提供された場合であっても、バイナリスキャンやSCAツールを用いて内包されるOSSを検出し、脆弱性を管理する
＃経産省のSBOMの手引きでは、バイナリファイルだと精度はかなり低いとありましたが…。 - コンポーネントを自組織に組み込む前にSAST/DASTによるスキャンやレビューを行う
- 出所と信頼性が分からないコンポーネントはダウンロードしない
- サードパーティの所有権と管理状況、DUNSナンバー、サプライヤとその上流サプライヤの過去の脆弱性の対応実績、生産国を考慮して選択や判断する
- 以下の観点でコンポーネントのサプライヤの信頼度を評価する
- コンポーネントを採用後に出た脆弱性を確認し、自組織への影響を確認する
この他に、2.3.5ではSBOMについて強調しているパートがありましたが、内容は上記のリストとほぼ同じでしたので割愛します。
2.4 ビルド環境を強化する
せっかく開発したソースコードの脆弱性を修正しても、ビルドの段階で悪意あるコードを混入されたら台無しです。
攻撃者は、開発ネットワークに侵入し、リポジトリやビルドシステムの脆弱性をつくことでコンパイルしたソースコードやライブラリ等に不正コードの注入を試みます。
あるいは、署名サーバを侵害して不正なソフトウェアを本物のように配信する方法もあります。
まずはビルド環境の守り方から。
本書では開発ビルド環境と本番ビルド環境の2種類が存在します。
前者については2.2.3（本noteでは2.2の「開発環境の強化」）を見てねと書いていますが、この2.4のセクションは対象が本番ビルド環境なのか両方なのかハッキリしません。(内容も一部は2.2.3と重複）
推奨緩和策は以下です。
対象はビルドパイプラインに含まれるリポジトリ、ワークステーション、ビルドシステム、署名サーバ、展開サーバなどです。
- ロックダウンによる機能の最小化
- ネットワーク接続を最小化（許可リスト型でURLやサービスを制限）
- データ漏洩、特にコードリポジトリとエンジニアリングワークステーションを監視し、侵入対策機能の活用する
- 侵入と流出を防ぐように構成
- ビルドスクリプトと構成ファイルは、セクション2.2.1「内部関係者によるソースコードの変更または悪用」と同じコードレビュープロセスの対象とする
- パイプライン構成のバージョン管理
＃継続的デリバリー（CD）パイプライン環境では、CDオーケストレーターがパイプラインのバージョン管理を行う。これにより、不審なシステムの変更を発見しやすくなる - 各システムへのアクセスに多要素認証を採用
- エンジニアリングネットワークを企業ネットワークから分離（できればインターネットからも分離）
- サービスアカウントを最小限に抑え、定期的にログイン履歴を監査
- ビルドパイプラインへのすべてのアクセスをログに記録
- ビルドパイプラインに関連付けられたシークレットを保護
＃デフォルトのユーザ名とパスワードの変更、平文保存の禁止、ログへの記載禁止、定期的なローテーションなどのベストプラクティスの採用
更に、本書では上級編の推奨緩和策として「Hermetic builds」と「再現可能なビルド」が紹介されています。
「Hermetic builds」の日本語訳はあまり見つかりませんが「密閉ビルド」という記載がネット上に見当たりました。
これは、ビルドに必要なサードパーティのコードも、コンパイラもやリンカなどのツールも、全てをコンテナなどの隔離したビルド環境に閉じ込めてしまうことです。
これによりビルドシステムをネットワークから隔離できるようになり、攻撃に対する防御力が高まります。
「再現可能なビルド」は自動化した仕組みを用いて、同一の入力を与えると毎回同じビルド結果が得られることを意味しています。
Hermetic buildsも結果的には再現可能なビルドに繋がる話です。
次に署名サーバの守り方についてですが、これは一般的な標的型攻撃対策と同じなので割愛します。
例えば多要素認証を使うとか、IPSやSIEMで監視するとか、脆弱性スキャンを侵入テストを行うといったことが書かれています。
2.5コードの配信
完成したソフトウェアをカスタマーに届ける際にも様々なリスクがあります。
例えば、ビルドの時に気づかなかったシークレットや不要なコンポーネントの混入、リポジトリの侵害や中間者攻撃による悪意あるソフトウェアとの差し替えが考えられます。
推奨緩和策は以下です。
開発者（およびサプライヤ）が配送用のパッケージを保管するリポジトリと、カスタマー側のパッケージマネージャの双方でチェックしあうことを求めています。
- バイナリソフトウェアの構成分析ツールを用いて、最終成果物の中にシークレットや意図しないコンポーネントが混在していないことを確認する
- 開発者は提供するソフトウェアに関するSBOMを提供し、サプライヤとカスタマーは構成分析ツールを用いて整合がとれていることを確認する
- 提供するソフトウェアに電子署名や暗号ハッシュを付けてリポジトリに公開し、パッケージマネージャ側でそれらを検証する
＃なお、SBOMや開発ドキュメントを含め、どこまでを署名の対象とするかはガイドラインや標準が必要との記載あり - リポジトリとパッケージマネージャの双方でパッチ適用や監視を行いサーバを堅牢にするとともに、サーバ間の通信をTLSで保護する
まとめは以上です。
全体的にSSDFから一段階記載が細かくなった印象と、3部作を1か月おきに発行したスピード感のためか、まだまだ構成がきれいに整理されていない印象を受けました。
多くの組織で開発環境のセキュリティ対策は本番に比べて緩いはずであり、途中に記載のあった「インターネットからの隔離」などは開発者の利便性を考えるとなかなか難しいように思います。
本書（およびEO 14028）の背景であるSolarwinds事件のように万が一侵害されたら広く社外に影響を及ぼすソフトウェアと、自社だけで使うソフトウェアでは守り方に差が生まれるのは当然かと思いますので、結局はリスク分析した上で取り組むべき話ですね。
