要約

  • OSPS Baselineはプロジェクトによる自己表明を認め、適合を特定の版、成熟度レベル、評価日を持つ時点情報として説明している。
  • 実用的な表明は対象範囲、版、レベル、日付、表明者、各コントロールの証拠、例外、再確認条件を結び、認証や個別リリースの安全保証へ拡張しない。

分析

ソフトウェア一覧に緑色の欄があり、「OSPS compliant」とだけ書かれている。その欄は判断済みに見える。だが、どの版を使ったのか、どのレベルなのか、いつ確認したのか、何を対象にしたのかが分からない。主リポジトリの話か、ビルド基盤や配布物まで含むのかも不明だ。

OSPS Baselineの一次資料は、この省略を認めていない。公式索引は v2026.08.28 を新しい適合作業に使う現行版とし、旧版を履歴参照として残し、開発中の版を別に置く。FAQはプロジェクトが自己表明できるとする一方、適合を「ある時点の状態」と呼び、日付、版、レベルを明示する例を示す。

同じコントロール番号でも履歴は一つではない

保守手順は YYYY-MM-DD 形式の版を使う。意味が大きく変わるコントロールには新しい識別子を与えるが、レベルの移動を含む小さな変更では識別子を維持できる。したがって、コントロール番号だけを保存しても、過去に評価した義務を完全には復元できない。版への固定参照が欠かせない。

レベルは適用集合を決める。2026.08.28版では、Level 1はコードの有無や利用者数を問わないプロジェクト、Level 2は少なくとも二人の保守者と少数の継続利用者を持つコードプロジェクト、Level 3は多数の継続利用者を持つコードプロジェクト向けである。レベルを省いた「Baseline適合」は、何を満たしたのかをぼかす。

日付は観測の寿命を示す。管理者が交代し、ブランチ規則が変わり、配布先やセキュリティ窓口が移る。あるリリースの署名付きマニフェストは次のリリースまで自動的に覆わない。古い確認結果を現在保証として流通させないために、時点が必要になる。

さらに対象範囲を記録する。プロジェクト名は、主リポジトリ、サブプロジェクト、ウェブサイト、パッケージレジストリ、CI/CD、複数の保守系列を包み得る。Baselineの文は、プロジェクト、権威あるリポジトリ、バージョン管理システム、パイプライン、公式リリースを区別している。証拠もその主語に対応させなければならない。

自己表明と第三者確認を混ぜない

自己表明は独立監査ではない。それでも、公開スキャナーが読めない権限設定を保守者が説明できる点に価値がある。FAQも、公開観測できるコントロールと特権設定に関わるものを分け、下流利用者が表明を受け入れるか、別の確認を設けるかを選べるとしている。

そこで必要なのは、表明者と証拠境界の明示だ。方針文書、貢献手順、変更履歴、リリースマニフェストは公開できる。権限画面は、財団や顧客が限定条件で確認することもある。「確認済み」と書くなら、誰が、どの方法で、何を、いつ確認したかを残す。公開URLがないことを、自動的な合格にも不合格にもしてはならない。

外部フレームワークへの対応表にも限界がある。2026.08.28版は、対応関係を参考情報とし、完全一致を保証せず、一方の進捗が他方の進捗を生む機能的接続でもないと説明する。FAQも、対応表は他のカタログへの適合を主張せず、監査や認証の代替ではないとする。OSPSの一行からISO、NIST、法規制の合格を生成することはできない。

表示は短く、記録は欠かさない

表明記録には、正式なプロジェクト名、対象リポジトリとサブプロジェクト、対象リリース、OSPS版とレベル、評価日、表明者と権限、適用コントロール、各証拠と観測時刻、非公開証拠の区分、例外と非適用理由、再評価の期限または変更条件を置く。

これは無脆弱性を約束せず、依存採用を決めず、バイナリを認証せず、配備結果を予言しない。その代わり、何をどの文章に照らし、どの表面について、どの時点で述べたのかを再確認できる。

基準の保守者、プロジェクトの表明者、証拠の確認者、製品リスクの決定者は別々である。共通語彙は彼らを接続するが、権限を統合しない。

緑の欄は「OSPS v2026.08.28、Level 2、2026-09-07評価」というリンクに変えればよい。短い表示の背後に完全な記録があれば、省略は隠蔽ではなく表示形式になる。

情報源

  1. OSPS Baselineの現行版索引
  2. OSPS Baseline 2026.08.28版
  3. OSPS Baseline FAQ
  4. OSPS Baselineの保守手順
  5. OSPS Baselineプロジェクトのガバナンス