# 2026年のDevOpsパイプラインセキュリティ：DevSecOpsのベストプラクティスと面接質問 > DevSecOpsの重要な手法、CI/CDパイプラインの保護方法、2026年の技術面接で求められるセキュリティに関する知識を解説します。SAST、SCA、OIDCフェデレーション、コンテナセキュリティまで網羅的に紹介します。 - Published: 2026-09-08 - Updated: 2026-09-08 - Author: Anthony Fillion-Maillet - Tags: devops, devsecops, security, cicd, pipeline - Reading time: 12 min --- DevOpsパイプラインのセキュリティは、大規模にソフトウェアをリリースする組織にとって重要な差別化要因となっています。[OWASP Top 10 CI/CDセキュリティリスク](https://owasp.org/www-project-top-10-ci-cd-security-risks/)では、不十分なフロー制御から侵害されたビルド依存関係まで、最新のパイプラインにおける最も危険な脆弱性が特定されています。本ガイドでは、2026年の技術面接で求められるDevSecOpsの必須プラクティスを解説します。 > **シフトレフトセキュリティ** > > DevSecOpsは、ソフトウェアデリバリーライフサイクルのすべての段階でセキュリティチェックを統合します。本番環境前の最終ゲートとしてセキュリティを扱うのではなく、シフトレフトの手法により、修正コストが低く、迅速に出荷できる開発段階で脆弱性を検出します。 ## CI/CDの攻撃対象領域を理解する 最新のCI/CDパイプラインは、ソースコードリポジトリ、ビルドランナー、アーティファクトレジストリ、デプロイメントターゲットにまたがる複雑な攻撃対象領域を持っています。2025年3月のtj-actions/changed-files侵害では、広く使用されているGitHub Actionに悪意のあるコードが注入され、23,000以上のリポジトリからシークレットが漏洩しました。2026年初頭のTanStack攻撃では、有効なSLSA Build Level 3の来歴を持つ170以上の汚染されたnpmパッケージが公開され、攻撃者がビルドプロセスを制御している場合、暗号化された証明でさえバイパスできることが実証されました。 これらのインシデントは、3つの重要な制御ポイントを浮き彫りにしています： - **ソースの完全性**：ブランチ保護ルール、署名付きコミット、必須のコードレビューにより、不正な変更がビルドパイプラインに到達することを防ぎます - **ビルドの分離**：エフェメラルランナー、最小限の権限、アーティファクト検証により、侵害された依存関係の影響範囲を制限します - **シークレットの衛生管理**：短命の認証情報、OIDCフェデレーション、シークレットスキャンにより、攻撃者が狙う静的トークンを排除します 面接官は、典型的なデプロイメントパイプラインにおける信頼境界をトレースするよう候補者に求めることがよくあります。優れた回答は、攻撃者がコードを注入したり認証情報を窃取したりできる各段階をマッピングします。 ## SASTとSCA：脆弱性の早期検出 静的アプリケーションセキュリティテスト（SAST）は、プログラムを実行せずにソースコードのセキュリティ欠陥を分析します。ソフトウェア構成分析（SCA）は、サードパーティの依存関係における既知の脆弱性を特定します。すべてのプルリクエストで両方を実行することで、コードがマージされる前に大多数の一般的なセキュリティ問題を検出できます。 ```yaml # .github/workflows/security.yml name: Security Scan on: pull_request: branches: [main] jobs: sast: runs-on: ubuntu-latest permissions: contents: read security-events: write steps: - uses: actions/checkout@v4 - name: Run CodeQL uses: github/codeql-action/analyze@v3 with: languages: javascript,typescript queries: security-extended sca: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Run Trivy vulnerability scanner uses: aquasecurity/trivy-action@0.28.0 with: scan-type: fs scan-ref: . severity: HIGH,CRITICAL exit-code: 1 ``` 上記のワークフローでは、SASTにCodeQL、SCAにTrivyを実行しています。Trivyで`exit-code: 1`を設定すると、高または重大な脆弱性が検出された場合にビルドが失敗します。GitHub Advanced SecurityとGitLab Ultimateには、それぞれのマージリクエストワークフローと統合された組み込みのSAST機能が含まれています。 ## OIDCフェデレーションによるシークレット管理 CI/CDプラットフォームに保存された長期間有効な認証情報は、パイプライン侵害において最も悪用される攻撃ベクトルです。[GitHub Actions OIDC](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-cloud-providers)は、静的シークレットを実行時にクラウドプロバイダーが発行する短命のトークンに置き換えます。 ```yaml # .github/workflows/deploy.yml name: Deploy to AWS on: push: branches: [main] jobs: deploy: runs-on: ubuntu-latest permissions: id-token: write # OIDCに必要 contents: read steps: - uses: actions/checkout@v4 - name: Configure AWS credentials via OIDC uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole aws-region: us-east-1 # AWS_ACCESS_KEY_IDやAWS_SECRET_ACCESS_KEYはどこにも保存されていない - name: Deploy to ECS run: aws ecs update-service --cluster prod --service api --force-new-deployment ``` AWS IAMロールの信頼ポリシーは、ロールを引き受けることができるリポジトリとブランチを制限します： ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" }, "StringLike": { "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:ref:refs/heads/main" } } } ] } ``` この条件は、特定のリポジトリの`main`ブランチへの認証情報発行を制限します。AzureとGCPは同等のOIDCフェデレーション機能を提供しています。存在しなければならないシークレットについては、[HashiCorp Vault](https://www.vaultproject.io/)やAWS Secrets Managerなどのクラウドネイティブオプションが、一元化されたローテーションとアクセスログを提供します。 ## コンテナセキュリティとSBOM生成 コンテナイメージは、アプリケーションコード以外の依存関係をもたらします。ベースイメージ、システムパッケージ、ビルドツールはすべて潜在的な脆弱性を抱えています。ビルドプロセス中にイメージをスキャンし、ソフトウェア部品表（SBOM）を生成することで、完全な依存関係チェーンの可視性が得られます。 ```yaml # GitLab CI コンテナセキュリティ container_scanning: stage: test image: registry.gitlab.com/gitlab-org/security-products/analyzers/container-scanning:7 variables: CS_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA CS_DOCKERFILE_PATH: Dockerfile script: - /analyzer run artifacts: reports: container_scanning: gl-container-scanning-report.json cyclonedx: gl-sbom.cdx.json ``` CycloneDX形式のSBOMアーティファクトにより、下流の利用者は再ビルドせずに新たに開示された脆弱性をチェックできます。SLSAなどのサプライチェーンセキュリティフレームワークは、ベースライン制御としてSBOM生成を必須としています。 ## ステージング環境での動的アプリケーションセキュリティテスト DASTツールは、静的分析では検出できない脆弱性（認証の欠陥、インジェクション脆弱性、セキュリティの設定ミスなど）について、実行中のアプリケーションをテストします。本番デプロイメント前にステージング環境に対してDASTを実行することで、以前のゲートを通過した問題を検出できます。 ```yaml # .gitlab-ci.yml dast: stage: dast image: registry.gitlab.com/gitlab-org/security-products/analyzers/dast:5 variables: DAST_WEBSITE: https://staging.example.com DAST_AUTH_URL: https://staging.example.com/login DAST_USERNAME: $DAST_USER DAST_PASSWORD: $DAST_PASSWORD DAST_AUTH_VERIFICATION_URL: https://staging.example.com/dashboard script: - /analyze artifacts: reports: dast: gl-dast-report.json rules: - if: $CI_COMMIT_BRANCH == "main" ``` [OWASP ZAP](https://www.zaproxy.org/)は、GitLab Ultimateを持たないチームに無料の代替手段を提供します。認証済みスキャンは、機密性の高い操作が通常存在するログイン壁の背後の機能をテストします。[Kubernetes環境](/technologies/devops/interview-questions/kubernetes-basics)では、APIセキュリティテストがIngressの設定とサービスメッシュポリシーを検証します。 ## Infrastructure as Codeセキュリティスキャン Terraform、Kubernetesマニフェスト、Helmチャートは、攻撃者が標的とするインフラストラクチャを定義します。IaCスキャンは、クラウド環境に到達する前に設定ミスを検出します。 ```yaml # GitHub ActionsでのCheckov IaCスキャン iac-scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Run Checkov uses: bridgecrewio/checkov-action@v12 with: directory: terraform/ framework: terraform soft_fail: false output_format: sarif output_file_path: checkov.sarif - name: Upload SARIF uses: github/codeql-action/upload-sarif@v3 with: sarif_file: checkov.sarif ``` Checkovは、CISやSOC2などのセキュリティベンチマークに対して[Terraform構成](/technologies/devops/interview-questions/terraform-basics)を検証します。SARIF出力は、統一された脆弱性追跡のためにGitHubセキュリティタブと統合されます。[Ansible](/technologies/devops/interview-questions/ansible-configuration)を使用するチームは、セキュリティルールを持つansible-lintを同じパイプラインステージに追加できます。 ## GitHub Actionsサプライチェーン強化 アクションを完全なコミットSHAにピン留めすることで、メンテナーや侵害されたアカウントが既存のタグに悪意のあるバージョンを強制プッシュするタグベースの攻撃を防ぎます。2026年5月のMegalodonキャンペーンでは、6時間の間に数千のリポジトリにわたって5,700以上の悪意のあるコミットがプッシュされました。 ```yaml # タグではなくコミットSHAにピン留め steps: - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2 # @v4や@latestのような可変タグは避ける # 悪い例: uses: actions/checkout@v4 ``` Dependabotは、新しいバージョンがリリースされたときにSHAピン留めされたアクションを更新します。[OWASP DevSecOpsガイドライン](https://github.com/OWASP/DevSecOpsGuideline)は追加の制御を推奨しています： - `permissions:`ブロックを使用してワークフロー権限を必要最小限に制限する - `pull_request_target`トリガーを無効にするか、コラボレーターからのラベル付きPRに制限する - 組織レベルでデフォルトが読み取り専用の`GITHUB_TOKEN`を使用する - デフォルトブランチで必須のステータスチェックとブランチ保護を有効にする ## よくあるDevSecOps面接質問 面接官は技術的な深さと実践的な経験の両方を評価します。これらの質問はDevOpsセキュリティの面接で頻繁に登場します。 **Q: リポジトリへのシークレットのコミットをどのように防ぎますか？** [detect-secrets](https://github.com/Yelp/detect-secrets)やgitleaksなどのツールを使用したpre-commitフックは、コミット前にステージされた変更をスキャンします。GitHub EnterpriseやGitLabのサーバーサイドプッシュルールは、既知のシークレット形式に一致するパターンを含むコミットをブロックします。開発者はローカルフックをバイパスできるため、シークレットスキャンはCIでもバックストップとして実行する必要があります。 **Q: SAST、DAST、SCAの違いを説明してください。** SASTは、SQLインジェクションパターンやハードコードされた認証情報などのバグを見つけるために、実行せずにソースコードを分析します。SCAは、パッケージバージョンをCVEデータベースと照合することで、依存関係の既知の脆弱性を特定します。DASTは、悪意のあるリクエストを送信して応答を観察することで、実行中のアプリケーションをテストします。成熟したパイプラインは3つすべてを実行します：SASTとSCAはすべてのPRで、DASTは本番リリース前のステージングで実行します。 **Q: CI/CDにおける最小権限の原則とは何ですか？** ビルドジョブは、その特定のタスクを完了するために必要な権限のみを持つ必要があります。ステージングにデプロイするジョブは、本番環境の認証情報を必要としません。OIDCフェデレーションは、特定のリポジトリ、ブランチ、ワークフロージョブにスコープされた認証情報を発行することでこれを強制します。[OWASP CI/CD Top 10](https://owasp.org/www-project-top-10-ci-cd-security-risks/)は、過剰な権限を持つ侵害されたジョブが攻撃対象領域を劇的に拡大するため、不適切なIDおよびアクセス管理をトップリスクとしてリストしています。 **Q: コンテナイメージの整合性をどのように検証しますか？** コンテンツ信頼署名（Docker Content Trust、Sigstore cosign）は、イメージが信頼されたパイプラインによってビルドされたことの暗号化検証を提供します。SBOM証明書はイメージ内のコンポーネントを文書化します。Kubernetesのアドミッションコントローラーは、署名されていないイメージや既知の重大な脆弱性を持つイメージを拒否します。レジストリスキャンは、ビルド時間後に現れる脆弱性を検出します。 **Q: CI/CDに対するサプライチェーン攻撃とその防止方法を説明してください。** tj-actions/changed-files攻撃は、広く使用されているGitHub Actionを侵害し、攻撃者が制御するエンドポイントにシークレットを抽出するコードを注入しました。防止策には、タグではなくコミットSHAにアクションをピン留めすること、Dependabotを使用してピン留めされたバージョンを更新すること、組織レベルのポリシーで実行できるアクションを制限すること、予期しないネットワーク接続や認証情報アクセスについてワークフローの実行を監視することが含まれます。 ## 技術面接のためのDevSecOpsロードマップ構築 セキュリティ実装について構造化された思考を示す候補者は際立ちます。実践的なDevSecOpsの展開は、最初に影響が大きく労力の少ない制御を優先します： - シークレットスキャンとブランチ保護を即座に有効にする。両方とも無料で、最も一般的な攻撃ベクトルをブロックします - 最初のスプリント内にプルリクエストチェックにSASTとSCAを追加し、マージ前に脆弱性を検出する - 静的認証情報からOIDCフェデレーションに移行し、CI/CDプラットフォームから最も危険なシークレットを排除する - イメージビルドの一部としてコンテナスキャンとSBOM生成を実装する - Terraform、Kubernetes、クラウド構成のIaCスキャンをデプロイする - 認証や機密データを扱うアプリケーションにDASTを追加する - 本番Kubernetesクラスター用にFalcoまたは同等のランタイム監視を確立する 面接官はトレードオフを認識する候補者を評価します。セキュリティスキャンはパイプラインのレイテンシーを追加します。誤検出はアラート疲労を引き起こします。成熟したDevSecOpsプラクティスは閾値を調整し、補償制御で計算されたリスクを受け入れ、修復までの平均時間を継続的に測定します。 --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/ja/blog/devops/devops-pipeline-security-2026-devsecops-interview