ITエンジニア向けQ＆Aサイト「Stack Overflow」を含むStack Exchange社のコミュニティサイトにおいて、AIによる回答を掲載する実験「Answer Assistant」が始まっています。
Stack Overflowはこれまでコミュニティとしての価値を維持するために人間による回答にこだわる姿勢を貫いてきました。
しかしChatGPTに代表される生成AIの登場によって、Stack OverflowのようなQ＆Aサイトに頼らなくとも、プログラミングなどに関する質問の答えが比較的高い精度で容易かつ瞬時に得られるようになりつつあります。
⇧ しかしながら、「AI」の回答って「幻覚（ハルシネーション）」だらけなので、裏付けのための調査で結局のところ時間がかかるので、瞬時に高精度の回答を得られることは稀な気がしますがね...
ソフトウェアのセキュリティの標準についてのザックリしたタイムライン
「ソフトウェア」の「セキュリティ」の「標準」に関して年表にして欲しいと、ChatGPTにお願いしたところ、以下のような回答が返ってきた。
| 年 | 見出し | 事件 | 確立された標準 | 関連する組織 |
|---|---|---|---|---|
| 2005 | ISO/IEC 27001 | - | ISO/IEC 27001（情報セキュリティ管理システム） | ISO/IEC |
| 2010 | SPDXの開始 | - | Software Package Data Exchange（SPDX） | Linux Foundation |
| 2013 | OWASP Top Tenの発表 | - | OWASP Top Ten（ソフトウェアセキュリティ脆弱性トップ10） | OWASP |
| 2015 | SWIDタグ標準化 | - | ISO/IEC 19770-2:2015（SWIDタグ標準） | NIST |
| 2017 | CycloneDXの開始 | Equifaxデータ漏洩事件 | CycloneDX初期ドラフト | OWASP |
| 2020 | 国際標準の確立 | SolarWinds攻撃 | ISO/IEC 5230:2020（オープンソース ライセンス コンプライアンス） | - |
| 2021 | 重要な転換点 | - | • SLSA初期ドラフト • 大統領令14028 • ISO/IEC 5962:2021（SPDX標準化） |
• OpenSSF • 米国政府 |
| 2021 | SBOM標準の確立 | - | SBOM（ソフトウェア部品表）関連標準（7月12日） | 米国政府 |
| 2022 | 防衛分野への展開 | - | DoDの防衛重要サプライ チェーン保護計画 | DoD |
| 2023 | EUの規制強化 | - | NIS2 Directive | EU |
| 2024 | 現状と課題 | XZ-utils攻撃未遂 | SBOMの普及（1日約200件の公開） | - |
| 2025 | 製品責任の拡大 | - | 製品責任指令（PLD）の更新 | EU |
⇧ おそらく、「幻覚（ハルシネーション）」だらけな気がしますが、「GitHub Actions」のドキュメントに出てくる、
- SLSA（Supply-chain Levels for Software Artifacts）
- SBOM（Software Bill Of Materials）
の2つに絞って情報を漁ってみると、「SLSA（Supply-chain Levels for Software Artifacts）」については、
Supply-chain Levels for Software Artifacts
SLSA ("salsa") is Supply-chain Levels for Software Artifacts
SLSA (pronounced "salsa") is a security framework from source to service, giving anyone working with software a common language for increasing levels of software security and supply chain integrity. It’s how you get from safe enough to being as resilient as possible, at any link in the chain.
⇧ 2021年9月が初出になるっぽい。
一方、「SBOM（Software Bill Of Materials）」はというと、
ソフトウェア部品表 (SBOM) は、ソフトウェアアプリケーションのようなソフトウェア成果物を構築するために使用されるコンポーネントの目録を公表する。
法令
NTIAの最小要素は2021年7月12日に公表され、"ソフトウェアのサプライチェーンにおける透明性を高めるためのSBOMの使用事例を説明するとともに、将来の進化のための選択肢を示している"。
最小要素は、データフィールド（各ソフトウェアコンポーネントに関するベースライン情報）、自動化サポート（機械および人間が読み取り可能な形式でSBOMを生成する能力）、およびプラクティスとプロセス（組織がSBOMを生成する方法とタイミング）の3つの大まかなカテゴリで構成されている。
”自動化サポート”要件は、”自動生成”の必要性を規定しており、これは ソフトウェア構成分析 (SCA) ソリューションを使用することで可能となる。
⇧ とあり、Wikipediaの情報が正しいとすると、
| 年度 | 月 | 標準 |
|---|---|---|
| 2021 | 7 | SBOM（Software Bill Of Materials） |
| 2021 | 9 | SLSA（Supply-chain Levels for Software Artifacts） |
⇧ 初出の順番は上記のような形になりますと。
まぁ、法令で定義されてるらしい「SBOM（Software Bill Of Materials）」が確立されてから、「SLSA（Supply-chain Levels for Software Artifacts）」が定義されるというのは妥当な気がしますしな。
GitHub ActionsのドキュメントでSLSAやSBOMが出てくるが関係性が分からないので整理したかったが...
で、「GitHub Actions」の公式のドキュメントによると、
⇧ とあり、全く分らん。
2025年2月19日（水）時点で、「SLSA（Supply-chain Levels for Software Artifacts）」のドキュメントには、
- SLSA Specification 1.1 Draft
- SLSA Specification 1.0
とあるようなのだが、「GitHub Actions」のドキュメントでは「SLSA Specification 1.0」を元に考えられている模様。
「SLSA Specification 1.0」のページを確認してみるのだが、
Levels and tracks
SLSA levels are split into tracks. Each track has its own set of levels that measure a particular aspect of supply chain security. The purpose of tracks is to recognize progress made in one aspect of security without blocking on an unrelated aspect. Tracks also allow the SLSA spec to evolve: we can add more tracks without invalidating previous levels.
⇧ レベルとしては、
- L0
- L1
- L2
- L3
の4つ存在するのだが、「GitHub Actions」のドキュメントで「ソフトウェア部品表 (SBOM) の構成証明」がどのレベルに該当するのかについて説明が無いというね...
「ソフトウェア部品表 (SBOM) の構成証明」については、「アーティファクト構成証明」と同様に「SLSA v1.0 ビルド レベル 2」相当と考えて良いのだろうか...
ネットの情報を漁っていたところ、
⇧ 上記サイト様によりますと、「レベル4」相当に該当するらしい。
なのだが、「レベル4」は、
⇧「SLSA Specification 1.1 Draft」で新たに入ってくるものらしいのよね…
とりあえず、
SLSA and SBOM
SBOM and SLSA are complementary, and following certain SLSA principles can make it easier to generate SBOMs. In particular, a major SLSA principle is the need to generate tamper-proof provenance data—that is, metadata that attests to who performed the release process for an artifact, the materials used in production, and whether the artifact was protected from tampering. Since SBOMs hinge on accuracy, completeness, and trust, having SLSA provenance for an artifact improves the quality and integrity of its SBOM.
⇧ 上記でも、「SBOM（Software Bill Of Materials）」が「SLSA（Supply-chain Levels for Software Artifacts）」のどの「レベル」に該当するかについての説明は無い...
最早「レベル」を設けている意味が無いんよね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
