ci-cd パイプラインは、コードを本番環境に届ける最短ルートであると同時に、攻撃者にとっても最も魅力的なターゲットです。2025 年初頭の GhostAction 攻撃では、広く使用されていた GitHub Action が侵害され、何千ものリポジトリからシークレットが流出しました。Qualys の調査によると、DevSecOps を実装している組織は 68% に達しましたが、技術的複雑さ(41%)、リソース制約(35%)、文化的抵抗(38%)が依然として課題です。Kubo はセキュリティを組み込んだ ci-cd 基盤を提供しており、本記事のプラクティスを標準で適用できます。
Shift-Left: セキュリティを開発の最初から組み込む
DevSecOps の基本原則は 「Shift-Left」、つまりセキュリティチェックをパイプラインの可能な限り早い段階に移動することです。Practical DevSecOps によると、セキュリティの問題は発見が遅いほど修正コストが指数関数的に増大します。
開発環境でのセキュリティ
# pre-commit フックの設定例
repos:
- repo: https:--github.com-gitleaks-gitleaks
rev: v8.18.0
hooks:
- id: gitleaks
name: Detect hardcoded secrets
- repo: https:--github.com-hadolint-hadolint
rev: v2.12.0
hooks:
- id: hadolint-docker
name: Lint Dockerfile
開発者の IDE やコミット前の段階で、シークレットの誤コミットや Dockerfile のベストプラクティス違反を検出します。GitGuardian などのツールは、リポジトリ全体のシークレットスキャンを自動化します。
CI パイプラインの初期段階
# GitHub Actions での Shift-Left セキュリティ
security-checks:
runs-on: ubuntu-latest
steps:
- uses: actions-checkout@v4
- name: SAST - SonarQube Scan
uses: SonarSource/sonarqube-scan-action@master
env:
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
- name: Secrets Detection
uses: gitleaks/gitleaks-action@v2
env:
GITLEAKS_LICENSE: ${{ secrets.GITLEAKS_LICENSE }}
- name: Dependency Check
uses: dependency-check/Dependency-Check_Action@main
with:
path: '.'
format: 'SARIF'
Captain.AI は、セキュリティスキャン結果の分析と優先順位付けを AI で支援し、開発者がアクションすべき問題を明確にします。
自動セキュリティテストの多層防御
ci-cd パイプラインには複数のセキュリティテストレイヤーを組み込み、異なる脅威を異なる段階で検出します。
SAST(静的アプリケーションセキュリティテスト)
ソースコードをコンパイル前に分析し、SQL インジェクション、XSS、バッファオーバーフローなどの脆弱性を検出します。
SCA(ソフトウェア構成分析)
オープンソース依存関係の既知脆弱性を検出します。
- name: SCA Scan
uses: aquasecurity/trivy-action@master
with:
scan-type: 'fs'
scan-ref: '.'
format: 'sarif'
severity: 'CRITICAL,HIGH'
DAST(動的アプリケーションセキュリティテスト)
実行中のアプリケーションに対してテストを実行し、認証バイパスやセッション管理の問題を検出します。
コンテナスキャン
- name: Container Image Scan
uses: aquasecurity/trivy-action@master
with:
image-ref: 'ghcr.io/your-org/app:${{ github.sha }}'
format: 'sarif'
severity: 'CRITICAL,HIGH'
exit-code: '1'
Trivy、Grype、Snyk Container がコンテナイメージの OS レイヤーとアプリケーションレイヤーの脆弱性を検出します。
IaC スキャン
# Kubernetes マニフェストとHelmチャートのスキャン
trivy config ./k8s-manifests/
kubescape scan framework nsa ./helm-charts/
checkov -d ./terraform/
Kubo のデプロイパイプラインには、これらのセキュリティスキャンが標準で統合されています。
サプライチェーンセキュリティと SLSA フレームワーク
ソフトウェアサプライチェーン攻撃が急増する中、SLSA(Supply-chain Levels for Software Artifacts)フレームワークによるビルドの完全性保証が重要になっています。
SLSA レベルの段階的導入
| レベル | 要件 | 目標 |
|---|---|---|
| SLSA 1 | ビルドプロセスの文書化 | 基本的な透明性 |
| SLSA 2 | ホステッドビルドサービス + 来歴(Provenance)生成 | 改ざん検出 |
| SLSA 3 | ハード化されたビルドプラットフォーム + 検証可能な来歴 | 改ざん防止 |
Sigstore によるコンテナ署名
Sigstore は、コンテナイメージの署名と検証のためのオープンインフラです。Cosign、Fulcio、Rekor の 3 コンポーネントで構成されます。
# Cosign でイメージに署名(キーレス署名)
cosign sign --yes ghcr.io/your-org/app@sha256:abc123
# 署名の検証
cosign verify \
--certificate-oidc-issuer https://token.actions.githubusercontent.com \
--certificate-identity-regexp "https://github.com/your-org/" \
ghcr.io/your-org/app@sha256:abc123
SBOM(ソフトウェア部品表)の生成
- name: Generate SBOM
uses: anchore/sbom-action@v0
with:
image: ghcr.io/your-org/app:${{ github.sha }}
format: spdx-json
output-file: sbom.spdx.json
- name: Attest SBOM
uses: actions/attest-sbom@v1
with:
subject-name: ghcr.io/your-org/app
subject-digest: sha256:abc123
sbom-path: sbom.spdx.json
GitHub のブログによると、GitHub Actions と Sigstore を組み合わせることで SLSA Level 2 は数時間で達成可能、Level 3 も数週間で実装できます。
Policy as Code とガードレール
セキュリティポリシーをコードとして定義し、パイプライン全体で自動適用します。
OPA/Gatekeeper によるアドミッションコントロール
# 特権コンテナの禁止ポリシー
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPPrivilegedContainer
metadata:
name: deny-privileged
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Pod"]
parameters:
exemptImages:
- "istio-proxyv2:*"
Kyverno によるポリシー適用
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-signed-images
spec:
validationFailureAction: Enforce
rules:
- name: verify-signature
match:
any:
- resources:
kinds:
- Pod
verifyImages:
- imageReferences:
- "ghcr.io-your-org-*"
attestors:
- entries:
- keyless:
subject: "https://github.com/your-org/*"
issuer: "https://token.actions.githubusercontent.com"
Kyverno と OPA Gatekeeper を Kubernetes クラスタに導入し、署名されていないイメージや特権コンテナのデプロイをブロックします。
ベースラインポリシーの設定
Wiz のガイドが推奨するように、明確に許容できないリスク(積極的に悪用されている脆弱性、署名なしイメージなど)をブロックするベースラインポリシーを設定し、開発速度を過度に制約しないバランスが重要です。
ランタイム監視とフィードバックループ
デプロイ後のセキュリティも継続的に監視します。
ランタイムドリフト検出
# Falco によるランタイムセキュリティ監視
- rule: Unexpected Network Connection
desc: Detect network connections to unexpected destinations
condition: >
outbound and not (fd.sip in (allowed_outbound_destinations))
output: >
Unexpected outbound connection
(command=%proc.cmdline connection=%fd.name user=%user.name)
priority: WARNING
Falco はKubernetes のランタイムセキュリティ監視ツールとして、不正なプロセス実行、ネットワーク接続、ファイルアクセスをリアルタイムで検出します。
フィードバックループの構築
ランタイムで検出された問題を ci-cd の改善にフィードバックする循環を構築します。
- 検出: Falco がランタイム異常を検出
- 通知: Slack/PagerDuty にアラート送信
- 分析: 根本原因をパイプラインの欠陥と特定
- 修正: ポリシーやスキャンルールを更新
- 検証: 次回デプロイで修正を確認
Captain.AI は、このフィードバックループを AI で高速化し、検出から修正提案までを自動化します。
コンプライアンスと監査
自動化された監査証跡
ci-cd パイプラインの各ステップが自動的に監査証跡を生成し、主要なコンプライアンスフレームワーク(SOC 2、ISO 27001、NIST、PCI DSS)への対応を簡素化します。
- name: Generate Attestation
uses: actions/attest-build-provenance@v1
with:
subject-name: ghcr.io/your-org/app
subject-digest: sha256:abc123
SLSA の来歴情報、Sigstore の署名ログ(Rekor)、SBOM がコンプライアンスの証拠として機能します。
まとめ: Kubo でセキュアな ci-cd を実現する
ci-cd パイプラインのセキュリティは、Shift-Left、多層テスト、サプライチェーン保護、Policy as Code、ランタイム監視の 5 層で構成されます。すべてを一度に導入する必要はありません。まず SAST とコンテナスキャンから始め、段階的に成熟度を高めていくアプローチが現実的です。
Kubo はセキュリティを組み込んだ ci-cd 基盤を提供しており、コンテナスキャン、ポリシー適用、署名検証が標準で統合されています。Captain.AI の AI セキュリティアシスタントが脆弱性の優先順位付けと修正提案を自動化し、開発速度を落とさないセキュリティ運用を実現します。セキュアな ci-cd パイプラインを構築したい方は、ぜひお問い合わせください。