なぜ今「ソフトウェアセキュリティ規範」を紹介するのか
안녕하신게라！パナソニック コネクト株式会社クラウドソリューション部の加賀です。
2024年2月、英国政府（科学・イノベーション・技術省：DSIT）は、「Software Security Code of Practice（ソフトウェアセキュリティ規範）」を発表しました。
この規範は英国NCSC（国家サイバーセキュリティセンター）によって作成されましたが、カナダのサイバーセキュリティセンター（CCCS）も共同で本規範を支持・発表しており、国際的な連携のもとで策定されたものです。
ソフトウェアサプライチェーン攻撃の増加と「回避可能な弱点」
近年、ソフトウェアサプライチェーンを狙った攻撃や、ソフトウェアのレジリエンス（回復力）に関わるインシデントが増加しています。
本規範の背景には、こうしたインシデントの多くが、ソフトウェア開発や保守プロセスにおける「回避可能な弱点（avoidable weaknesses）」に起因しているという強い危機感があります。また、ベンダーと利用者の間でのコミュニケーション不足が、被害を拡大させる要因の一つであるとも指摘されています。
この規範は、そうした課題に対処するために、ソフトウェアベンダーや開発者が従うべきセキュリティのベースラインとして策定されました。国際的なソフトウェアサプライチェーン攻撃の脅威が増大する中で、英国とカナダという主要国が共同で発表したこの規範は、グローバルなベストプラクティスの方向性を示す重要な指標となります。
本記事では、ソフトウェアサプライチェーンのセキュリティに関心のある開発者やベンダー担当者に向けて、その要点を整理・解説します。
対象読者
この規範は、主に以下のような組織・役割を対象としています。
-
ソフトウェアベンダー
独自のソフトウェアやSaaSを開発・販売する企業。 -
経営層 (Senior Leaders)
組織内のセキュリティ文化とリソース確保に責任を持つリーダー（「Senior Responsible Owner」の任命が推奨されています）。 -
開発・技術チーム
実際に設計、開発、保守を行う現場のエンジニア。
※ 本規範は主に営利目的でソフトウェアを開発・販売する組織を対象としているため、オープンソースの開発者やメンテナは直接の対象ではありません。しかし、その原則の多くはOSSプロジェクトのセキュリティ向上にも非常に有用です。
英・カナダ共通の指針
この規範は、4つの主要なテーマに分類された14の原則で構成されています。
これらは英国NCSCとカナダCCCSが共通して推奨する、ソフトウェアセキュリティのベースラインとなります。
1. 安全な設計と開発 (Secure design and development)
ソフトウェアが提供される時点で適切に安全であることを保証するための原則です。
-
1.1 確立されたセキュア開発フレームワークに従うこと
脅威分析、セキュアコーディング規約、テスト戦略などを含む構造化されたアプローチを採用します。 -
1.2 ソフトウェアの構成を理解し、リスクを評価すること
SBOM（ソフトウェア部品表）などを活用し、サードパーティコンポーネントの取り込みや保守に伴うリスクを評価します。 -
1.3 配布前にソフトウェアおよび更新プログラムをテストする明確なプロセスを持つこと
セキュリティテストをリリースプロセスに組み込みます。 -
1.4 「Secure by Design」および「Secure by Default」の原則に従うこと
最初からセキュリティを考慮して設計し、デフォルトで最も安全な設定が有効になるようにします。
2. ビルド環境のセキュリティ (Build environment security)
ビルド環境が侵害されるリスクを最小限に抑え、ソフトウェアの完全性を保護します。
-
2.1 ビルド環境を不正アクセスから保護すること
開発環境とビルド環境を論理的・物理的に分離し、アクセス制御を徹底します。 -
2.2 ビルド環境への変更を管理し、ログに記録すること
変更履歴を追跡可能にし、監査できるようにします。
3. 安全なデプロイと保守 (Secure deployment and maintenance)
脆弱性の可能性と影響を最小限に抑えるため、ライフサイクル全体でセキュリティを維持します。
-
3.1 顧客にソフトウェアを安全に配布すること
改ざんを防ぐための署名や安全な配布チャネルを使用します。 -
3.2 効果的な脆弱性開示プロセスを実装し、公開すること
セキュリティ研究者や利用者からの報告を受け付ける窓口を設置し、その場所を明記したsecurity.txtファイルをウェブサイトの.well-knownディレクトリ配下に公開します。 -
3.3 コンポーネントの脆弱性を検出、優先順位付け、管理するためのプロセスを持つこと
使用しているライブラリ等の脆弱性を継続的に監視します。 -
3.4 必要に応じて関連当事者へ脆弱性を報告すること
自社がCVE採番機関（CVE Numbering Authority, CNA）になるか、あるいは既存のCNAを通じて脆弱性情報を登録し、影響を受ける顧客やコミュニティへ透明性をもって報告します。 -
3.5 タイムリーなセキュリティ更新パッチと通知を顧客に提供すること
脆弱性が発見された際の迅速な対応体制を整えます。
4. 顧客とのコミュニケーション (Communication with customers)
顧客が効果的なリスク管理を行えるよう、十分な情報を提供します。
-
4.1 販売するソフトウェアのサポートとメンテナンスのレベルを明示すること
サポート期間や対応範囲を明確にします。 -
4.2 サポート終了（EOL）の少なくとも1年前に通知すること
顧客が移行や対策を行うための十分な猶予を提供します。 -
4.3 顧客に重大な影響を与える可能性のあるインシデントについて情報を提供すること
インシデント発生時のインフォームド・チョイス（十分な情報に基づく判断）を可能にするため、透明性を確保します。
実装と保証 (Assurance)
英国政府は、企業がこの規範に準拠しているかを確認するための「自己評価フォーム」も提供しています。経営層（Senior Responsible Owner）は、これらの原則が組織内で遵守されていることに責任を持つ必要があります。また、将来的にはこのコンプライアンスプロセスに基づいた認証スキームも検討されています。
まとめと日本企業への示唆
この規範は現時点ではボランタリー（任意）なものですが、単なるチェックリスト以上の意味を持ちます。
サプライチェーンセキュリティがビジネスリスクに直結する現代において、本規範への準拠は、ベンダーとしての信頼性を国際的に証明するための重要なマイルストーンとなり得ます。
特に、以下の点で日本の開発者や企業にとっても重要な指針となるでしょう。
-
グローバルスタンダードへの準拠
米国のSSDF（NIST SP 800-218）やEUのCyber Resilience Actとも整合性が取られており、本規範を実践することは、事実上の国際標準に対応することにつながります。
海外の取引先から、これらの規範に基づいたセキュリティ体制を求められるケースは今後増加する可能性があります。 -
国内の取り組みとの連携
日本の経済産業省が策定中の「ソフトウェア管理に向けたソフトウェアサプライチェーンセキュリティガイドライン」などとも目的を同じくするものです。
これらの国内外のガイドラインを併せて参照することで、自社の開発プロセスをより堅牢なものへと改善できます。 -
具体的なアクションへの落とし込み
本規範は、SBOMの活用、脆弱性開示ポリシー（VDP）の設置、EOLポリシーの明文化など、具体的なアクションを促しています。
これらを自社の開発プロセスや文化に組み込むことで、漠然とした「セキュリティ向上」から一歩進んだ、測定可能で継続的な改善サイクルを構築できます。
自社の製品やサービスが、グローバルなサプライチェーンの中で信頼され続けるために、この規範を羅針盤として開発プロセスを見直してみてはいかがでしょうか。
出典
お断り
記事内容は個人の見解であり、所属組織の立場や戦略・意見を代表するものではありません。
あくまでエンジニアとしての経験や考えを発信していますので、ご了承ください。