Maven/Gradleでビルド結果を署名・検証せよ！成果物の改ざんを防ぐCode Signing実装術
テックリードの君なら、サプライチェーン攻撃の脅威がもはや「対岸の火事」ではないことを痛感しているはずだ。オープンソースの依存関係を狙った改ざん、あるいはローカルビルド環境やCI/CDパイプラインのコンテナが侵害されたとき、悪意あるコードが混入したアーティファクト（JAR/AAR）がMaven Centralや社内リポジトリに流出するリスクは常に潜んでいる。
「うちは閉じた社内ネットワークだから大丈夫」「HTTPSで通信しているから改ざんされない」——そんな神話は今すぐ捨ててくれ。バイナリの正当性を暗号学的に保証する唯一の防衛線が GPG（GNU Privacy Guard）署名 だ。
今回は、Javaエコシステムの2大ビルドツールである Maven と Gradle におけるコードサイニングの完全実装術と、CI/CD環境でのセキュアな秘密鍵運用のベストプラクティスを、実務直結のコードとともに徹底解説する。
—
1. なぜ「署名」が必要なのか？（アーキテクトの視点）
ビルドツールにおける署名（Code Signing）とは、単なる「形式的なお作法」ではない。
公開リポジトリ（Maven Centralなど）に成果物をパブリッシュする際、または社内のセキュアなアーティファクトリポジトリ（Nexus / Artifactory）で依存関係の完全性を担保する際、以下の3点を保証するために必須となる。
1. 改ざん検知（Integrity）: 転送中やストレージ上でJARファイルが書き換えられていないことの証明。
2. 否認防止（Non-repudiation）: 誰が（どの秘密鍵の所有者が）そのビルド成果物をリリースしたのかの証明。
3. 信頼の連鎖（Chain of Trust）: 鍵サーバー（Keyserver）やWeb of Trustを介した開発者アイデンティティの担保。
これらを怠ると、消費する側（エンドユーザーや他のマイクロサービス）でクラックされたバイナリが実行され、システム全体の乗っ取りを許す致命的な脆弱性（RCE等）に直結する。
—
2. Maven環境での実装：`maven-gpg-plugin` の極意
Mavenで署名を行う場合、標準的なデファクトは `maven-gpg-plugin` だ。
だが、デフォルト設定のままでは、開発者のローカル環境にあるGPGエージェントとの対話（パスフレーズ入力を求めるポップアップなど）が必要になり、CI/CDパイプラインで盛大にフリーズする。
CI/CD耐性を持ち、かつ開発者個人のローカルビルドでもシームレスに動作する、実戦投入レベルの `pom.xml` の設定構成例を提示する。
プロファイル分割によるクリーンな設定管理
署名処理は、日常的なローカル開発（`mvn clean install`）のたびに実行されるべきではない。ビルド時間が無駄に伸びるだけでなく、鍵のパスフレーズ入力を何度も求められて開発体験（DX）が劇的に悪化する。そのため、`release` プロファイル として切り離すのが鉄則だ。
Maven実行コマンド
リリースビルドを走らせる際は、以下のようにプロファイルを明示して実行する。
releaseプロファイルを有効化し、テストをスキップせずに検証付きでパッケージング
mvn clean verify -P release
—
3. Gradle環境での実装：`signing` プラグインのスマートな構成
Gradleは宣言的なDSL（Groovy/Kotlin）により、よりエレガントに署名を統合できる。標準の `signing` プラグインを使用し、アーティファクト（JAR、ソース、ドキュメント）を自動的に検知して `.asc` 署名ファイルを生成する。
ここでは、モダンな Kotlin DSL (`build.gradle.kts`) を用いたプロダクションレディな設定を公開する。
plugins {
`java-library`
`maven-publish`
signing
}
group = “com.example”
version = “1.0.0”
java {
withSourcesJar()
withJavadocJar()
}
publishing {
publications {
create
from(components[“java”])
pom {
name.set(“Secure Core Library”)
description.set(“Enterprise grade secure library with digital signature”)
url.set(“https://github.com/example/secure-core-library”)
// ライセンスや開発者情報の記述（省略）
}
}
}
repositories {
maven {
// 例: ローカルステージングディレクトリへの出力
url = layout.buildDirectory.dir(“staging-repo”).get().asFile.toURI()
}
}
}
// 署名プラグインの詳細設定
signing {
// 環境変数から秘密鍵のASCIIアーマーとパスフレーズを取得
// ファイルパスではなく環境変数（文字列）から直接読み込むことでCIのファイル配置の手間を排除
val secretKey: String? = System.getenv(“GPG_PRIVATE_KEY”)
val password: String? = System.getenv(“GPG_PASSPHRASE”)
if (!secretKey.isNullOrBlank() && !password.isNullOrBlank()) {
useInMemoryPgpKeys(secretKey, password)
}
// publicationsで定義した公開物をすべて署名対象に指定
sign(publishing.publications[“mavenJava”])
}
Gradle実行コマンド
Mavenと同様に、署名を含んだパブリッシュ準備を行うには以下のコマンドを叩く。
アーティファクトのビルド、署名の生成、ローカルリポジトリへの出力
./gradlew clean build publishToMavenLocal
—
4. CI/CD環境における秘密鍵管理のベストプラクティス
ここで、多くの開発者が躓く「CI環境での秘密鍵の安全な扱い方」について、プロのアーキテクトとしてのソリューションを提示しよう。
🚨 絶対やってはいけないアンチパターン
- 秘密鍵（`secring.gpg` や private key のテキスト）を Git リポジトリにコミットする（暗号化していても論外）。
- ビルドサーバーのファイルシステムに平文の秘密鍵を直接置く。
🛡️ 模範解答：メモリ内（In-Memory）インジェクション
現代のCI/CDプラットフォーム（GitHub Actions、GitLab CI、CircleCI）では、環境変数 または シークレットストレージ を経由して、ビルドの瞬間にメモリ上に秘密鍵を展開するのがセキュアの極みだ。
1. GPG秘密鍵のエクスポートとBase64エンコード（ローカルでの事前準備）
秘密鍵のエクスポート（armor形式）
gpg –armor –export-secret-keys YOUR_KEY_ID > private-key.asc
クリップボードへコピー（または安全な方法でCIのシークレットに登録）
cat private-key.asc
2. GitHub Actions での実装例 (`.github/workflows/release.yml`)
GitHub Secrets に以下の変数を登録する。
- `GPG_PRIVATE_KEY`: エクスポートした秘密鍵の全テキスト（あるいはBase64文字列）
- `GPG_PASSPHRASE`: 鍵作成時に設定したパスフレーズ
name: Secure Release Build
on:
push:
tags:
- ‘v’
jobs:
publish:
runs-on: ubuntu-latest
steps:
- name: Checkout Code
uses: actions/checkout@v4
- name: Set up JDK 17
uses: actions/setup-java@v4
with:
java-version: ’17’
distribution: ‘temurin’
# Gradleのキャッシュ最適化（開発スピードを落とさないための布石）
- name: Validate Gradle Wrapper
uses: gradle/wrapper-validation-action@v1
# 環境変数にシークレットを注入してビルド＆パブリッシュ実行
- name: Publish with Gradle (Signing Enabled)
env:
GPG_PRIVATE_KEY: ${{ secrets.GPG_PRIVATE_KEY }}
GPG_PASSPHRASE: ${{ secrets.GPG_PASSPHRASE }}
run: |
./gradlew publish –no-daemon
Gradleの設定側で `useInMemoryPgpKeys(secretKey, password)` を使っているため、ファイルを一切ディスクに残さず、メモリ空間だけで安全に署名処理が完結する。
—
5. 署名の検証方法：本当に正しく署名されているか？
コードを書いたら、必ず「本当に改ざん検知が機能するか」「署名が有効か」を検証しなければならない。開発者自身のローカル環境で確認するための実用コマンドを授けよう。
1. 署名ファイルの存在確認
ビルド成果物が出力されるディレクトリ（例: `build/libs/` や `target/`）に、拡張子 `.asc` が付いたファイルが生成されていることを確認する。
- `secure-core-library-1.0.0.jar`
- `secure-core-library-1.0.0.jar.asc` （←これ）
2. GPGコマンドによる検証
手元のマシンに公開鍵がインポートされている状態であれば、以下のコマンド一発で署名の正当性を検証できる。
JARファイルと対応する.ascファイルを同じディレクトリに置き、検証実行
gpg –verify secure-core-library-1.0.0.jar.asc secure-core-library-1.0.0.jar
成功時の出力ログ例:
gpg: Signature made 水 5 12:34:56 202X JST
gpg: using RSA key A1B2C3D4E5F67890
gpg: Good signature from “Example Developer
この “Good signature” の文字を見た瞬間が、エンジニアとして最もアドレナリンが出る瞬間のひとつだ。万が一バイナリが1バイトでも書き換えられていれば、即座に `BAD signature` が返され、ビルドパイプラインを強制終了させることができる。
—
テックリードからの総括
ビルド結果の署名は、最初は「面倒な手続き」に見えるかもしれない。しかし、一度MavenのプロファイルやGradleのプラグインとしてコード化し、CI/CDのシークレット基盤と統合してしまえば、あとは完全に自動化される。
サプライチェーンの安全性を担保することは、モダンな開発組織におけるプロフェッショナリズムの証明だ。明日からのビルドパイプラインに、ぜひこのCode Signingを組み込み、組織全体のセキュリティ水準を一段上のステージへ引き上げてほしい。