2026年、ML-DSAコード署名をCI/CDにどう導入する？

結論：隔離した流水線で一連の署名経路を先に検証します

FIPS 204で標準化されたML-DSAでも、CI/CDの各ツールや制品の消費側まで対応しているとは限りません。まず隔離した流水線で鍵管理、署名、検証、消費側の互換性を確かめ、問題がない制品から段階的に有効化してください。ML-DSAがFIPS 204で定義されていることは、NISTのFIPS 204本文で確認できます。

この手順は、ソフトウェア制品の署名を運用するDevSecOps担当者、リリース基盤を保守するエンジニア、コード署名の移行範囲を決めるセキュリティ責任者向けです。
署名を作る工程だけでなく、署名後の制品を受け取る側まで含めて確認できます。
アルゴリズムの解説より、まず導入可否と回帰条件を決めたい場合に役立ちます。

導入前：署名対象と信頼境界を定めます

最初に、何へ署名するのかを固定します。ビルド成果物、更新パッケージ、コンテナイメージなどで、署名の付け方や検証する場所は異なります。署名対象が曖昧なままでは、ビルド後に加工されたファイルを誤って信頼するなど、署名の検証結果と実際に配布する制品が一致しないおそれがあります。

次に、署名端、公開端、消費端の責任範囲を図にします。署名端は鍵へのアクセスを制御する主体、公開端は署名済み制品を配布する主体、消費端は署名を検証して採用を判断する主体です。各境界で、誰が何を確認し、失敗した場合にどこで配布を止めるかを明記してください。

FIPS 204に基づくアルゴリズムの選択と、実際に使う暗号ライブラリー、署名データの形式、クライアントの対応状況は別々に確認します。標準に準拠した実装を選んでも、配布先の検証ツールがその署名形式を読めるとは限りません。後量子暗号への移行計画では、NIST NCCoEの移行情報も参照し、依存関係の棚卸しと移行試験を分けて進めます。

準備段階：鍵と権限を決めます

鍵をどこで生成し、どこに保管し、どの工程が使用できるのかを決めます。鍵の生成方法や保管製品の操作は製品・ライブラリーごとに異なるため、汎用コマンドを流用せず、選定した実装の公式資料に従ってください。たとえば、利用するライブラリーにML-DSAの署名インターフェースがあるかは、署名 API の公式仕様で確認できます。

権限設計では、ビルドを実行するすべてのジョブに署名鍵を渡すのではなく、署名が必要な工程だけに利用権限を限定します。通常のログ、環境変数の表示、デバッグ出力へ秘密情報が混入しないことも確認してください。流水線のシークレットを設定する場合は、公式のシークレット管理資料を読み、利用する CI/CD 環境のアクセス制御とログの扱いに合わせます。

鍵の輪番と失効も、導入前に運用手順として決めておきます。新しい鍵への切り替え後も旧鍵で署名した制品を検証する必要があるのか、漏えいの疑いがある場合はどの配布物を停止するのかを、消費側の管理者と合意してください。

注意：鍵の保管先を変更しただけでは、署名権限が適切に分離されたとは言えません。どのジョブが鍵を呼び出せるか、実行者と変更履歴を追跡できるかまで確かめます。

接続段階：署名をビルド識別情報に結び付けます

署名工程では、署名対象の制品と、その制品を生成したビルドの識別情報を対応付けます。ビルド元の記録を付ける場合は、SLSAのprovenance仕様を参照し、署名の検証だけでなく、どのソースやビルド工程に由来する成果物なのかを追えるようにします。

署名データを制品に添付する方式や、別のエンベロープで運ぶ方式は、採用する形式と消費側の実装に合わせて決めてください。形式の候補を評価する際は、DSSEの仕様・実装資料を確認し、形式がML-DSAを含む実際の署名経路で扱えるかを別途試験します。形式の説明と、特定クライアントでの対応保証は同じではありません。

どの方式でも、署名ステップを通過したという事実だけで公開を許可しないでください。制品の識別情報、署名結果、公開操作の記録を関連付け、署名対象と実際に公開するファイルが同一であることを確認します。

検証段階：署名と制品の受け入れ条件を試します

流水線に署名を組み込んだら、消費側まで届く一連の動きを確かめます。次の項目は、試験用制品と検証環境で一つずつ確認してください。

• [ ] 正規の鍵で署名した制品が、想定する検証ツールで受け入れられる。
• [ ] 署名後に内容を変更した制品が、検証で拒否される。
• [ ] 誤った鍵、対応していない形式、署名の欠落を検出したとき、公開や導入が止まる。
• [ ] 検証に失敗した理由がログで追え、秘密鍵や秘密情報がログに出ない。
• [ ] 配布先で使うクライアント、リポジトリー、更新機構が同じ署名方式を処理できる。

この確認により、ML-DSAによる署名が作れるかだけでなく、署名を検証して制品を採用する経路が成立するか判断できます。とくに旧版クライアントは、新しい署名方式を理解できない場合に検証を失敗させるのか、署名を無視して処理を続けるのかを確かめてください。後者の動作を許容する設計は、署名を必須とする方針と矛盾する可能性があります。

試験段階：回帰条件を満たしてから対象を広げます

まずは影響範囲を限定した制品で試し、運用担当者が失敗を検知して公開を止められることを確認します。旧クライアントが残る、検証形式が揃わない、鍵の失効時に対象制品を特定できない場合は、全体への展開を保留します。旧方式の検証能力を残す場合も、どの制品をどの検証器で受け入れるかを定め、意図しない迂回経路にならないようにします。

ML-DSAへ切り替えた後に旧版クライアントが署名を検証できるかは、アルゴリズム名だけでは決まりません。署名形式、クライアントが依存するライブラリー、更新機構の対応が揃っているか、対象の実環境で確認してください。切り替え前の署名方式を残すなら、併用できると仮定せず、実際の形式と検証ツールで試験する必要があります。

回帰の判断条件

• 試験用クライアントと配布先のクライアントで検証結果が一致するなら、非重要制品から適用範囲を広げます。
• 署名は成功しても消費側が検証できないなら、公開を止め、クライアントか署名形式の対応を確認します。
• 変更済み制品や誤った鍵を拒否できないなら、展開せず、検証経路と失敗時の処理を見直します。
• 旧クライアントの挙動や失効時の回復手順が未確定なら、従来の公開手順を維持し、確認できた範囲だけで再試験します。

運用上の要点：回帰先は「署名検証を省略すること」ではありません。事前に承認した旧手順へ戻し、どの制品をどの検証方式で受け入れるかを追跡できる状態にします。

開発環境の選定：互換性を確認してから実行場所を決めます

署名の成否は、開発環境を用意しただけでは判断できません。採用する暗号ライブラリー、CI/CDの実行環境、制品形式、消費側の検証ツールが揃っている必要があります。手元の開発環境を変える場合も、まず公式資料と対象バージョンのリリース情報を確認し、その組み合わせで署名・検証を再現できるかを試験してください。

チームで開発環境や検証方法を相談する場合は、ZavCloudのヘルプセンターを確認できます。ただし、環境を用意できることはML-DSA対応の保証ではありません。対応状況は、利用するライブラリーとツールの公式資料で個別に確かめる必要があります。

最終的には、鍵へのアクセスを限定できるか、改変制品を確実に拒否できるか、旧クライアントを含む消費側で検証できるかを記録し、条件を満たした対象だけを段階的に広げます。既存の共有実行環境で鍵の権限分離が難しい、macOS依存のビルドを実機に近い環境で確かめたい、試験用の環境を常時維持したくない場合は、購入や既存環境の拡張に加えて一時的なMac利用も比較対象になります。Mac環境を用意しても暗号ライブラリーの対応は別途確認が必要ですが、短期の再現環境を探す場合はZavCloudのMac miniレンタルを確認し、必要な環境条件を照合してから試験計画に組み込んでください。