「第三者による審査を受けたファームウェア」と聞いたとき、確かめたいのは、どの機器の、どの版が、どこまで調べられたかです。ファームウェアは、サーバーや周辺機器の内部で動き、起動や更新などを支えるソフトウェア。製品名だけが同じでも、審査の対象が同じとは限りません。
OCP APAC Summit 2026では、Tetrel SecurityのRob Wood氏とRickey Wang氏が、S.A.F.E.に沿って機器メーカーが審査を進める手順を説明しました。S.A.F.E.はSecurity Appraisal Framework and Enablementの略で、ファームウェアの第三者審査と、その結果を複数の利用者が参照するための枠組みです。講演資料にはDRAFTの表示があるため、以下では報告の読み方を、OCPの公式文書とも照合して見ていきます。［1］［2］
簡単にまとめると？
- S.A.F.E.の短報SFRは、対象の機器・ファームウェアと、審査範囲や最終的な指摘を結びつける報告です。
- 報告への署名、ファームウェアのハッシュ、審査範囲はそれぞれ役割が異なります。いずれか一つで安全性全体が決まるわけではありません。
- 導入時は、自分が使う版と構成に報告が対応するか、対象外や残る指摘も含めて読みます。
審査結果を、複数の利用者へ渡す
S.A.F.E.の狙いの一つは、同じファームウェアについて顧客ごとに審査を繰り返す負担を減らすことです。機器メーカーは、Security Review Provider（SRP）と呼ばれる審査会社と対象範囲を決めます。SRPが設計やコードを調べ、メーカーが修正し、その内容を再確認した後に報告をまとめる、という流れです。［2］
公開側の中心となるのが、Short-Form Report（SFR）という機械で読める短い報告です。公式の枠組みでは、SRPが暗号学的に署名したSFRをメーカーへ渡し、GitHubへの公開申請はメーカー自身が行います。製品とファームウェアの組み合わせについてS.A.F.E.の承認を示すには、SFRの公開が必要です。審査を依頼した、あるいは報告を受け取ったという段階とは分けて考える必要があります。［2］
図1では、報告を渡す経路と、機器・ファームウェアを納める経路が分かれています。顧客はGitHubからSFRを取得し、納入されたファームウェアとの対応を確かめます。TetrelをSRPの一例として描いたこの図は、製品を受け取ることと、その製品に対応する審査の根拠を受け取ることが別の手順だと示しています。公式文書でも、メーカーが公開時期を管理し、公開を見送る場合はS.A.F.E.の承認を示せないとされています。［1］［2］
署名、ハッシュ、審査範囲を読み分ける
SFRの署名は、その報告の署名者と内容の完全性を確認するためのものです。一方、ファームウェアのハッシュは、対象となるデータから計算した値で、報告がどのファームウェアを指すかを照合する手掛かりになります。署名の確認と、手元のファームウェアが報告の対象と一致するかの確認は、別の作業です。ハッシュが一致すること自体は、脆弱性がないことを意味しません。［2］
さらに確認したいのがScope Document、つまり審査範囲を定めた文書です。S.A.F.E.のScope 1はコードと設計の評価を中心とし、Scope 2はそれに加えて信頼境界や隔離領域などへ踏み込みます。Scope 3では、電圧などに瞬間的な乱れを与える攻撃や、処理中の物理的な情報漏れといった攻撃への耐性を扱います。［3］
この番号を、製品全体に一つ付く安全性の点数と読むのは適切ではありません。公式文書は、同じCPUでも信頼の起点となる部分をScope 3、アプリケーションを動かす部分をScope 2で調べる例を挙げています。どの部品に、どの攻撃を想定した審査を行ったかを、対象と一緒に読むための区分です。［3］
短い報告にも、残る指摘が入る
SFRが伝えるのは、修正と再確認を経た後の最終結果です。公式文書は、審査範囲内でCVSSという脆弱性評価の点数がゼロでない指摘などを、概要とともに含めるよう求めています。したがって、SFRの公開を「すべての問題をなくした」という宣言として読むことはできません。何が残り、どの条件で影響するかも、報告から読み取る内容です。［2］
ただし、公開SFRには攻撃を具体的に実行するための詳細を載せない方針があります。メーカー向けの詳細報告には、調査方法、未完了の範囲や制約、再現手順、改善の提案などが含まれ、通常は秘密保持の対象となります。公開短報だけで調査の全内容が見えるわけではありません。［2］
設定も別に確かめる必要があります。公式文書は、ファームウェアのハッシュを変えずにメーカー側の設定を変更でき、それによって保護が弱まる場合の指摘をSFRへ含めるよう述べています。また、導入時の設定に依存する問題を除外するには、安全な設定が文書の選択肢として存在するだけでなく、実運用で合理的に期待できる必要があります。同じバイナリを使っていても、設定条件まで同じとは限らないためです。［2］
導入する構成との対応を確かめる
報告を手にしたら、まず機器の識別情報とファームウェアの版・ハッシュを、導入するものと照合します。次に、審査対象の部分、想定した攻撃、対象外の範囲を確かめます。そのうえで、残る指摘と、その指摘に関係する設定や運用条件を確認する、という順で読むと対応が整理できます。
たとえば、ある版に対する報告があっても、後から入れた更新版へ、その結果をそのまま移すことはできません。公式の審査範囲文書は、実運用向けのファームウェアの各版を評価の対象としています。S.A.F.E.を読む際に役立つのは、名称だけで判断を終えることではなく、審査された対象と、いま使おうとしている構成を結びつけることです。［3］
参考文献
- Rob Wood／Rickey Wang（Tetrel Security）「Navigating the OCP S.A.F.E. process for vendors」、OCP APAC Summit 2026、15ページ。本文は主に3–5、10、13ページを参照。講演資料／OCP公式掲載ページ。
- OCP Security Workgroup「Security Appraisal Framework and Enablement」、Framework文書（Revision History 2.1、2026年6月）、OCP Report Deliverables／Short-Form Report Guidance。公式文書（2026年10月8日確認）。
- OCP Security Workgroup「Review Scope」、High-level review areas／Scope 1–3。公式文書（2026年10月8日確認）。