The English summary follows the Japanese texts.
はじめに
こんにちは。OpenChain Japan-WG、Tooling-SGリーダーの忍頂寺です。
この記事では、オープンソースコンプライアンス関連で今年1年で僕が気になったことを振り返りつつ、少し先の話題も提供できればと思います。
SBOMの透明性と相互運用性
今年は、オープンソースソフトウェア (OSS)の利用においてSoftware Compsition Analysis (SCA)を実施し、利用するソフトウェアを把握してSoftware Bill of Materials (SBOM)を管理することの重要性を改めて認識する1年だったように思われます。
国内でも経済産業省の取組 (@MasatoEndo さんの12日の記事) や、米国でもNTIAにおけるNTIA Software Component Transparencyなどの取り組みが良く知られています。さらに先の5月の米国大統領令はサイバーセキュリティの強化を重視する内容であり (@AyumiWatanabe さんの7日の記事)、SBOM管理の重要性に言及しています。Linux Foundationからは、そうしたサイバーセキュリティに関係するプロジェクトを紹介する記事 "How LF communities enable security measures required by the US Executive Order on Cybersecurity" が提供されました。
SBOMについては、NTIAがplugfestを開催するなどしてオープンソースコンプライアンスに取り組む企業や団体が協力してSBOMで扱うべき情報を検証し、時系列的には、先の米国大統領令を受ける形で、The Minimum Elements For a Software Bill of Materials (SBOM) を公開しました。
その後、SPDX WorkgroupはSPDX Docfestを開催し、SBOMのフォーマットの一つであるSPDXをソフトウェアサプライチェーンで流通して相互利用するための課題の洗い出しや検討を実施しました。この議論は、現行のSPDX仕様の範囲での活用方法はもちろん、次期仕様となる v3.0の検討にもいかされています。
たとえば、話題の一つとして、一つのSPDXファイルが扱う粒度があります。ソフトウェアの規模、ここでは、関連するパッケージや含まれるファイルという観点になりますが、それが増えれば増えるほど、SPDXで管理する項目が増えてしまいます。そのため、場合によっては、一つのSPDXファイルですべてをまかなうのではなく、何らかの纏まりで分けた複数のSPDXファイルを関連付けて管理することが必要になるでしょう。
SBOMの粒度や関連付けは、ソフトウェアとそのSBOMの再利用という観点でも検討に値するでしょう。ここでは、さらに、そうしたSBOMの内容の確からしさが組織に閉じず再利用可能なものであれば、どのようにアーカイブして共有するかなども重要な論点になりそうです。
また、ソフトウェアは、ソースコード形式だけではなく、非ソースコード形式、たとえば、コンパイルされたバイナリで流通する場合があります。この時、コンパイル時の設定によっては、依存するファイルが異なることがあり得ます。SBOMでは、バイナリについて、それがどのようなものとして生成されたのかといった情報を管理することも重要になります。
ビルドする時点でSBOMをどのように生成するか、また、そのSBOMでビルドに関する情報をどのように表現するか、などは、脆弱性管理の観点からも議論が進みそうです。
SBOM管理のワークフローとオートメーション
サプライチェーンにおけるSBOMの透明性と相互運用性のためには、SBOMの作り方が関心事項の一つになります。オープンソースコンプライアンスに関連する商用ソリューションは多くありますし、オープンソースによるツールチェインの取り組みもあります。
今年の9月から12月にかけて、OpenChain Project では、計6回の Automation Case Study が開催されました。ここでは、SBOMの監査やレビューに用いるツールとして OpossumUIの利用例を交えながらコンプライアンスワークフローのオートメーション(自動化)について議論がなされました。
また、上記のツールに限らず Open Compliance Summit 2021 では、OSS Review toolkit (ORT) を用いてオープンソースコンプライアンスのワークフローをどのように設計し運用しているかの事例、ORTとGitLab CIとを連携させる事例、SCAツールの課題、SW360でのSPDX対応のための機能強化、バイナリ分析のためのOSSツールBANGなどが話題になりました。
こうしたSBOM管理の一連のツールの成熟、その利用例としてのワークフローやそのオートメーションに関する共有は、SBOM管理それ自体の透明性と相互運用性の確保に繋がると期待されます。
コンプラアンスワークフローのオートメーションに向けて
課題や知見の共有と議論により、物事の対処にかかるコンセンサスが形成されることがあります。
ここまで、SBOMとして扱う情報やその表現について、また、SBOMを生成するための手順などが、話題になってきたことを見てきました。さて、ISO/IEC 5230 (OpenChain Specification) では、SBOM に関するプロセスにおいて、review と approval の実施を定めています (§3.3 “Open source content review and approval”)。
今後、review や approval について、機械で実施可能なものとしてポリシーや手順が表現でき、さらに、その内容をソフトウェアサプライチェーンのコミュニティでコンセンサスを得ることができれば、さらなるオープンソースコンプライアンスのオートメーションの実現に近づけるかもしれません。
コミュニティが開拓する新たな地平がそこにあるような気がします。
先の Open Compliance Summit Japan 2021 で、次の発表をしました。
"From Compliance, for Collaboration: Open Source Program As an Engine for Creation - Takashi Ninjouji & Yasutaka Shirai, Toshiba Corporation"
そのなかで、オープンソースコンプライアンスは、もっとソフトウェアエンジニアリングに近い形、ざっくりといえば、CI/CDにもっと統合して実現できないか、という思いを述べました。
この図でいえばreviewからapproveのポリシーとルールを表現できないかな、と考えています。
おわりに
SBOMについて、その情報表現から、作成、管理、さらにはワークフローのオートメーションに関するこの一年の話題を振り返りつつ、最後はその先に見たいものを述べました。ソフトウェアを書いて動かして楽しんで！、なことに来年も取り組めればと思ってます。
明日(12/25)は、このAdvent Calendar企画のトリで、遠藤さんの記事になります。お楽しみに！
Summary
This article looks back at the SBOM relating topics in 2021, such as information representation, creation, management, workflow automation, and concludes with what I would like to see beyond that.
ISO/IEC 5230 (OpenChain Specification) specifies review and approval in the SBOM relating process (§3.3 "Open source content review and approval").
How do you think about if policy and procedure for review and approval can be expressed as human-readable and machine-executable, and if the content of policy and procedure can be agreed upon by the software supply chain community, this could be a further achievement in the automation of open source compliance?
There are new horizons to explore with the community, I think.
In the following presentation at the Open Compliance Summit Japan 2021, "From Compliance, for Collaboration: Open Source Program As an Engine for Creation - Takashi Ninjouji & Yasutaka Shirai, Toshiba Corporation," my comment was that the process of open source compliance could be much closer to software engineering, or roughly speaking, more integrated into CI/CD.
I hope it could be to express policies and rules that can be human-readable and machine-executable for the processes such as "review" and "approve" shown in the slide above.