開発者は、効率と時間の節約のために、アプリケーションを構築するためにサードパーティのコードを日常的に利用しています。しかし、このような外部コンポーネント、特にオープンソースソフトウェア（OSS）への依存は、脆弱性やライセンス問題を含む重大なリスクをもたらす。2023年のGitHubの調査によると、開発者の31%が、セキュリティ脆弱性の発見と修正を、コードを書くこと（32%）に次いで2番目に重要なタスクと考えている。
その結果、多くの組織がOSSへの依存を懸念している。OSSはハッカーに頻繁に狙われるからだ。組織は、ソフトウェア・サプライ・チェーン全体の脆弱性の増加や、最近の有名な攻撃を受け、リスクを効果的に軽減する方法を理解するという課題に直面している。
ESGの調査レポートによると、過去12ヶ月間に91％の企業がソフトウェア・サプライチェーンのインシデントを経験していることが明らかになった。最も一般的なインシデントは以下の通り：
Log4J、Curl、Apache Struts、OpenSSLのような著名な脆弱性はすべて、業務上の被害を多数もたらしている。これらは、ソフトウエアのサプライチェーン内の脆弱性がひとつでも悪用されると、組織に深刻な影響が及ぶことを浮き彫りにしている。こうしたリスクの高まりを受けて、世界中の規制機関は、ソフトウェアの透明性とセキュリティを重視している。の採用が進んでいる。 Software Bill of Materials (SBOM)の採用は、ソフトウェア・サプライチェーンのリスクを管理するための重要な戦略となりつつある。
SBOM規制が勢いを増す
SBOM規制はますます広まっている。多くの政府が、SBOMの実施に関する勧告を発表している。米国では、SBOMの推奨事項がいくつかの政府指針に含まれている：
欧州では、EUサイバーセキュリティ機関（ENISA）が「モノのインターネットのためのSupply Chain 確保のためのガイドライン」を発表し、サイバーセキュリティの向上とソフトウェア関連のサプライチェーンリスクの管理に関する貴重な洞察を組織に提供している。
他の国も同様のガイドラインを出している：
組織はSBOMを使用して、使用しているソフトウェアコンポーネントに関連するリスクを評価し、それらのコンポーネントの脆弱性を特定し、対処するよう助言する。
情報セキュリティ・マニュアル」の中でSoftware 開発のためのガイドライン」において、ACSCは、サイバーサプライチェーンの透明性を高め、アプリケーションに使用される個々のソフトウェアコンポーネントに関連するセキュリティリスクの特定と管理を容易にするために、SBOMを使用することを推奨している。
PCI DSSがSBOMの作成を必要とする理由
ペイメントカードのデータに対するリスクが高まっていることを認識し、PCI DSS（Payment Card Industry Data Security Standard）はSBOM採用の原動力となっている。最新版である PCI DSS 4.0 では、SBOM の使用が義務付けられ、機密情報の保護における SBOM の重要な役割が強調されています。ソフトウェア・コンポーネントの詳細なインベントリを提供することで、SBOM は組織が脆弱性を特定し、プロアクティブに対処できるようにし、コストのかかるデータ侵害や金銭的損失のリスクを低減します。
2004年に制定されたPCI DSSは、クレジットカード情報の保護を目的とした包括的なセキュリティ基準です。PCI DSSは、クレジットカード取引を取り扱う事業者向けに、年間処理量に応じた厳格な要件を定めている。2022年にリリースされたPCI DSS v4.0では、進化する脅威に対応するため、SBOMの義務付けを含む大幅な変更が導入されました。PCI DSS v4.0への準拠は2024年4月までに義務付けられており、特定の要件は2025年3月31日までに段階的に導入されます。
SBOM を義務付けることで、PCI DSS は組織が自社のソフトウェアエコシステムを包括的に理解し、 脆弱性を事前に特定して対処できるようにします。このアプローチにより、コストのかかるデータ侵害や財務上の損失のリスクが大幅に低減されます。
PCI DSSの新バージョンであるバージョン4.0.1が2024年半ばにリリースされました。つまり、旧バージョンの4.0は2024年12月31日以降は無効となる。ただし、新バージョンではルールの追加や削除はなく、期限も変更されていない。したがって、このブログのSBOM要件に関する情報は、バージョン4.0と4.0.1の両方に適用される。
PCI DSS要件6.3.2への準拠
PCI DSS v4.0 の SBOM 要件は、PCI DSS の最新版における広範な機能強化の一部です。バージョン 4.0 で追加された 64 の新しい要件の一部として導入された SBOM 要件は、特に特注およびカスタ ムソフトウェアに焦点を当て、組織がソフトウェアコンポーネントのインベントリを維持する必要性に対応しています。
この要件は PCI DSS 要件 6 に分類され、強力なセキュリティ対策の実装と脆弱性評価および更新の定期的な実 施を通じて、安全なシステムおよびアプリケーションの作成と維持を義務付けています。この要件は、ソフトウェアの脆弱性がもたらすリスクを低減し、カード会員データを保護するために不可欠です。セクション 6 では、主に 5 つの分野を取り上げます：
- 6.1 安全なシステムおよびソフトウェアを開発し、維持するためのプロセスと仕組みが定義され、理解されている。
- 6.2 特注およびカスタムソフトウェアは安全に開発される。
- 6.3 セキュリティの脆弱性を特定し、対処する。
- 6.4 公開ウェブアプリケーションは攻撃から保護されている。
- 6.5 すべてのシステムコンポーネントの変更は安全に管理される。
具体的には、要件 6.3.2 は、サードパーティコンポーネントの脆弱性、またはサードパーティコンポーネ ントプロバイダの侵害がカード会員データの漏洩につながったいくつかの違反から生じた重要な更新で す。要件は次のとおりです：
6.3.2.b サードパーティのソフトウェアコンポーネントを統合した特注およびカスタムソフトウェアを含め、ソフトウェア文書を調査し、インベントリ と比較して、インベントリに特注およびカスタムソフトウェアとサードパーティのソフトウェアコンポーネントが含まれていることを検証する。
組織は、アプリケーションで使用される特定のコンポーネントやサービスを徹底的に文書化し、管理しなければならない。この情報の一部はデータフロー図でカバーされてきたかもしれないが、新しい要件ではより詳細な文書化が求められる。コンポーネントが更新され、変更されるにつれて、これらの詳細を追跡することは困難になる可能性がある。この情報を記録するために、標準的なテンプレートを使用することが望ましい。さらに、GITのようなソースコード・リポジトリの中には、使用中のコンポーネントのリストをエクスポートするツールを提供しているものもあります。最低限、インベントリには以下を含めるべきです：
- アプリケーション・コンポーネント（通常はリポジトリ・プロジェクト）
- サードパーティ製コンポーネントのリスト
- アプリケーションの依存関係のリスト（Tomcat、Jboss、.NET、ミドルウェアなど）
- 承認された支払いページスクリプトのリスト
OPSWAT SBOM が PCI DSS 要件を満たすためにどのように役立つか
ソフトウェアのサプライチェーンのセキュリティを確保するために、SBOMを求める規制がますます増えている。しかし、組織はソフトウェアコード構成の正確なインベントリを構築するのに苦労している。
しかし、正確で包括的な SBOM を作成することは、組織にとって大きな課題である。これらの文書は、ソフトウェアコンポーネントの綿密なインベントリを要求し、その起源、バージョン、相互依存関係についての詳細な情報を必要とする。正確な SBOM がなければ、組織は、ソフトウェアサプライチェーンに内在するリスクを効果的に特定、評価、緩和するのに苦労する。
SBOM生成のためのガイドライン
OPSWAT SBOMは、コードとコンテナの両方に対するSBOMの生成を自動化し、ソフトウェアのサプライチェーンにおけるセキュリティを強化し、コンプライアンスを支援する。
- すべてのコンポーネントと依存関係を特定
オープンソースやサードパーティのライブラリを含むすべてのソフトウェアコンポーネントを、そのバージョンと依存関係とともに正確に特定する。これは、堅牢なSBOMの基礎を形成する。 - OSSリスクの評価
OSSコンポーネントに関連する潜在的なリスクを評価する。ライセンスコンプライアンス、セキュリティ脆弱性、保守状況などの要因を考慮する。ソフトウェアに対する重要度に基づいてコンポーネントの優先順位を決める。 - OSS 脆弱性のスキャン
脆弱性スキャンおよび SBOM 生成ツールを活用して、OSS コンポーネント内の既知の脆弱性を特定する。深刻度とソフトウェアへの潜在的な影響に基づいて脆弱性の優先順位を決定する。
OPSWAT SBOMの使用
OPSWAT SBOMは、コードとコンテナの両方に対するSBOMの生成を自動化し、ソフトウェアのサプライチェーンにおけるセキュリティを強化し、コンプライアンスを支援する。
ここでは、OPSWAT SBOMを活用してSBOMを効果的に生成する方法を紹介する：
アプリケーション内で使用されているすべてのオープンソースライブラリとコンポーネントのインベントリを提供することで、OPSWAT SBOMは、ソフトウェアサプライチェーンにおける依存関係の脆弱性の管理を支援し、ユーザーがアプリケーションの脆弱性を効率的に特定して修正できるようにします。
脆弱性の特定に加え、OPSWAT SBOM は、各ソフトウェアコンポーネントに関連するライセンスを検証する。これにより、ライセンス条項の遵守が保証され、潜在的な法的落とし穴が回避されます。OSS におけるライセンス検出の重要な役割については、こちらをご覧ください。
OPSWAT SBOMは、Java、JavaScript、Go、PHP、Pythonなど、10以上のプログラミング言語をサポートしています。この幅広いサポートにより、さまざまなソフトウェア開発エコシステムにわたる包括的なvulnerability detection 。
コンプライアンス違反に対する罰則
SBOM 要件を含む PCI DSS 基準に準拠していない組織は、毎月 5,000 ドルから 10 万ドルの罰金を課される可能性があります。これらの罰金は、コンプライアンスに関する問題が未解決のままであれば、時間の経過とともにエスカレートする可能性があります。
金銭的な罰則に加え、PCI DSS に準拠しない場合、法的および運用上の重大な問題につながる可能性があります。法的な影響には、訴訟、弁護費用、多額の和解金などが含まれる場合があります。さらに、非準拠は連邦取引委員会（FTC）などの機関による連邦監査の引き金となり、さらなる罰則につながる可能性があります。
PCI DSS 4.0準拠のための次のステップ
SBOM の PCI DSS 4.0 フレームワークへの統合は、より安全なソフトウェア・サプライチェーンへの極めて重要な転換を意味する。OPSWAT SBOM のような高度なツールを活用することで、組織はオープンソースのリスクを効果的に管理し、コンプライアンスを強化し、コストのかかるデータ侵害から保護することができます。
SBOM の活用は、もはやオプションではなく、必須である。ソフトウェアの依存関係を理解し、それに対処するための積極的な対策を講じることで、企業は、業務を保護し、顧客の信頼を構築する強固なセキュリティ基盤を構築することができる。
