要点: 良いCIは、検証したソースコードと本番で動く成果物が同じであることを証明します。
この記事の用語: 品質ゲート：マージやリリース前に必須とする条件。SBOM：製品に含まれる構成要素一覧。
現場の課題
ビルド成功だけでは、テストのSkip、脆弱ライブラリ、シークレット混入を防げません。権限が強すぎるランナーは、Pull Requestをソフトウェア供給網全体のリスクに変えます。
単純な対策だけでは不十分な理由
GitLabとGitHubは構文が違っても、最小権限、ジョブの分離、一つの変更不能な成果物という原則は同じです。セキュリティ上の検出事項には担当者と期限が必要です。
処理フロー
ソースコード Verify
Format・Lockfile→Quality
Lint・Type・テスト・ビルド→セキュリティ
シークレット・SAST・依存サービス・Image→リリース
SBOM・署名・Provenance
Format・Lockfile→Quality
Lint・Type・テスト・ビルド→セキュリティ
シークレット・SAST・依存サービス・Image→リリース
SBOM・署名・Provenance
アーキテクチャ上の判断
Fail Fast
Format、Verify、Lint、Typeを先に実行します。
ビルド Once Promote
同一ダイジェストをStagingと本番で使います。
Trust Zone分離
PRは読み取り専用、Sign・デプロイはProtected Refと短期アイデンティティだけです。
さらに深く考える
ソースコード Drift検証
Generated ファイルとLockfile後のClean Treeを確認します。
Exceptionを技術的負債管理
担当者、Control、期限を持ち、期限切れでFailします。
実装手順
- 重いジョブの前に、リポジトリ状態、Lockfile、生成ファイルの差分を確認します。
- Lint、型検査、テスト、本番ビルドを明確な合格基準で並列実行します。
- ソースコードと成果物をスキャンし、一度だけ署名した同じダイジェストを全環境へ移します。
コード例: Equivalent Quality Gates
verify: format --check; generated-diff; lockfile-policy
quality: lint; typecheck; unit --coverage; integration
build: production-build; migration-check
security: secret-scan; SAST; dependency-audit; image-scan
release: SBOM; sign(digest); attest(provenance)
deploy: promote(the_same_digest)GitLabはstages・needs、GitHubはjobs・needsを使い、実Commandはリポジトリ Scriptへ置きます。
想定しておく障害
- Untrusted Branchのキャッシュを使います。
- 必須テストをSkipしてExit 0になります。
- デプロイ時Rebuildでダイジェストが変わります。
監視すべきこと
| 指標 | 何が分かるか |
|---|---|
| パイプライン・キュー時間 | Feedback速度です。 |
| ゲート 失敗・不安定な率 | Defectと不安定自動化を分けます。 |
| ダイジェスト・SBOM・署名 Coverage | リリース 検証結果です。 |
設計の検証方法
- Lint、テスト、ビルド、シークレット、脆弱性を意図的に失敗させます。
- Untrusted PRの権限を試験します。
- 本番 ダイジェストから全検証結果を追跡します。
本番導入の進め方
既存パイプラインを測り、ゲートを報告のみで追加してノイズを除きます。短時間の検査、セキュリティポリシー、成果物への署名の順で強制し、その後にキャッシュと並列化で高速化します。
本番前チェックリスト
- Protected Branchは全CheckとReviewを要求します。
- Untrusted PRはシークレットやPrivileged ランナーへ到達しません。
- 失敗ジョブはリリース可能成果物を残しません。
まとめ
CI/CDはレビュー済みソースコードから本番成果物までをつなぐ証跡の連鎖です。