海の向こうの“セキュリティ”

自主的な「ソフトウェアセキュリティ実施基準」で示された14の原則とは。英国政府が策定

 英国政府は、組織や企業が依存するソフトウェアのセキュリティとレジリエンスを向上させることを目的に、自主的な「ソフトウェアセキュリティ実施基準(Software Security Code of Practice)」を策定し、2025年5月に公開しました。あくまで「自主的な(voluntary)」な基準であり、現時点で法的拘束力はありませんが、英国政府は本基準をベースにした認証制度の構築を検討しています。

 本基準は、英国家サイバーセキュリティセンター(National Cyber Security Centre、以降NCSC)の技術専門家と、業界や学術界の専門家グループが共同で策定したもので、2024年5月から8月まで実施された意見公募からのフィードバックも踏まえて改良を重ねたものとなっています。また、カナダのサイバーセキュリティセンター(Canadian Centre for Cyber Security)も策定に協力しています。さらに、PDFでは表紙を含めて9ページとコンパクトにまとめられており、HTML版も提供されています。ただし、HTML版はPDF版のレイアウトやデザインを完全には再現していないため、少々読みづらく感じられる部分もあるかもしれません。

 今回公開された実施基準は、市場全体にわたって一貫したソフトウェアセキュリティとレジリエンスのベースラインを確立するために、ソフトウェアベンダーが実装することが期待される14の原則から構成されています。なお、オープンソースの開発者およびメンテナーについては、本基準の主な対象とはなっていませんが、当然ながら参考にすべき部分はあります。

 この14の原則は以下の4つのテーマに分類されています。

  1. セキュアな設計と開発(Secure design and development)
  2. ビルド環境のセキュリティ(Build environment security)
  3. セキュアな導入と保守(Secure deployment and maintenance)
  4. 顧客とのコミュニケーション(Communication with customers)

 この実施基準では、対象者によって上記4つのテーマへの関連度合いが異なることが明記されています。

ソフトウェア開発者および販売業者

ソフトウェアまたはソフトウェアサービスの開発と販売の両方を行なう組織は、上記4つの全てに従うことが求められる。

ソフトウェア再販業者

ソフトウェアを販売するが、自組織ではソフトウェアを開発しない組織については、上記3から4のみが責任範囲に含まれるが、可能な限り、自組織が流通させるソフトウェアの開発者に対して、本実施基準の原則に従うよう促すべきである。

ソフトウェア開発者のみの場合

ソフトウェアを開発するが、ソフトウェアの販売または流通には関与しない組織については、上記1および2が適用され、組織/個人の責任範囲内にある場合には上記3も適用される。

オープンソースの開発者およびメンテナー

すでに紹介したように、本実施基準はオープンソースの開発者およびメンテナーを主な対象としていない。オープンソースソフトウェアの場合、開発者/メンテナーは、サプライチェーン全体、またはコードの継続的な保守とセキュリティに関して、正式な責任を負うものではない。オープンソースのコードに関連するリスクは、エンドユーザーまたは自組織のソフトウェアでオープンソースのコードを使用しているプロプライエタリ開発者が管理する必要がある。

 以下に14の原則を紹介します。

1. セキュアな設計と開発

これらの原則により、ソフトウェアが提供される際に適切なセキュリティが確保される。

ベンダー組織の上級責任者(Senior Responsible Owner)は、自組織が販売するソフトウェアまたはソフトウェアサービスに関して、自組織が以下を達成していることを保証する必要がある。

1.1 確立されたセキュアな開発フレームワークに従う。
1.2 ソフトウェアの構成を理解し、開発ライフサイクル全体を通じてサードパーティ・コンポーネントの取り込みと保守に関連するリスクを評価する。
1.3 配布前にソフトウェアおよびソフトウェアアップデートをテストするための明確なプロセスを持つ。
1.4 ソフトウェアの開発ライフサイクル全体を通じて、セキュア・バイ・デザインおよびセキュア・バイ・デフォルトの原則に従う。

2. ビルド環境のセキュリティ

これらの原則により、ビルド環境が危険にさらされるリスクを最小限に抑え、ソフトウェアの整合性と品質を保護するための適切な手順が確実に実行される。

ベンダー組織の上級責任者は、自組織が販売するソフトウェアまたはソフトウェアサービスに関して、自組織が以下を達成していることを保証する必要がある。

2.1 ビルド環境を不正アクセスから保護する。
2.2 ビルド環境への変更を制御し、ログに記録する。

3. セキュアな導入と保守

これらの原則により、ソフトウェアはその耐用期間全体にわたってセキュリティを維持し、脆弱性の発生確率と影響を最小限に抑えることができるようになる。

ベンダー組織の上級責任者は、自組織が販売するソフトウェアまたはソフトウェアサービスに関して、自組織が以下を達成していることを保証する必要がある。

3.1 ソフトウェアを顧客にセキュアに配布する。
3.2 効果的な脆弱性開示プロセスを実装して公開する。
3.3 ソフトウェアコンポーネントの脆弱性を積極的に検出し、優先順位を付け、管理するためのプロセスと文書を用意する。
3.4 適切な場合は脆弱性を関係者に報告する。
3.5 セキュリティアップデート、パッチ、通知を顧客にタイムリーに提供する。

4. 顧客とのコミュニケーション

これらの原則により、ベンダー組織は効果的なリスクおよびインシデント管理を可能にするために十分な情報を顧客に提供できるようになる。

ベンダー組織の上級責任者は、自組織が販売するソフトウェアまたはソフトウェアサービスに関して、自組織が以下を達成していることを保証する必要がある。

4.1 販売するソフトウェアに対して提供されるサポートおよび保守のレベルを明記した情報を顧客に提供する。
4.2 ベンダーによるソフトウェアのサポートまたは保守が終了する場合は、遅くとも1年前に顧客に告知する。
4.3 顧客組織に重大な影響を及ぼす可能性のある重要なインシデントに関する情報を顧客に提供する。


 コンパクトにまとめられた内容で普遍性も高く、特に、開発そのものだけでなく、導入や保守、顧客とのコミュニケーションにまで言及しているのは重要な点です。また、オープンソースについては、開発者やメンテナーは本実施基準の主な対象ではないとする一方で、オープンソースのコードに関連するリスクは、エンドユーザーまたは自組織のソフトウェアでオープンソースのコードを使用しているプロプライエタリ開発者が管理する必要があると明確に指摘している点も重要です。ソフトウェアの開発や販売に関わる企業の方は一度は目を通しておくべき文書でしょう。

山賀 正人

CSIRT研究家、フリーライター、翻訳家、コンサルタント。最近は主に組織内CSIRTの構築・運用に関する調査研究や文書の執筆、講演などを行なっている。JPCERT/CC専門委員。日本シーサート協議会専門委員。