Paper Files / DevSecOps
2026年版DevSecOpsの実装論：ソフトウェア供給網攻撃、AI支援開発、eBPF観測を前提とした継続的セキュアデリバリの設計・評価
DevSecOpsは、開発・運用・セキュリティの境界を可視化しつつ、ソフトウェア供給網全体にセキュリティ制御を組み込む実践体系として、2026年時点で成熟段階に入った。本研究は、クラウドネイティブ、コンテナ、IaC、SBOM、SLSA、ポリシー・アズ・コード、eBPF観測、AI支援開発という2026年の現実的な環境を前提に、DevSecOpsを「パイプラインの安全化」ではなく「継続的に検証可能なリスク制御システム」として再定式化する。まず、現代的脅威として、依存関係汚染、CI/CD資格情報窃取、署名鍵の不正利用、イメージ汚染、シークレット漏えい、LLMによる脆弱コード生成、プロンプト注入、コードレビュー回避、観測回避を含む攻撃面を整理する。次に、脅威モデルを、資産・信頼境界・攻撃経路・検出可能性・復旧可能性の関係で形式化し、リスクを $R = P(A)\times I(A)\times (1-D(A))$ の形で扱う。提案手法は、事前段階の設計レビュー、コミット時SAST/秘密情報検査、ビルド時SBOM生成と成果物署名、デプロイ時ポリシー検証、実行時eBPF観測と異常検知、事後のフィードバック学習を一貫した制御ループとして統合する。実装では、GitHub Actions、GitLab CI、Tekton、Trivy、Syft、Grype、Semgrep、Open Policy Agent、cosign、in-toto、Falco、Cilium Tetragon、Prometheus、OpenTelemetryを組み合わせ、Kubernetesとコンテナレジストリに接続する。評価では、模擬マイクロサービス環境で誤検知率、検出遅延、ビルド増分時間、ポリシー違反阻止率を測定し、攻撃シナリオ別に従来CI/CDとの差分を示す。その結果、提案方式は供給網攻撃の阻止と運用継続性の両立に有効であり、特にシークレット漏えいと未署名成果物の流通を大幅に抑制した。最後に、AIガバナンス、ポスト量子暗号移行、SRE連携、ソフトウェア部品表の品質保証を含む今後の課題を示す。
1. Introduction
DevSecOpsは、2026年の実務において、単なる「CI/CDにセキュリティツールを足す」発想を超えた、組織全体の供給網統制モデルとして理解される必要がある。クラウドネイティブ化の進展、マイクロサービスの常態化、IaCの普及、そして開発現場へのAI支援コーディングの浸透により、脅威はもはや本番環境の脆弱性に限定されない。攻撃者は、ソースコード、依存パッケージ、ビルドパイプライン、署名鍵、コンテナレジストリ、デプロイ権限、監視系テレメトリを連結した「供給網のどこか一箇所」を突破すれば、信頼の連鎖を崩せることを理解している。SolarWinds事件やCodecov侵害、3CXサプライチェーン攻撃の教訓は、2026年になっても消えていない。むしろ、AI生成コードや自動化の拡大により、攻撃対象は増大し、レビューの盲点も広がっている（NIST, 2022; CISA, 2023）。
本研究が扱うDevSecOpsは、既存のSAST、DAST、SCA、IaCスキャン、秘密情報検査を列挙するものではない。重要なのは、それらを相互依存した制御ループとして構成し、リスクを持続的に観測・制御・再学習する仕組みとして設計することである。DevSecOpsの失敗は、多くの場合、ツール導入不足ではなく、組織の意思決定関数にセキュリティ制約が埋め込まれていないことに起因する。たとえば、開発速度を最大化する指標だけが評価されると、脆弱な依存関係の固定化、セキュリティ例外の常態化、レビューの形骸化が起きる。これに対し、成熟したDevSecOpsは、ビルド成功率やデプロイ頻度だけでなく、ポリシー違反率、未修正高リスク脆弱性の滞留時間、署名付き成果物比率、機密情報検出件数、実行時異常検知の平均遅延などをKPIとして扱う必要がある。
2026年の特筆点は、AI/MLを悪用した攻撃と防御の両方が実務に入り込んでいることである。攻撃者は、生成AIを用いた高精度なフィッシング、自然なコミットメッセージ生成、レビュー回避コードの埋め込み、プロンプト注入を通じた開発支援ツールの誤誘導を行う。一方、防御側も、LLMを使った脆弱性説明、ルール補完、ポリシー生成、アラート要約の自動化を進めている。したがって、DevSecOpsは単にコードを静的に評価する枠組みではなく、人間・ツール・モデル・パイプラインの相互作用を含むサイバー・サイバネティック制御系として捉えなければならない。ここで重要なのは、生成AIの利用を禁止することではなく、出力の真正性、依存性、責任境界、監査証跡を明確化することである（OWASP, 2024; NIST, 2024）。
また、2026年の防御実務では、eBPFに基づく観測が重要性を増している。コンテナ/クラウド環境では、従来のエージェント型EDRがノイズや性能の制約に直面しやすい一方、eBPFはカーネルレベルのイベント観測により、プロセス起動、ネットワーク接続、ファイルアクセス、権限昇格、システムコール列を低オーバーヘッドで取得できる。DevSecOpsにおいてeBPFは、ビルド時の静的検査だけでは取り切れない実行時逸脱を補完する基盤であり、特に「署名された正常成果物が後から悪性化する」ケースや、「コンテナ設定ミスが本番で顕在化する」ケースの検知に有効である（Cilium, 2024; Falco, 2024）。
本論文の目的は三つである。第一に、2026年時点でのDevSecOpsの攻撃面を整理し、実務で遭遇する典型的な侵害経路を脅威モデルとして明示する。第二に、その脅威モデルに対して、設計・実装・運用を一体化した方法論を提案する。第三に、模擬環境を用いて提案方式の有効性を定量評価し、実運用での導入障壁と限界を議論する。これにより、DevSecOpsを「ツール群の総称」ではなく、ソフトウェア供給網の耐攻撃性を測定可能な形で高める工学的方法として位置付ける。
2. Background and Related Work
DevSecOpsの概念的基盤は、DevOpsの自動化原則と、セキュリティ・バイ・デザインの実践を統合するところにある。2010年代後半までは、セキュリティはしばしば開発パイプラインの末尾に追加され、リリース前のゲートとして機能していた。しかし、これでは脆弱性の早期発見には寄与しても、依存関係の汚染、CI/CD権限の悪用、ビルド環境の侵害、秘密情報の流出など、供給網全体のリスクに対処できないことが明らかになった。NISTのSSDFは、安全な開発慣行を組織プロセスとして整理し、設計、実装、検証、運用に跨る統制を求めている（NIST, 2022）。同様に、CISAのSecure by Design原則は、初期設定の安全性、権限最小化、監査可能性、更新容易性を重視する（CISA, 2023）。
ソフトウェア供給網の問題は、SBOMの普及によって一定の可視化が進んだ。CycloneDXとSPDXは、依存関係、ライセンス、コンポーネントの識別を標準化し、脆弱性管理とコンプライアンスを支援する。だが、SBOMは「何が含まれているか」を示すに過ぎず、「どのように作られたか」を保証しない。そのため、SLSAやin-totoのような来歴保証、ならびに成果物署名の仕組みが重要になる。SLSAはビルドプロvenanceの信頼レベルを段階化し、ソースから成果物への変換が改ざんされていないことを示す枠組みである（SLSA, 2024）。in-totoは、サプライチェーンの各工程を暗号学的に記述し、実行された操作の完全性を検証する（in-toto, 2024）。2026年のDevSecOpsでは、SBOM、provenance、署名が三位一体で扱われるべきである。
ツール群としては、静的解析のSemgrep、CodeQL、SonarQube、SCAのTrivy、Grype、Dependency-Check、秘密情報検査のgitleaks、git-secrets、CIのGitHub Actions、GitLab CI/CD、Tekton、Argo CD、デプロイ前ポリシーのOPA GatekeeperやKyverno、サインのcosign、観測のFalcoやCilium Tetragon、メトリクスのPrometheusとOpenTelemetryが実務で広く使われている。これらは互いに補完関係にあり、単独では十分ではない。たとえば、Semgrepはコードパターンの検出に強いが、バイナリや実行時挙動は見えない。TrivyはコンテナやIaCの弱点を洗い出すが、権限昇格や横展開の挙動は観測できない。Falcoは実行時検知に優れるが、ビルド工程の不正は見落とす。したがって、DevSecOpsの設計は、各ツールの検査対象と責務境界を明示し、冗長性と補完性を持つように組む必要がある。
研究面では、DevSecOpsはしばしば成熟モデルやフレームワークとして論じられてきたが、2026年の実務に即した定量評価はまだ限定的である。多くの報告は、ツール導入の一覧やベストプラクティスに留まり、誤検知率、検出遅延、パイプライン時間増分、開発者体験への影響を統合的に扱っていない。また、AI支援開発の拡大に対するセキュリティ統制は未成熟であり、LLMが提案したコードに潜む脆弱性、機密の学習・再現リスク、プロンプト注入への耐性などをDevSecOpsに織り込んだ研究は少ない（OWASP, 2024; MITRE, 2024）。
表1に、主要なDevSecOps関連技術の役割を整理する。これにより、各要素がどの工程をカバーするかを可視化できる。
| 技術/ツール | 主目的 | 検査対象 | 強み | 限界 |
|---|---|---|---|---|
| Semgrep | SAST | ソースコード | 高速、ルール拡張が容易 | 実行時は不可視 |
| Trivy | SCA/IaC/コンテナ | 依存関係、イメージ、設定 | 幅広い対象を一括検査 | 文脈依存の判定が弱い |
| Syft | SBOM生成 | 依存・成果物 | SPDX/CycloneDX対応 | 脆弱性検出はしない |
| cosign | 署名/検証 | 成果物 | OCI連携、鍵管理の柔軟性 | 鍵運用が難しい |
| OPA/Kyverno | ポリシー制御 | K8s/IaC | 宣言的で監査容易 | 複雑な例外処理に弱い |
| Falco/Tetragon | 実行時検知 | syscall/挙動 | 低レベル観測が可能 | ノイズ削減が課題 |
3. Threat Model and Problem Formalization
DevSecOpsにおける脅威モデルは、単に「攻撃者がコードを改ざんする」ことだけを想定しては不十分である。2026年の実務では、攻撃者は開発組織の信頼チェーンを狙い、ソース管理、ビルドインフラ、依存リポジトリ、秘密情報、コンテナレジストリ、デプロイ制御、観測基盤のいずれかを侵害する。したがって、保護対象は成果物そのものではなく、成果物が信頼されるに至る過程である。これを形式化するため、本研究では資産集合 $A$、攻撃行為集合 $X$、防御制御集合 $C$ を定義する。資産には、$a_1$=ソースコード、$a_2$=依存関係、$a_3$=ビルド環境、$a_4$=秘密情報、$a_5$=署名鍵、$a_6$=成果物、$a_7$=実行時テレメトリが含まれる。
各攻撃 $x \in X$ は、発生確率 $P(x)$、被害影響 $I(x)$、検知可能性 $D(x)$ を持つとする。リスクは単純化して、 $$ R(x)=P(x)\times I(x)\times (1-D(x)) $$ で与える。ここで $D(x)$ は0から1の範囲で、1に近いほど検知しやすい。制御集合 $C$ は、ある攻撃に対する検知・阻止・復旧の期待値を改善する。すなわち、$C$ の導入後リスクは $R’(x)=R(x)\cdot \alpha_x$ と表せ、$\alpha_x \in [0,1]$ は制御効果係数である。DevSecOpsの設計問題は、予算や遅延制約の下で $\sum_x R’(x)$ を最小化する制御集合 $C$ を選ぶ最適化として表現できる。
攻撃者モデルは三層に分ける。第一に、外部攻撃者であり、公開リポジトリ、CIログ、Issue、パッケージレジストリ、公開コンテナから侵入口を探す。第二に、サプライチェーン攻撃者であり、正規の開発者アカウントや依存関係のメンテナ権限を悪用する。第三に、内部脅威であり、正当なアクセスを持ちながら権限濫用や不注意により情報漏えいを引き起こす。AI支援開発の普及により、第四の層としてモデル依存攻撃を加える必要がある。これは、コーディング支援LLMやレビュー補助LLMに対して、プロンプト注入や文脈汚染を行い、不正な提案や誤った安全判断を誘導するものである。
表2に、代表的な脅威と典型的な防御制御を整理する。
| 脅威 | 侵害対象 | 典型手口 | 主な防御 |
|---|---|---|---|
| 依存関係汚染 | パッケージ/レジストリ | タイポスクワッティング、メンテナ乗っ取り | 署名検証、固定バージョン、内部ミラー |
| CI/CD侵害 | パイプライン | トークン窃取、ランナー悪用 | 最小権限、短寿命資格情報、隔離ランナー |
| シークレット漏えい | リポジトリ/ログ | 誤コミット、ビルド出力 | gitleaks、マスキング、Vault |
| 成果物改ざん | コンテナ/バイナリ | ビルド注入、レジストリ汚染 | cosign、provenance、再現性ビルド |
| 実行時逸脱 | Pod/ホスト | 権限昇格、横展開 | eBPF監視、OPA、Pod Security |
| LLM悪用 | 開発支援 | プロンプト注入、コード毒入れ | 入力サニタイズ、出力検証、監査 |
本研究では、セキュリティ目的関数を単一の「阻止率」ではなく、検出遅延 $T_d$、修復時間 $T_r$、パイプライン遅延 $\Delta T_p$ を含む多目的最適化として扱う。実務では、セキュリティが高くても開発効率を破壊すれば継続できないため、目的関数は $$ J = \lambda_1 \sum_x R’(x) + \lambda_2 T_d + \lambda_3 T_r + \lambda_4 \Delta T_p $$ と定義できる。$\lambda_i$ は組織のリスク許容度とSLOに応じて設定される。これにより、DevSecOpsは「全件ブロック」ではなく、リスクに応じた漸進的制御として設計可能になる。
4. Proposed Methodology
提案手法は、DevSecOpsを六段階の制御ループとして統合する。第一段階は設計時制御であり、脅威モデリング、データ分類、依存関係方針、例外承認フローを定義する。第二段階はコミット時制御であり、pre-commitフック、SAST、秘密情報検査、コード所有者ルールを適用する。第三段階はビルド時制御であり、再現可能なビルド、SBOM生成、成果物署名、provenance記録を行う。第四段階はデプロイ時制御であり、OPA/Kyvernoによりポリシー適合を判定する。第五段階は実行時制御であり、eBPFベースの観測と異常検知で逸脱を捕捉する。第六段階は学習・改善であり、検知結果をルール更新、例外見直し、トレーニングデータ整備に還元する。
この方法論の核心は、各段階を独立最適化せず、同一の証跡IDで連結することである。すなわち、コミット、ビルド、署名、デプロイ、実行時イベントを一貫したトレーサビリティで結び、ある成果物がどのコードから、どの依存関係から、どの環境で生成されたかを追跡できるようにする。これにより、インシデント発生時に影響範囲を限定でき、ロールバックや再ビルドの判断が迅速になる。
表3に、各段階での統制と主な観測データを示す。
| 段階 | 統制 | 観測データ | 代表ツール |
|---|---|---|---|
| 設計時 | 脅威分析、データ分類 | ADR、リスク台帳 | STRIDE、PASTA |
| コミット時 | SAST、秘密情報検査 | 差分、フック結果 | Semgrep、gitleaks |
| ビルド時 | SBOM、署名、provenance | 依存関係、ビルドログ | Syft、cosign、in-toto |
| デプロイ時 | ポリシー検証 | マニフェスト、Admission結果 | OPA、Kyverno |
| 実行時 | 挙動監視 | syscall、ネットワーク、FS | Falco、Tetragon |
| 改善時 | フィードバック学習 | アラート、誤検知 | SIEM、Prometheus |
実装上、提案手法は「阻止」「検知」「復旧」の三層防御を採る。阻止は、未署名成果物やポリシー違反マニフェストを入れないこと。検知は、署名済みでも不審な挙動を検出すること。復旧は、検知後に再現可能な手順で安全な既知状態へ戻すこと。とくに復旧では、GitOpsを使って宣言的に状態を管理し、悪性変更が確認された場合は、信頼済みコミットに対して自動ロールバックを行う。これにより、手作業の復旧に伴う人的ミスを減らせる。
5. Implementation
実装は、GitHub/GitLabをソース管理、TektonまたはGitHub ActionsをCI、HarborまたはECR/GCRをレジストリ、Kubernetesを実行基盤とする標準的なクラウドネイティブ環境を前提にした。秘密情報はVaultまたはクラウドKMSで管理し、短寿命のOIDCトークンを用いてCIランナーに認可を与える。ビルドでは、マルチステージDockerfileを採用し、依存関係の固定と非root実行を徹底する。SBOMはSyftで生成し、OCIアーティファクトとしてレジストリに保存する。署名はcosignで行い、provenanceはin-toto/SLSA形式で添付する。
以下はGitHub Actionsにおける最小構成の例である。SAST、SCA、SBOM、署名を一連のステップとして並べ、失敗時にはデプロイを停止する。
name: secure-build
on:
push:
branches: [ "main" ]
jobs:
build-scan-sign:
runs-on: ubuntu-latest
permissions:
id-token: write
contents: read
packages: write
steps:
- uses: actions/checkout@v4
- name: Run Semgrep
run: semgrep scan --config p/owasp-top-ten --error
- name: Run Trivy filesystem scan
run: trivy fs --severity HIGH,CRITICAL --exit-code 1 .
- name: Generate SBOM
run: syft . -o spdx-json=sbom.spdx.json
- name: Build image
run: docker build -t ghcr.io/org/app:${{ github.sha }} .
- name: Push image
run: docker push ghcr.io/org/app:${{ github.sha }}
- name: Sign image
env:
COSIGN_EXPERIMENTAL: "true"
run: cosign sign --yes ghcr.io/org/app:${{ github.sha }}
Kubernetes側では、OPA GatekeeperまたはKyvernoで「未署名イメージ禁止」「root実行禁止」「latestタグ禁止」「高特権Capabilities禁止」を強制する。以下はKyvernoの簡略例である。
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-signed-images
spec:
validationFailureAction: Enforce
rules:
- name: verify-signature
match:
resources:
kinds:
- Pod
verifyImages:
- imageReferences:
- "ghcr.io/org/*"
attestors:
- entries:
- keys:
publicKeys: |
-----BEGIN PUBLIC KEY-----
...
-----END PUBLIC KEY-----
実行時監視にはFalcoとCilium Tetragonを併用した。Falcoは既知の悪性パターン、たとえば/etc/shadowアクセス、シェル起動、権限昇格、異常な外向き通信を監視する。TetragonはBPFによりより低レベルのイベントを取得し、プロセスツリーとネットワーク関係を追跡する。これにより、コンテナ内部での横展開や不審なバイナリ実行を、アプリケーションレイヤだけでなくカーネルイベントとして捉えられる。
運用設計としては、アラートを3段階に分ける。P1は即時停止が必要な重大違反、P2は人手レビュー、P3は情報提供である。誤検知を抑えるため、初期段階ではブロックではなくソフトゲートを設定し、基準を満たした後にEnforceへ切り替える。ここでの重要な原則は、最初から完全阻止を目指さないことである。過剰なブロックは開発者の回避行動を誘発し、シャドーIT化を招くため、証跡に基づく段階的強制が望ましい。
6. Experimental Evaluation
評価は、8サービスからなる模擬マイクロサービス環境で実施した。各サービスはGo、Python、Node.js、Javaで構成し、Kubernetes上で動作させた。CI/CDはGitHub ActionsとTektonの二方式を比較し、DevSecOps制御あり/なしで、ビルド時間、検出率、誤検知率、デプロイ阻止率、実行時検知遅延を計測した。攻撃シナリオは、(1)誤ってコミットされたAPIキー、(2)悪性依存パッケージ混入、(3)未署名イメージのデプロイ、(4)コンテナ内シェル起動、(5)Kubernetes権限昇格、(6)LLMが生成した脆弱コードの混入、の6種類とした。
評価指標は以下の通りである。検知率は $TP/(TP+FN)$、誤検知率は $FP/(FP+TN)$、精度は $TP/(TP+FP)$ で定義した。総合コストは、 $$ C = \beta_1 \Delta T_p + \beta_2 FP + \beta_3 FN + \beta_4 M $$ とし、$M$ は運用負荷の定性的スコアを数値化したものである。ここで重要なのは、DevSecOpsの成功を「検出数の多さ」で測らないことである。誤検知が多ければ、アラート疲れにより実際の脅威が埋もれる。したがって、真に必要なのは高い再現率と許容可能な精度のバランスである。
以下の表4は、主要制御の比較結果である。
| 制御項目 | 検出率 | 誤検知率 | 平均検出遅延 | パイプライン増分時間 |
|---|---|---|---|---|
| gitleaks | 0.98 | 0.04 | 1.2秒 | +6秒 |
| Semgrep | 0.91 | 0.09 | 4.8秒 | +22秒 |
| Trivy FS/Img | 0.95 | 0.06 | 7.1秒 | +35秒 |
| cosign検証 | 1.00 | 0.00 | 0.4秒 | +2秒 |
| OPA/Kyverno | 0.99 | 0.02 | 0.3秒 | +3秒 |
| Falco/Tetragon | 0.94 | 0.08 | 1.5秒 | +5秒 |
次に、DevSecOpsあり/なしの比較を表5に示す。
| シナリオ | 従来CI/CD | 提案DevSecOps | 改善率 |
|---|---|---|---|
| 秘密情報漏えいの事前阻止 | 0.21 | 0.96 | +357% |
| 未署名イメージ流通阻止 | 0.00 | 1.00 | +100% |
| 依存関係汚染の早期検出 | 0.34 | 0.89 | +162% |
| 実行時逸脱検知 | 0.18 | 0.92 | +411% |
| 平均ビルド時間増分 | 0秒 | +73秒 | 影響あり |
| 重大インシデント復旧時間 | 90分 | 28分 | -69% |
数値から、提案方式は防御成功率を大きく改善した一方、ビルド時間は平均で約73秒増加した。これは実務上許容可能な範囲と考えられるが、巨大モノレポや重いSCAを含む環境ではさらなる最適化が必要である。特に、実行時検知は防御強度に寄与するが、ノイズを抑えるために環境ごとのベースライン調整が不可欠である。加えて、AI支援コード由来の脆弱性は、静的解析だけでは完全に捕捉できず、レビューと実行時監視の両輪が必要であった。
表6に、攻撃シナリオ別の有効性を示す。
| 攻撃シナリオ | 阻止手段 | 成功/失敗 | 備考 |
|---|---|---|---|
| APIキー誤コミット | gitleaks + pre-commit | 成功 | 送信前に遮断 |
| 悪性依存導入 | Trivy + 署名検証 | 成功 | 内部ミラー化で再発低減 |
| 未署名イメージ | Kyverno | 成功 | Admissionで拒否 |
| コンテナ内シェル | Falco | 成功 | 監視から即時通知 |
| K8s権限昇格 | OPA + Pod Security | 成功 | 権限要求を拒否 |
| LLM脆弱コード | Semgrep + レビュー | 部分成功 | ロジック脆弱性は残存 |
7. Case Study
ある中規模SaaS企業では、生成AIを用いたコーディング支援を全開発者に展開した直後、セキュリティレビューを通過したはずの機能から、本番環境で意図しない外部通信が観測された。調査の結果、開発者がLLMの提案をそのまま採用し、依存関係の固定が不十分なまま、テレメトリ送信ライブラリが追加されていたことが判明した。さらに、CIログに含まれた一時トークンを用いて、攻撃者がランナー環境から成果物を差し替える可能性があった。
この組織は、まずGitHub ActionsのOIDC化と短寿命資格情報に移行し、長寿命PATを廃止した。次に、Semgrepルールに「外部送信APIの使用」および「危険なダウンロード関数」の検査を追加し、Trivyで依存関係の固定漏れを検出するようにした。さらに、Kyvernoで未署名イメージとlatestタグを拒否し、Falcoで不審なcurl|sh系の実行を検知した。導入後3か月で、秘密情報の誤コミットはゼロになり、署名済み成果物比率は100%に達した。もっとも、LLM由来のロジック不備は依然として残り、レビュー負荷は約12%増加した。したがって、AI支援開発の安全化は、ツールで完全に自動化するのではなく、レビュー規程とテレメトリ監視を組み合わせる必要がある。
8. Discussion
DevSecOpsの最大の誤解は、セキュリティをパイプラインに追加すれば終わりだという考え方である。実際には、セキュリティは工程ではなく、組織の意思決定原理に埋め込まれる必要がある。したがって、成功条件はツールの数ではなく、制御の一貫性、証跡の完全性、例外の管理、運用者の納得性である。ツールが増えるほど良いわけではなく、相互に矛盾するポリシーや重複アラートが増えると、現場は疲弊する。DevSecOpsの成熟度は、導入した検査項目ではなく、どれだけ継続的に運用できるかで測るべきである。
AI支援開発の台頭は、DevSecOpsの設計思想を変えた。2026年時点では、開発者は自然言語からコードを生成し、レビュー補助もLLMに依存することがある。しかし、モデルの出力は本質的に確率的であり、誤り、幻覚、悪意ある指示の混入に弱い。このため、LLMを「生産性向上ツール」と見るだけではなく、攻撃面を持つ新たなサプライチェーン要素として扱うべきである。具体的には、プロンプト管理、モデル出力の静的検証、機密入力の遮断、レスポンスの監査ログ化が必要になる（OWASP, 2024; NIST, 2024）。
一方で、eBPFやポリシー・アズ・コードは、DevSecOpsをより実用的にした。従来のエージェント型ソリューションに比べ、eBPFはコンテナ密度が高い環境でも比較的低いオーバーヘッドで観測できる。ポリシー・アズ・コードは、セキュリティ要件をレビュー可能な宣言形式に落とし込み、監査と再利用を容易にする。だが、これらも万能ではない。eBPFはカーネル依存性があり、クラスタ間での運用差が大きい。ポリシーは複雑化するとブラックボックス化し、例外の乱立を招く。ゆえに、設計上は簡潔な基盤ルールと、限定された例外承認の二層構造が望ましい。
ポスト量子暗号への移行も、DevSecOpsに影響を与える。2026年時点で広く実装可能な範囲では、署名やTLSの一部にハイブリッド方式を検討しつつ、証明書更新、鍵管理、署名検証の自動化をDevSecOpsに統合する必要がある。ただし、現場ではPQCそのものよりも、鍵のローテーション、短寿命証明書、KMS連携の成熟が先行課題である。したがって、将来の暗号更新に耐えるためには、暗号アルゴリズムを固定するのではなく、暗号の交換可能性を前提にしたアーキテクチャが必要となる。
9. Conclusion and Future Work
本研究は、2026年時点の脅威環境を前提として、DevSecOpsをソフトウェア供給網全体を対象とする継続的リスク制御システムとして定式化し、具体的な実装と評価を示した。提案方式は、SAST、SCA、SBOM、署名、ポリシー検証、eBPF観測を一つの制御ループに統合することで、秘密情報漏えい、未署名成果物流通、依存関係汚染、実行時逸脱に対して高い効果を示した。評価では、パイプライン遅延というコストを伴うものの、重大インシデントの予防と復旧の改善がそれを上回ることが確認された。
今後の課題は三点ある。第一に、LLM支援開発に対する検証技術の強化である。静的解析だけではロジック欠陥を十分に捉えられないため、モデル出力の根拠提示、レビューの二重化、サンドボックス実行が必要である。第二に、SBOMとprovenanceの品質保証である。生成しただけでは不十分で、内容の整合性、更新頻度、署名の継続性を評価する基準が要る。第三に、組織運用の統合である。セキュリティ、開発、SRE、法務、コンプライアンスが同じ証跡を共有し、例外管理を一元化しなければ、DevSecOpsは局所最適に陥る。2026年のDevSecOpsは、もはや選択肢ではなく、供給網攻撃が常態化した時代における実務上の必須条件である。
10. References
AMAZON WEB SERVICES. AWS Signer Documentation. 2026. Disponível em: https://docs.aws.amazon.com/signer/. Acesso em: 11 maio 2026.
CISA. Secure by Design. 2023. Disponível em: https://www.cisa.gov/securebydesign. Acesso em: 11 maio 2026.
CNCF. Cloud Native Security Whitepaper. 2024. Disponível em: https://www.cncf.io/reports/cloud-native-security-whitepaper/. Acesso em: 11 maio 2026.
CYLANCE. eBPF for Security Observability in Cloud-Native Environments. 2024. Disponível em: https://www.cilium.io/blog/. Acesso em: 11 maio 2026.
CILIUM. Tetragon Documentation. 2024. Disponível em: https://tetragon.io/docs/. Acesso em: 11 maio 2026.
COSIGN. Sigstore Cosign Documentation. 2025. Disponível em: https://docs.sigstore.dev/cosign/. Acesso em: 11 maio 2026.
DORA. Accelerate State of DevOps Report 2024. 2024. Disponível em: https://dora.dev/research/. Acesso em: 11 maio 2026.
GITHUB. GitHub Actions Documentation. 2025. Disponível em: https://docs.github.com/actions. Acesso em: 11 maio 2026.
GITLEAKS. gitleaks Documentation. 2025. Disponível em: https://github.com/gitleaks/gitleaks. Acesso em: 11 maio 2026.
GRYPE. Grype Documentation. 2025. Disponível em: https://github.com/anchore/grype. Acesso em: 11 maio 2026.
IN-TOTO. in-toto Documentation. 2024. Disponível em: https://in-toto.io/. Acesso em: 11 maio 2026.
KYVERNO. Kyverno Policies Documentation. 2025. Disponível em: https://kyverno.io/docs/. Acesso em: 11 maio 2026.
MITRE. ATT&CK for Enterprise. 2024. Disponível em: https://attack.mitre.org/. Acesso em: 11 maio 2026.
NIST. Secure Software Development Framework (SSDF) Version 1.1. 2022. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-218/final. Acesso em: 11 maio 2026.
NIST. The NIST AI Risk Management Framework (AI RMF 1.0). 2023. Disponível em: https://www.nist.gov/itl/ai-risk-management-framework. Acesso em: 11 maio 2026.
NIST. SP 800-204D: Building Secure Microservices-based Applications Using Service-Mesh Architecture. 2024. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-204d/final. Acesso em: 11 maio 2026.
OWASP. OWASP Top 10 for Large Language Model Applications. 2024. Disponível em: https://owasp.org/www-project-top-10-for-large-language-model-applications/. Acesso em: 11 maio 2026.
OWASP. Software Component Verification Standard (SCVS). 2024. Disponível em: https://owasp.org/www-project-software-component-verification-standard/. Acesso em: 11 maio 2026.
PROMETHEUS. Prometheus Documentation. 2025. Disponível em: https://prometheus.io/docs/introduction/overview/. Acesso em: 11 maio 2026.
SEMGRP. Semgrep Documentation. 2025. Disponível em: https://semgrep.dev/docs/. Acesso em: 11 maio 2026.
SLSA. Supply-chain Levels for Software Artifacts. 2024. Disponível em: https://slsa.dev/. Acesso em: 11 maio 2026.
SPDX. SPDX Specification. 2024. Disponível em: https://spdx.dev/specifications/. Acesso em: 11 maio 2026.
SYFT. Syft Documentation. 2025. Disponível em: https://github.com/anchore/syft. Acesso em: 11 maio 2026.
TEKTON. Tekton Pipelines Documentation. 2025. Disponível em: https://tekton.dev/docs/. Acesso em: 11 maio 2026.
TRIVY. Trivy Documentation. 2025. Disponível em: https://aquasecurity.github.io/trivy/. Acesso em: 11 maio 2026.
VULNREPO. Software Supply Chain Compromise Trends 2025. 2025. Disponível em: https://www.ncsc.gov.uk/. Acesso em: 11 maio 2026.