インド政府 CERT-In SBOM技術ガイド 第１版 (2024.10.03)

こんにちは、丸山満彦です。

SBOMは世界中で検討が進んでいますね...インドでも政府＋CERT-Inから技術ガイドが公表されていました。

ドイツが9月にTR-03183案を公表し、日本も8月末に経済産業省 ソフトウェア管理に向けたSBOMの導入に関する手引ver2.0 を公表し、中国が5月に国家標準「ネットワークセキュリティ技術ソフトウェア部品表 (SBOM) データフォーマット」案を公表していますね...

● Indian Computer Emergency Response Team (CERT-In)

・2024.10.03 Technical Guidelines on SOFTWARE BILL OF MATERIALS (SBOM) Version 1.0

・[PDF]

目次...

1. Executive Summary	1. エグゼクティブサマリー
2. Overview of SBOM	2. SBOMの概要
2.1 Necessity and Utilization	2.1 必要性と活用
2.2 Application & Scope	2.2 適用と範囲
2.3 SBOM Implementation	2.3 SBOMの実施
3. Ecosystem	3. エコシステム
3.1 Levels of SBOM	3.1 SBOMのレベル
3.2 Classification of SBOM	3.2 SBOMの分類
3.3 Roadmap for Organizations to develop and adopt SBOM	3.3 SBOMを開発し採用するための組織のロードマップ
3.4 License Management	3.4 ライセンス管理
4. SBOM Preparation	4. SBOMの準備
5. Process and Practices of SBOM for Software Consumer/Developer/Integrator Organizations	5. ソフトウェア消費者／開発者／統合者組織のためのSBOMのプロセスと実践
5.1 Establish Roles and Responsibilities	5.1 役割と責任を確立する
5.2 Roadmap for Navigating the Functions of SBOM	5.2 SBOMの機能をナビゲートするためのロードマップ
5.3 Secure SBOM Distribution: Access Control and Public/Private SBOM	5.3 安全な SBOM の配布： アクセス管理と公開/非公開SBOM
5.4 SBOM Sharing	5.4 SBOMの共有
6. Vulnerability Tracking and Analysis in SBOM	6. SBOMにおける脆弱性の追跡と分析
7. Recommendations and Best Practices	7. 推奨とベストプラクティス
7.1 Recommendations	7.1 推奨事項
7.2 Best Practices	7.2 ベストプラクティス

エグゼクティブサマリー...

1. Executive Summary	1. エグゼクティブサマリー
Software products are composed of many different components, some of which might come from third party sources. These third-party components and dependencies can have vulnerabilities, which attackers can exploit, leading to security incident or breaches. Key threats include attackers inserting malicious code, vulnerabilities in outdated components, and breaches by compromised suppliers.	ソフトウェア製品は多くの異なるコンポーネントで構成されており、その一部はサードパーティから提供されている可能性がある。これらのサードパーティ製コンポーネントや依存関係には脆弱性が存在する可能性があり、攻撃者はこれを悪用することで、セキュリティインシデントや侵害を引き起こす可能性がある。主な脅威には、攻撃者による悪意あるコードの挿入、旧式のコンポーネントの脆弱性、危険なサプライヤーによる侵害などがある。
These issues can lead to data breaches, operational disruptions, and reputational damage.	これらの問題は、データ漏洩、業務の中断、風評被害につながる可能性がある。
These threats can be countered by maintaining visibility & transparency on software components used for building or developing the software. Software Bill of Materials (SBOM) helps organizations know exactly what components are in their software or assets, making it easier to identify and fix vulnerabilities. By using SBOMs, entities can improve their software security and protect against potential threats.	これらの脅威には、ソフトウェアの構築や開発に使用されるソフトウェア・コンポーネントの可視性と透明性を維持することで対抗できる。ソフトウェア部品表（SBOM）は、組織が自社のソフトウェアや資産にどのような部品が含まれているかを正確に把握し、脆弱性の特定と修正を容易にするのに役立つ。SBOM を使用することで、事業体はソフトウェアのセキュリティを改善し、潜在的な脅威から保護することができる。
A Software Bill of Materials (SBOM) is list of all the components, libraries, and modules that make up a software, providing transparency into its composition. Software composition is important to comprehend as it grows more sophisticated and depends on more external components. In cybersecurity, safeguarding software against cyberattacks requires an awareness of the dependencies and components utilized in its construction. An SBOM is therefore a crucial instrument in contemporary cybersecurity procedures.	ソフトウェア部品表（SBOM）とは、ソフトウェアを構成するすべてのコンポーネント、ライブラリ、モジュールのリストであり、ソフトウェアの構成に透明性を提供する。ソフトウェアが高度化し、より多くの外部コンポーネントに依存するようになると、ソフトウェアの構成を理解することが重要になる。サイバーセキュリティでは、サイバー攻撃からソフトウェアを保護するために、その構築に利用された依存関係とコンポーネントを認識する必要がある。したがって、SBOMは現代のサイバーセキュリティ手順において極めて重要な手段である。
An SBOM is vital for maintaining software security. It helps organizations understand what their software is made of, manage potential risks, respond to security issues, and comply with regulations. Following are the key benefits an organization can derive by implementing SBOM:	SBOMはソフトウェアのセキュリティを維持するために不可欠である。SBOMは、組織が自社のソフトウェアが何で構成されているかを理解し、潜在的なリスクをマネジメントし、セキュリティ問題に対応し、規制に準拠するのに役立つ。以下は、SBOM を導入することによって組織が得られる主なメリットである：
i. Enhanced Security Management: By knowing the components of the software, organizations can identify which components might be vulnerable to security threats for mitigation.	i. セキュリティ管理の強化： i. セキュリティ管理の強化： ソフトウエアの構成要素を把握することで、組織は、どの構成要素がセキュ リティの脅威に脆弱性を持つ可能性があるかを特定し、その低減を図ることができる。
ii. Effective Incident Response: In the event of a cyber-security incident, an SBOM assists in speeding up incident response by providing detailed component information.	ii. 効果的なインシデント対応： サイバーセキュリティインシデントが発生した場合、SBOM は詳細なコンポーネント情報を提供することで、インシデント対応の迅速化を支援する。
iii. Vulnerabilities Identification and Patch Management: By listing all components, organizations can quickly spot and address known vulnerabilities in the software by patching them.	iii. 脆弱性の特定とパッチ管理： すべてのコンポーネントをリスト化することで、組織はソフトウェアに存在する既知の脆弱性を迅速に発見し、パッチを適用して対処することができる。
iv. Supply Chain Security: Supply chain risks can be reduced significantly by gaining visibility into third-party components used in creating a software.	iv. サプライチェーンのセキュリティ： ソフトウェアの作成に使用されるサードパーティ製コンポーネントを可視化することで、サプライチェーンリスクを大幅に低減できる。
v. Assist in Ensuring Compliance: SBOM helps organizations to streamline adherence to security regulations, guidelines and best practices on software security by providing required transparency in software composition.	v. コンプライアンスの確保の支援： SBOM は、ソフトウェア構成に必要な透明性を提供することで、組織がソフトウェアセキュリティに関するセキュリティ規制、ガイドライン、ベストプラクティスの順守を合理化するのを支援する。
vi. Improved Operational Efficiency: With a clear understanding of software components, organizations can streamline their vulnerability management processes, saving time and resources.	vi. 運用効率の改善： ソフトウエアコンポーネントを明確に理解することで、組織は脆弱性管理プロセスを合理化し、時間とリソースを節約することができる。
Indian Computer Emergency Response Team (CERT-In) has released following technical SBOM guidelines for entities, particularly those in the public sector, government, essential services, organizations involved in software export and software services industry.	インドコンピュータ緊急対応チーム（CERT-In）は、特に公共部門、政府、必須サービス、ソフトウェア輸出に携わる組織、ソフトウェアサービス産業の事業体向けに、以下の技術的なSBOMガイドラインを発表した。
Departments and organizations are encouraged to make the creation and provision of Software Bill of Materials (SBOM) a mandatory standard practice as part of software procurement and software development in order to enhance security and reduce the risk of cyber threats.	各部門や組織は、セキュリティを強化し、サイバー脅威のリスクを低減するために、ソフトウェア部品表（SBOM）の作成と提供をソフトウェア調達やソフトウェア開発の一環として必須の標準慣行とすることが奨励されている。
The following chapters delve into various technical aspects of the Software Bill of Materials (SBOM) explaining its purpose, and its growing significance in the software supply chain ecosystem. Second chapter provides overview of SBOM and discuss about the scope and implementation of SBOM, followed by a chapter on SBOM ecosystem, which explains different levels and classifications of SBOM. Subsequent chapters, explore the different standards and data formats employed for representing SBOM information, and elaborate on the minimum elements, data fields, and automation support. Objectives of all processes and practices involved in SBOM, secure SBOM sharing, and distribution are elaborated in this document including approaches for vulnerability tracking and analysis in SBOM. Finally, the last chapter of the document covers recommendations and best practices for SBOM implementation.	以下の章では、ソフトウェア部品表（SBOM）の様々な技術的側面について掘り下げ、その目的と、ソフトウェアサプライチェーンエコシステムにおけるその重要性の高まりについて説明する。第2章では、SBOMの概要を提供し、SBOMの範囲と実装について議論し、続いてSBOMエコシステムに関する章を設け、SBOMのさまざまなレベルと分類について説明する。続く章では、SBOM情報を表現するために採用されているさまざまな標準とデータ形式を探り、最小要素、データフィールド、自動化サポートについて詳しく説明する。SBOM、安全なSBOMの共有、および配布に関わるすべてのプロセスと実践の目的は、SBOMにおける脆弱性の追跡と分析のアプローチを含め、この文書で詳しく説明されている。最後に、この文書の最後の章では、SBOM 実装のための推奨事項とベストプラクティスを取り上げている。

Figure 2: Levels of SBOMの縦横をかえたもの...

Top-Level SBOM	Provides a general summary of the software elements that are either integrated or directly used in a product. Essential details like component names, versions, and their interactions within the software are usually included.	製品に統合されている、または直接使用されているソフトウェア要素の一般的な要約を提供する。コンポーネント名、バージョン、ソフトウェア内での相互作用など、重要な詳細が含まれるのが普通である。
n-Level SBOM	Goes beyond top-level overview to include deeper details and complexities. The "N" in "N-level" represents any arbitrary level of depth, indicating that the SBOM includes information at multiple tiers or levels of granularity.	トップレベルの概要を超えて、より詳細で複雑な内容を含む。N-level 「の 」N "は任意の深さのレベルを表し、SBOMに複数の階層または粒度の情報が含まれていることを示す。
Delivery SBOM	Describes every part, library, and dependency that is part of a software release or delivery package. It offers clarity regarding the makeup of the software that is being supplied.	ソフトウェアリリースまたは納入パッケージの一部であるすべての部品、ライブラリ、依存関係を記述する。提供されるソフトウェアの構成を明確にする。
Transitive SBOM	Includes not only the direct dependencies of a software component but also its indirect or transitive dependencies.	ソフトウェアコンポーネントの直接的な依存関係だけでなく、間接的または推移的な依存関係も含む。
Complete SBOM	Offers a complete and exhaustive list of all the parts, dependencies, and related metadata that are present in a software system.	ソフトウェアシステムに存在するすべての部品、依存関係、関連するメタデータの完全で網羅的なリストを提供する。

---

● まるちゃんの情報セキュリティ気まぐれ日記

・2024.11.09 ドイツ 連邦セキュリティ室 (BSI) 意見募集 TR-03183： 製造者及び製品に対するサイバーレジリエンス要件（一般要求事項、SBOM、脆弱性報告）

・2024.09.01 経済産業省 ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引ver2.0 (2024.08.29)

・2024.05.26 中国 TC260 意見募集 国家標準「ネットワークセキュリティ技術ソフトウェア部品表 (SBOM) データフォーマット」案 (2024.05.16)

・2024.03.14 IPA NIST SP 800-161 rev.1 システム及び組織におけるサプライチェーンのサイバーセキュリティリスクマネジメントのプラクティスの翻訳 (2024.01.31)

・2024.01.08 米国 NSA SBOM管理のための推奨事項 (Ver. 1.1)

・2023.11.12 米国 NSA CISA ソフトウェアサプライチェーンの確保： ソフトウェア部品表の開示に関する推奨事項

・2023.11.09 米国 CISA 脆弱性悪用可能性交換情報の発行時期

・2023.09.26 米国 CISA サプライチェーンリスクマネジメント（SCRM）のためのハードウェア部品表フレームワーク（HBOM）

・2023.09.18 米国 CISA オープンソース・ソフトウェア・セキュリティ・ロードマップ

・2023.09.01 NIST SP 800-204D（初期公開ドラフト）DevSecOps CI/CDパイプラインにソフトウェアサプライチェーンセキュリティを統合するための戦略

・2023.08.15 ドイツ SBOMの要件...技術ガイドライン TR-03183：製造業者および製品に対するサイバーレジリエンス要件 (2023.08.04)

・2023.08.01 経済産業省 ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引

・2023.07.03 OWASP SBOMガイダンス CycloneDX v1.5 (2023.06.23)

・2023.04.25 米国 CISA SBOM関連の二文書

・2023.04.18 国際医療機器規制当局フォーラム 「レガシー医療機器のサイバーセキュリティのための原則と慣行」「医療機器サイバーセキュリティのためのSBOMの原則と実践」 (2023.04.11, 04.13)

・2023.02.21 英国 NCSC サプライチェーン・マッピングのガイダンスを公表しています。。。(2023.02.16)

・2023.02.05 ソフトウェアサプライチェーンリスクの軽減策について...

・2022.11.12 NIST ホワイトペーパー【プロジェクト概要】ソフトウェアサプライチェーンとDevOpsのセキュリティ実践：リスクベースアプローチによるDevSecOpsの実践

・2022.10.06 米国 CISA 拘束的運用指令23-01 - 連邦ネットワークにおける資産の可視化と脆弱性検出の改善

・2022.09.18 米国 行政管理予算局 (0MB) ソフトウェアサプライチェーンのセキュリティ強化 を公表

・2022.07.26 NIST White Paper (Draft) [プロジェクト概要] ソフトウェアサプライチェーンとDevOpsセキュリティの実践：リスクベースアプローチによるDevSecOpsの実践

・2022.07.16 経済産業省 令和３年度委託調査報告書（サイバーセキュリティ関係） 2022.07.14現在

・2022.06.25 NIST SP 1800-34 (ドラフト) コンピューティングデバイスの完全性の検証

・2022.05.08 NIST SP 800-161 Rev. 1 システムと組織のためのサイバーセキュリティ・サプライチェーン・リスクマネジメントの実践

・2022.02.06 NIST ホワイトペーパー： 大統領令14028条第4e項に基づくソフトウェア・サプライチェーン・セキュリティ・ガイダンス

・2021.12.13 Apache Log4j 2 の脆弱性 (CVE-2021-44228)＋ ソフトウェアの管理 + 脆弱性情報の管理

・2021.11.22 英国 サプライチェーンとマネージドサービスプロバイダーのサイバーセキュリティについての質問に対する回答 at 2021.11.15

・2021.10.30 NIST SP 800-161 Rev. 1 (Draft) システムと組織のためのサイバーセキュリティ・サプライチェーン・リスクマネジメントの実践（第2次ドラフト）

・2021.09.03 NIST SP 1800-34B (ドラフト) コンピューティングデバイスの完全性の検証（初期ドラフト）

・2021.06.27 NIST ソフトウェアサプライチェーンにおける「クリティカル・ソフトウェア」の定義：大統領令14028に応えて...

・2021.06.02 米国 国家のサイバーセキュリティ向上に関する大統領令 (EO 14028) に基づくソフトウェアサプライチェーン管理に関係して。。。

・2021.05.13 米国 国家のサイバーセキュリティ向上に関する大統領令

・2021.05.01 NIST SP 800-161 Rev. 1 (ドラフト) システムと組織のためのサイバー・サプライチェーン・リスク管理の実践

・2020.02.05 NISTがサプライチェーンセキュリティの実践資料のドラフトを公開していますね。。。