The English version of this article will be available later.
はじめに
こんにちは。OpenChain Japan-WG、Tooling-SGリーダーの忍頂寺です。
本稿は4部構成になっています。
- 「Open Source Security Sumit Japan」
- 「ITMedia @IT連載企画「解決！OSSコンプライアンス」第10回 補稿」
- 「ソフトウェア開発プロセス改善(SPI)とオープンソース活用推進」
- 「今時のSBOMと呼べるかはさておき、実はやっているのでは?」
第1部と第2部は、僕がそれぞれの機会で伝えきれなかったことを補完する記事になります。
第3部は、取組事例として紹介したいことです。
最後の第4部は、SBOMに関する様々なご意見を伺ったことを受けての随筆になります。
1. Open Source Software Security Summit Japan
オープンソースは、自由かつオープンという共通の価値観に支えられています。そして、企業はオープンソースで共創(Co-Creation & Co-Operation)しつつ、自らの市場価値を高める競争(Competition) に取り組みます。企業もそのエコシステムの発展に関わっているオープンソースは、技術や暮らしに欠かせない存在です。オープンソースを「公共財」と捉える見方もあるほどです。一方で、重要インフラなどを対象とするサイバーセキュリティ強化への関心が高まるなか、一部のオープンソースについては重要インフラと同様の扱いが必要だとする意見も聞きます。米国における Open Source Security Summit (ニュースリリース、日本語参考訳)はこうした動きの表れの一つと見ることが出来るように思われます。
国内でもそれに呼応して、2022年8月23日にOpen Source Software Security Summit Japan が開催されました。主催した OpenSSF (Open Source Security Foundation) と Linux Foundation Japan による開催記事を次から参照できます。
- OpenSSF. "Outcomes from Open Source Software Security Summit in Japan"
- Linux Foundation Japan. "Open Source Security Summit Japanの成果" (上記記事の参考訳)
上記の記事にあるとおり、午後のパネルディスカッションに登壇しました。そこで、セキュリティ分野においてもISO/IEC 5230:2020 (OpenChain Specification) への適合が有効であるという意見を述べました。これには次の二つの理由があります。
- ISO/IEC 5230によるプロセスマネジメント標準は、組織におけるSBOM管理運用の実施を求めていること
- SBOM管理記録を用いることで脆弱性管理に効率的に対処できること
1点目は、5230の仕様要件 "3.4 Compliance artifact creation and delivery" で言及する "Compliance artifact" にはSBOMが当然に含まれているからです。
2点目は、少し前提があります。まず、SBOMは、対象となるプロダクトと関係するソフトウェアを網羅できている必要があります。さらに、そうしたSBOMを構成管理データベースで管理するとなお良いでしょう。実際、"log4shell" が話題になったおり、構成管理の確認で影響範囲の特定を円滑に進められた事例があったと聞いています。
また、オープンソース活用には経営層の積極的な関与が重要であることも述べました。これは、プロダクトに占める割合が高まりつつあるオープンソースについて企業としてのソフトウェアに関する技術戦略を持って取り組むべきであり、それに応じた人的資本投資が重要となるためです。
ところで、メモを準備していたのにタイミングを見誤って発言できなかった点を紹介させてください。
私見では、セキュリティとオープンソース活用推進は、連携すべきと考えています。ソフトウェア部品の管理という観点では、共通したプロセスが想定されます。この時、プロセスや管理データベースの運用について、関係する情報を一元的に管理できるような環境を整備があるとよさそうです。そのためにも、CI/CDも活用してできるだけ開発現場の負担にならないことが重要です。さらにいえば、これは、品質保証や品質管理などにも同様のことがあてはまりそうです。
したがって、セキュリティやオープンソースコンプライアンスに関連するSBOMの管理運用プロセスは個別に整備するのではなく、ソフトウェア開発プロセス全体として取り組む必要があると考えています。
なお、OpenChain Project は、セキュリティアシュアランスを対象とするプロセスマネジメント標準として "OpenChain Security Assurance Specification 1.1" を公開しています。この仕様についてもISO/IEC 5230:2020 と同様に国際標準化に向けた取り組みがなされています。
2. ITMedia @IT連載企画「解決！OSSコンプライアンス」第10回 補稿
Japan-WG 有志が寄稿している @ITでの掲載記事「解決！OSSコンプライアンス」」にて第10回記事「SBOMの2大フォーマット「SPDX」「CycloneDX」の違いとは？」を担当しました。SBOMに関する話題を紹介しています。そちらの記事も読んで頂けると幸いです。
ここでは、その記事で挙げたSPDXのデータフィールドのうちのいくつかについて、諸事情で割愛した説明を補足します。次の表は、元記事の「ソフトウェアをパッケージ単位で管理する情報項目」に関する記載の表から一部を抜粋し、さらに注釈番号を添えています。
| データフィールド例 | 説明 |
|---|---|
| PackageDownloadLocation (*1)(*2) | ダウンロードファイルを取得する場合のURLや、VCS (Veersion Control System) のロケーションなど |
| ExternalRef (*1)(*3) | 外部で参照可能な情報。たとえば、パッケージマネージャーを利用してソフトウェアパッケージを取得する場合は、そのロケーションなど。それ以外では、関連する脆弱性情報の参照先など。 |
| PackageLicenseConcluded (*4) | ソフトウェアパッケージに適用されるライセンスのうち、リリースに関係するとして判断したもの |
| PackageLicenseInfoFromFiles (*4) | ソフトウェアパッケージを分析して検出されたライセンスの情報 |
| PackageLicenseDeclared (*4) | ソフトウェアパッケージの著者が宣言しているライセンス情報 |
実際には、取引先からの指定に従って上記や先の記事で挙げたものからいくつかを使う場合や、さらに追加する場合もあるでしょう(*5)。
以上までに添えた注釈番号に対応する補足は次になります。
| 注釈 | 補足説明 |
|---|---|
| 1 | パッケージ管理ツールを介して取得する場合は [PackageDownloadLocation]を”NOASSERTION” として、 [ExternalRef]で取得手段を明確にすればよい。 このフィールドでの “NOASSERTION” の使い方は SPDX2.3の”7.7 Package download location field” を参照のこと。 |
| 2 | 自作モジュールの場合で、ダウンロード手段を提供していない場合は ”NOASSERTION” とする。 |
| 3 | 値の書式は <category> <type> <locator> である。パッケージ管理ツールで取得する手段を明らかにする場合、"category" に "PACKAGE_MANAGER" 、"type" に "maven-central"、"npm"、"nuget"、"bower"、"purl" などのいずれか、”locator” に対応するパッケージマネージャーで管理されるソフトウェア名称やバージョンを所定の書式に従って指定する。詳細は、SPDX2.3の "7.21 External reference field" を参照のこと |
| 4 | 適用されるライセンスが後述するSPDX License List にない場合は、[LicenseID]、 [ExtractedTex]、[LicenseName]、[LicenseComment] などのデータフィールドを用いて明確にする。詳細は、SPDX2.3の "10 Other licensing information detected section" を参照のこと。 |
| 5 | SPDX Lite との互換を取る場合、データフィールド [FilesAnalyzed] を設けてその値を "false" にする。詳細は、SPDX2.3の "Annex G SPDX Lite (Normative)" を参照のこと。 |
CycloneDXについては OpenChain Japan-WG などで勉強会を企画したいところです。
3. ソフトウェア開発プロセス改善(SPI)とオープンソース活用推進
日本SPIコンソーシアム (JASPIC) は、ソフトウェア開発プロセスの改善に関する研究、普及活動を行う団体です。同団体が主催するカンファレンス ソフトウェアプロセス改善カンファレンス SPI Japan 2022 での2件の発表に関わる機会を得ました。
(以下、当日の発表枠順)
- 「オープンソースコンプライアンスのためのプロセスマネジメント標準ISO/IEC 5230の適合に向けて」
忍頂寺 毅 (株式会社 東芝)(PDF) - 「OSSライセンスコンプライアンスを遵守するためのOSS教育の整備と全社展開」
小山 貴和子 (株式会社 東芝)」(PDF)
1件目は、ISO/IEC 5230 (OpenChain Specification)適合に向けたパイロットスタディです。SPI専門家と協業して取り組んだことを紹介しています。
2件目は、E-learningによりグループ全社向けに展開しているOSS教育の事例紹介です。こちらも、SPI専門家と協業しました。
ISO/IEC 5230 は、ソフトウェア開発プロセスについて、経営層を巻き込んでの組織としての整備を求め、開発部門とそれ以外の部門との組織間の連携の重要性を示唆しています。これは、SPIをご存じの方であれば、ごく自然なこととして受け止められるでしょう。一方で、ライセンスポリシー、コントリビューションポリシー、SBOMなどのコンプライアンスアーティファクト(関連成果物)の管理など、オープンソース活用に力点を置いた要件も備えています。そのため、ISO/IEC 5230 に関する取り組みは、SPIとオープンソースコンプライアンスの複合領域と捉えることができます。
上記の2件のいずれも、セッション後の発表者交流にて積極的な質問を受けました。
企業としてSPIやオープンソースコンプライアンスに取り組んでいてもそれぞれ独立しての取り組みになっていることや、コンプライアンスをカバーできるオープンソースの専門家の不足、などへの懸念を挙げる声がありました。企業ごとの事情があるので、一概に解決策と呼べるものを示すのは難しそうです。ただ、企業として取り組む以上、経営層の関与が果たす部分が大という印象を持っています。
4. 今時のSBOMと呼べるかはさておき、実はやっているのでは？
SBOM管理運用に類似した取り組みをしている企業が多いのではないかなと思っています。コンセンサスが醸成されつつあるSBOMとの程度の差はあれ、です。
2022年12月、Open Source Summit Japan 2022 と Open Compliance Summit 2022 に参加しました。そこで、日本の企業や産業界はSBOMの必要性がないと考えている、とか、その重要性や利便性の認識に欠いている、といった趣旨の指摘が見られました。国内外を問わず、僕自身も含めてですが、その指摘に驚いたというか、果たしてそうだろうかと思った参加者はいたようでした。
そうした感想を持った方々の中には、OpenChain Project や SPDX Workgroup などに見られる Linux Foundation における日本企業の活動や、経済産業省におけるサイバー・フィジカル・セキュリティ確保に向けたソフトウェア管理手法等検討タスクフォースの取り組み及びその成果の一つとして次の文書をご存知の方もいました。
-
Collection of Use Case Examples Expanded Regarding Management Methods for Utilizing Open Source Software and Ensuring Its Security
※オリジナルの日本語版：「OSSの利活用及びそのセキュリティ確保に向けた管理手法に関する事例集」
日本で"SBOM" という言葉は、ここ数年で耳にすることが増えたかもしれません。
たしかに、昨今「SBOM」という用語は、米国大統領令 Executive Order 14028 及びそれに関連するNTIA による "The Minimum Elements for Software Bill of Materials (SBOM)" に端を発する取り組みで、一定のコンセンサスが醸成されつつある状況です。商流でのSBOM管理運用ということで標準化の必要性が高くなっていますが、程度の差はあれ、似たような取り組みをしてきた日本企業が多いのが実態ではないでしょうか。
たとえば、ソフトウェアを製品に組み込んだり、サービスとしてリリースなどをしていれば、OSSも含む第三者に由来する知的財産権の管理運用をしているはずです。OSSだけを対象とする場合は「OSSリスト」と読んだり、COTSなどを含む場合は「ソフトウェアリスト」といった名称で管理運用していることがあるのではないでしょうか。これらも、ある種のソフトウェア部品表(Software Bill of Materials: SBOM)といえます。また、こうした部品表と関連付けて脆弱性管理も実施していることでしょう。
ただ、これまでの各社や業界毎の独自の取組が、世界的にできつつあるコンセンサスとギャップがあるかも知れません。そのため、日本企業や産業界は、動向をキャッチアップしつつ、自身のこれまでの取り組みについてフィット＆ギャップ分析を実施し、ソフトウェア開発プロセス改善(SPI)に取り組むことが重要ではないでしょうか。また、日本企業のビジネス事情を踏まえて、進みつつあるコンセンサス形成に提案すべきこともあるでしょう。
国内では強い関心を持ってSBOM管理運用に取り組む企業や産業もあれば、そうではないところもある、というのが実情のように思える次第です。改めて、オープンソースコミュニティでの日本企業からのコントリビューションや、国内でもSBOMやその管理運用に関する情報提供や情報交換の重要性を実感しました。Linux Foundation傘下の OpenChain Project は、コミュニティメンバーにはとくに参加資格はなく、自由に参加できます。また、そのJapan-WGでは、情報交換を日本語で行うこととし、その成果を英語化して海外のコミュニティとの交流を行っています。この取組をより一層強化していきたいところです。
SBOMの管理運用に興味関心のあるかた、Japan-WGに気軽にご参加ください！
おわりに
OSSのサプライヤーとなる場合は組織におけるソフトウェア開発プロセスとしてSBOMの管理運用に取り組むことが重要です。一方で、SBOMの管理運用のコンセンサスが世界的にできつつあるとはいえ、途上の部分もあります。信頼あるソフトウェアサプライチェーンの構築に関心をお持ちの方、オープンソースコミュニティで一緒に取り組みましょう。
明日(12/17)は、@gucci56 さんの Open Compliance Summit 2022 参加レポートになります。お楽しみに！