同じデスクトップアプリが、公式リリースページとミラーサイトで配布されているとします。ファイル名とバージョン番号は同じでも、利用者にはまだ確認すべきことがあります。同一のファイルなのか、誰が公開したのか、想定したコードとビルド工程から生成されたのか、自分の端末で実行するのに適しているのか、という問いです。
これらには異なる証拠が必要です。あらゆる検証を「安全認証」と呼ぶと、実際には保証できないことまで期待させ、開発者がリリース工程の空白を見落とす原因にもなります。
チェックサムはファイルの一致を確認する
ダウンロード後にハッシュを計算し、期待する値と比べれば、ファイル内容が一致するかを確認できます。ただし、期待する値自体が信頼できる経路から来ていることが重要です。ファイルと検証値の両方が未確認の同じページにあるなら、一致だけで発行者の身元は証明できません。
逆にハッシュの不一致はファイルの差を示しますが、それだけで悪意は断定できません。異なるビルド、再パッケージ化、誤ったダウンロードでも変化します。検証済みバージョンとして扱うのを止め、配布元、対象プラットフォーム、対応するチェックサムの記録を確認し直すことが適切です。
配布側は、明確なファイル名、バージョン情報、チェックサム一覧を一緒に管理すべきです。利用者が古い記事からハッシュをコピーし、別のプラットフォームや別ビルドのインストーラーと比較するような状態を避けます。
署名では「期待する主体は誰か」を確認する
デジタル署名は署名者と署名対象のデータを結び付けますが、その身元が期待どおりかも判断する必要があります。Sigstore の検証文書が署名だけでなく、関連する身元や発行者の条件を確認するよう求めるのは、この区別のためです。Sigstore 検証文書
したがって「署名は有効」と表示されても、どの発行者やワークフローに対応するか確認します。開発者は、正式リリースに署名できる主体を明示すべきです。数学的に検証できる任意の署名に、自動的に正式版の地位を与えてはいけません。
証明書や署名方式を変更する場合も、確認可能な説明が必要です。出所の分からない証明書をその場で信頼するよう利用者に求めるだけでは、完全な更新手順とは言えません。
ビルドの来歴は配布物と生成工程を結ぶ
GitHub の artifact attestation はビルドの来歴を記録し、成果物とリポジトリやワークフローとの関係の検証を助けます。「このファイルがどう作られたか」の証拠になりますが、実際の成果物と期待する身元の確認は依然として必要です。GitHub の成果物証明文書
SLSA のビルドレベルは、来歴記録の存在、ホスト型プラットフォームが生成する署名付きの来歴、さらに厳しいビルド基盤の保護要件を区別します。レベルを引用する際は適用範囲と根拠を説明し、すべてのソフトウェアリスクを網羅する点数として使わないようにします。SLSA ビルドレベル
| 証拠 | 主に答えられること | 単独では証明できないこと |
|---|---|---|
| チェックサム | 期待するファイル内容を取得したか | 発行者の身元、プログラム動作の安全性 |
| デジタル署名 | 誰がどのデータに署名したか | 署名者が自分の信頼条件を満たすか |
| ビルドの来歴証明 | どのビルド工程から成果物ができたか | すべてのコードと依存関係に問題がないこと |
| 再現可能なビルド | 指定条件で同一成果物を再生成できるか | 脆弱性や不適切な動作がないこと |
これらの証拠は相互に補完できます。開発者は、どの証拠を提供していて、どの確認が別途必要かを利用者に伝えるべきです。
再現可能なビルドには入力と環境の明示が必要
Reproducible Builds プロジェクトは、同じソースコード、ビルド環境、ビルド手順から、指定した成果物をバイト単位で同一に生成できることを再現可能なビルドと定義しています。「自分のパソコンではコンパイルできる」より明確な検証目標です。再現可能なビルドの定義
配布者はツールチェーン、依存関係の固定情報、ビルド引数と成果物の対応を保存することを勧めます。再現可能性をまだ達成していないなら、どこまで再生成できたか正確に記録し、差異を省いて合格と宣言しないことが大切です。
公開リポジトリの範囲も明確にします。中核のソースコードを含む場合もあれば、主にビルドツール、設定、上流で生成されたアプリパッケージを含む場合もあります。利用者が何を検査し再ビルドできるのか分かって初めて、来歴の証拠を適切に評価できます。
利用者が実践できる確認順序
- 検索広告や転送されたリンクだけに頼らず、プロジェクトの正式な入口からリリースリポジトリを確認する。
- リリースノートを読み、OS、プロセッサーのアーキテクチャ、リリースチャネルを確認する。
- ファイルと対応するチェックサムを照合し、署名や来歴証明があれば期待する身元と範囲も検証する。
- 保守状況と既知の制約を確認し、「最新」タグを本番利用への適合と同一視しない。
- 情報が食い違う場合は、バージョンとファイル名を保存し、プロジェクトのサポート窓口で確認する。
この手順は、すべての利用者にビルドエンジニアになることを求めるものではありません。製品側は複雑な証拠を、入手元、対象利用者、検証方法、異常時の問い合わせ先が分かるリリースページに整理できます。
開発者にとっては、一度だけ「検証済み」と表示するより、この情報のつながりを長期間維持する方が価値があります。旧版の撤回、署名の変更、更新失敗の際も、対応する説明が見つかるべきです。
AlphaBiz の公開リポジトリの説明は、ビルドツールと上流で生成されたアプリパッケージを区別しています。この種のデスクトップアプリを論じる際も、検査できる範囲を正確に説明し、公開リポジトリ、完全なソースコード、再現可能なリリースを混同しないようにします。AlphaBiz プロジェクト概要
開発者はリリースの証拠一覧を整えることから、利用者は普段使うアプリのダウンロードファイルを一つ確認することから始められます。リリースページにどのような検証情報が欲しいか、AlphaBiz Discussions で意見を交換しましょう。