【要点抽出】NIST SP800-218 Secure Software Development Framework

ニキヌス

EO 14028の第4条で命じられたソフトウェア・サプライチェーン・セキュリティの強化に向けて作られたSecure Software Development Framework（SSDF）を読みます。

https://csrc.nist.gov/pubs/sp/800/218/final

何の本？

上述の通り、本書は米大統領令を受けてNISTがまとめたものであり、SP800-218という番号で公開されています。
「セキュアな開発ライフサイクルを実現するにはこういうことをしなきゃいけないよね」という上位レベルの要素を書いたものであり、開発言語や開発規模によらずどこでも使える共通的なエッセンスをまとめています。
そのため、本書は具体的なツールや技術の話にはフォーカスしていません。

構成は？

全27ページ、Appendixを除けば19ページというコンパクトさです。
章立てもシンプルに

  1. Introduction

  2. The Secure Software Development Framework

しかなく、２．の推奨する慣行（Practices）を書いた表がメインです。本noteではこれをまとめます。

セキュアなソフトウェア開発とは？

本書に入る前に、「セキュアなソフトウェア開発」って何でしょうか。
なんとなく、脆弱性のないソフトウェアを作ることあたりが思いつきます。

しかし、せっかく脆弱性のないソフトウェアを作っても、それを攻撃者に改ざんされてしまったらどうでしょうか。
あるいは、凄腕のエンジニアなら脆弱性のないソフトウェアを作れたとしても、その人が携わらない体制で作られた（例えば3rdパーティから取得した）ソフトウェアでも同じ品質を保てるでしょうか。
そもそも「脆弱性のない」なんてありえるのでしょうか。ないと思っていてもあるのが脆弱性なわけで、それをどう見つけて修正するのでしょうか。

これらの観点をひっくるめて、組織レベルで・脆弱性を極力なくし・利用者の手元まで安全に届けられ・品質を継続的に改善することが「セキュアなソフトウェア開発」であり、その実現には特定のエンジニアの技量やツールといったミクロな話ではなく、組織全体の体制やプロセスから整える必要があります。本書はそうした目線で取り組むべきことが書かれています。

２．The Secure Software Development Framework

本書の日本語訳を作られていたこちらを参考にさせて頂きました。

本書では、安全な推奨慣行(Practices)を4つのグループで表しています。
この4グループの中に、合計19個のPracticesがあり、更にそれらは42個のTasksに分解されます。

  • 組織の準備（PO）： 組織レベルで安全なソフトウェア開発を実行するための、従業員、プロセス、および技術の準備

  • ソフトウェアの保護（PS）： ソフトウェアのすべてのコンポーネントを改ざんや不正アクセスから保護する

  • 安全性の高いソフトウェアの製造（PW）： リリース時のセキュリティの脆弱性を最小限に抑える

  • 脆弱性への対応（RV）： リリース時に残存している脆弱性を特定し、対処し、将来同様の脆弱性が発生しないように対応する

組織の準備（PO）

ここには5個のPractices、13個のTasksが含まれます。

【PO.1】 ソフトウェア開発のセキュリティ要件を定義する

  • 組織のソフトウェア開発環境、プロセス、あるいはソフトウェアが満たすべきセキュリティ要件を決めて文書化する。

  • また、それらの要件をソフトウェアを取得するサードパーティにも（契約に含めるなどして）伝える。

  • 要件は最低年1回更新し、関係者を教育する。

【PO.2】 役割と責任を実装する

  • SⅮLCに係る全ての人に対して、役割と責任を定義し、それぞれにあわせた教育を定期的に行う。
    「役割」とは、セキュリティ担当、セキュリティチャンピオン、PMやPL、開発者、テスターオーナー、運用担当者など。
    「セキュリティチャンピオン」とは、開発チームの士気や文化を「セキュリティ向上」に向けるチアリーダー的な存在。開発者側にいるセキュリティの啓発担当的な人。

  • 「セキュアな開発をやるぞ！」というトップダウンな宣言をしかるべきエラい人に出してもらい、それを全員に伝える。

【PO.3】 支援ツールチェーンを実装する

  • SDLC全体にセキュリティを組み込むために、ツールを活用してプロセスを自動化する。

  • このツールを用いて、セキュアなソフトウェア開発を行っていることを示すアーティファクト（証拠の一部）を記録する。

  • 活用するツールそのものについても、セキュリティ要件を守る。
    #CI/CDパイプラインに関するツールなどを指している気がする。

【PO.4】 ソフトウェアのセキュリティ点検に対する基準を定義し使用する

  • ソフトウエアのセキュリティ点検の基準を決めるとともに、それを守るために必要なプロセスや仕組みを実装する。
    「セキュリティ点検の基準」とは、例えばKRIや脆弱性の重大度のスコアなど。

【PO.5】 ソフトウェア開発のための安全な環境を実装し維持する

  • ソフトウェアの開発環境（ビルドやテストを行う環境も含む）を保護するために、各環境を分離し、認証などのアクセス制御やログ監視を行う。
    「各環境」とは、本番/開発環境間や、異なるシステム間を指す。

  • 開発に用いるエンドポイント（サーバや端末）についても、機能の最小化や多要素認証、暗号化などのハードニングを行う。

ソフトウェアの保護（PS）

ここには3個のPractices、4個のTasksが含まれます。

【PS.1】 すべての形式のコードを不正アクセスや改ざんから保護する

  • ソースコードや実行可能コードへのアクセスを必要最小限に絞り、不正なコードの混入やソフトウェアの盗難リスクから守る。

  • リポジトリのバージョン管理機能を用いたトレーサビリティの確保や、コード署名やハッシュ値を用いた整合性の保護を行う。

【PS.2】 ソフトウェアリリースの整合性を検証するための仕組みを提供する

  • 取得したソフトウェアが正規であり改ざんされていないことを確認するために、コード署名やハッシュ値を用いた整合性の確認を行う。

【PS.3】各ソフトウェアリリースをアーカイブして保護する

  • リリースしたソフトウェアの脆弱性を修正するために、リリースごとに必要なファイルや整合性検証の情報などをアーカイブする

  • リリースしたソフトウェアのコンポーネントの出所データを保持および共有する。
    「出所データ」とは、SBOMで言われるようなソフトウェアの構成要素の出自を示す情報。本書においても (e.g., in a software bill of materials [SBOM])とあえてSBOMに言及している。

安全性の高いソフトウェアの製造（PW）

ここには8個のPractices、16個のTasksが含まれます。

【PW.1】 セキュリティ要件を満たしセキュリティリスクを軽減するソフトウェアを設計する

  • 脅威モデリングやアタックサーフェスのマッピング等のモデリング手法を用いてソフトウェアのリスクを評価し、設計に反映する。

  • リスクへの対応策は独自に作りこまず、できるだけ標準化したものを組み込む。

  • 洗い出されたリスクや求められるセキュリティ要件への対応について、どのように対処したのかを後で追えるようにしておく。

【PW.2】セキュリティ要件とリスク情報への準拠を検証するためにソフトウェア設計をレビューする

  • ソフトウェアの設計から独立した第三者やツールによるレビューにより、必要なセキュリティ要件や洗い出されたリスクに対処できていることを確認する。

【PW.4】可能な場合、機能を複製する代わりに既存の安全性の高いソフトウェアを再利用する
(PW.3はPW.4に統合されたため欠番）

  • 個別に開発すると危険な暗号化モジュールなどのセキュリティ機能は、モジュールやサービスの再利用を優先する。

  • そのためにも、商用やオープンソースなど外部で開発された安全性の高いコンポーネントを取得し、それらが組織のセキュリティ要件を満たしていること、あるいは危険な脆弱性が放置されていないことを確認する。
    #ここでもSBOMの取得が言及されている。

  • 外部からの取得ではまかなえない部分は、共通的に活用することを前提に社内で開発する。

【PW.5】安全なコーディング慣行を遵守してソースコードを作成する

  • 開発言語と環境に適したコーディング慣行に従うことで危険な脆弱性を最小限に抑える。
    「コーディング慣行」とは、入力値の検証のようなセキュアコーディングの実践だけでなく、リンターを用いたスタイルの標準化やピアレビューも含む。

【PW.6】実行可能形式のセキュリティを向上させるために、コンパイル、インタープリタ、およびビルドプロセスを構成する

  • コンパイラ、インタープリタ、およびビルドツールを適切な構成で用いてソフトウェアの脆弱性をテスト前に減らす。
    「適切な構成」とは、最新のツールを使うことや、セキュリティ面に問題があるコードに警告を出す機能の有効化などを指す。

【PW.7】脆弱性を特定し、セキュリティ要件への準拠を検証するために、対人可読なコードのレビューや分析のいずれかもしくは両方を実施する

  • 組織のルールに沿ってコードレビューやコード分析を行い、洗い出された問題点を記録および優先順位付けする。

【PW.8】脆弱性を特定し、セキュリティ要件への準拠を検証するために、実行可能コードをテストする

  • PW.7と内容はほぼ同じ。PW.7が静的診断（SAST）の記載で、PW.8は動的診断（DAST）の記載と思われる。

【PW.9】 デフォルトで安全な設定となるようにソフトウェアを構成する

  • ソフトウェアをインストールした時から安全な設定状態で使える「セキュア・バイ・デフォルト」になるよう構成する。

脆弱性への対応（RV）

ここには3個のPractices、9個のTasksが含まれます。

【RV.1】継続的に脆弱性を特定して確認する

  • リリースまでに見つけきれなかった脆弱性がソフトウェアに潜んでいる可能性があるため、様々な情報ソースからソフトウェアおよびソフトウェアが使用するサードパーティコンポーネントの脆弱性情報を収集したり、コードレビューや診断を継続的に行ったりする。

  • 発見した脆弱性については、開示や修復を行うためのポリシーや体制、プロセスを用意する。

【RV.2】脆弱性を評価、優先順位付け、および修正する

  • 発見した脆弱性を分析し、リスク対応計画に落とし込む。
    「リスク対応計画」とは、リスクの低減・回避・受容・移転の選択や、根本策までの暫定策の検討を指す。

【RV.3】脆弱性の根本原因を特定するために脆弱性を分析する

  • 発見した脆弱性が作りこまれた根本原因を分析し、SDLCプロセスを改善する。

  • 同じソフトウェア内、あるいは他のソフトウェアに同様の脆弱性がないかチェックを横展開し、事前に是正する。

＊＊＊はじめての方へ＊＊＊
これは何のnoteだ？と思われた方はこちらをご覧ください。
これまでにまとめたガイドライン類の一覧はこちら

この記事が気に入ったらサポートをしてみませんか？