解決策
2010年までに、ソフトウェアを出荷するあらゆる企業はライセンスとコンポーネントを追跡しなければならなくなっていたが、ツールやチームごとに表記が異なっていた——「Apache 2」「ASL 2.0」「Apache-2.0」——ため、コンプライアンスデータを組織間でやり取りできなかった。Linux FoundationのSPDXプロジェクトはこの問題を識別子の層で解決した。すなわち、パッケージのコンポーネントとメタデータのための標準データ形式、およびライセンスごとに一つの安定した短いIDを持つ正規のライセンス一覧である。
IDが安定しており機械可読であったため、スキャナ、監査者、サプライヤは翻訳なしにソフトウェア部品表を交換できた。SPDXは事実上のSBOMフォーマットとなり、世界のソフトウェアサプライチェーンにおいてその役割を10年間担った。
2021年8月24日、仕様はISO/IEC JTC 1を通じてISO/IEC 5962:2021として公表された。Linux Foundationはこの節目を「事実上の業界標準から正式なISO/IEC JTC 1標準への移行」と位置づけ、SPDXをサプライチェーン全体にわたるソフトウェアのセキュリティと完全性に関する国際的な要件に向けたものとした。
達成したこと
ライセンスごとに一つの正規の短いID、機械可読
うまくいった理由
自動化されたコンプライアンスを実際に壊していたのは、法的な争いではなく、曖昧なライセンス表記であった。
安定した短いIDにより、どの二つのツールも人手による確認なしにライセンスについて合意できた。
事実上のSBOMフォーマットとしての10年間は、ISOの刻印が実践を発明したのではなく追認したことを意味した。
コンポーネントとメタデータの形式はライセンスを超えてセキュリティやサプライチェーンの用途に供され、支持層を広げた。
応用できること
コンプライアンスが失敗するのは意図ではなく曖昧さのためである。法的文言ではなく識別子を標準化することで、ツールは自動的に合意できるようになり、それがチェックリストを業界のフォーマットへと変える。
その後
ISO/IEC 5962:2021により、SPDXはソフトウェア部品表の国際的に認められたオープン標準となった。ちょうどその頃、各国政府が調達にSBOMを要求し始めていた。仕様はLinux Foundationの下で自由に利用できるISO標準として進化を続けている。
出典をたどる
出典
- SPDX Becomes ISO/IEC 5962:2021 Recognized Standard for Software Security LinuxSecurity · linuxsecurity.com ·
- ISO/IEC 5962:2021 Information technology — SPDX Specification V2.2.1 International Organization for Standardization · iso.org