11 KiB
title, created, updated, type, tags, sources, confidence
| title | created | updated | type | tags | sources | confidence | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CI/CD Runtime Security | 2026-06-30 | 2026-07-16 | concept |
|
|
medium |
CI/CD Runtime Security
CI/CD runtime security is the practice of observing, constraining, and isolating what actually runs inside build, test, release, and deployment jobs. The core problem is that CI jobs hold cloud credentials, signing keys, package-registry tokens, and deployment authority, while compromised dependencies or scripts can execute inside short-lived jobs and disappear with the evidence when the job ends. ai-agent-identity-security covers adjacent authorization and audit concerns for agents; loop-engineering is relevant because autonomous development loops often depend on these pipelines as their verification and deployment boundary.
Why it matters
Traditional software supply-chain controls often answer where an artifact came from or how it was built, but they may not preserve enough runtime evidence about what a job process actually did. cicd-sensor frames this as an EDR-like gap for CI/CD: open-source defenders exist for many production runtimes, while CI/CD runners have lagged despite holding highly privileged credentials.^[raw/articles/cicd-sensor-2026.md]
Implementation pattern
cicd-sensor uses an eBPF-powered sensor for GitHub Actions and GitLab CI/CD. Its baseline detections use process ancestry and correlated signals: for example, credential access by a process descended from npm install, or one job reading several credential categories. It can emit per-run logs, graphical job summaries, cloud-routed evidence, and build attestations while keeping data in the operator's own infrastructure rather than sending it to a project-operated SaaS.^[raw/articles/cicd-sensor-2026.md]
Tangled's Spindle microVM engine shows the complementary isolation side of the same problem. Each workflow boots a small QEMU microVM, runs a guest agent over vsock, executes steps as an unprivileged spindle-workflow user, and can build a NixOS guest configuration from the workflow file itself. Network access is routed through separate namespaces, slirp layers, DNS filtering, and blackholed special-use ranges so the guest can reach the internet without reaching the host or local private networks. This makes CI runner design part of the trust boundary, not just a scheduling detail.^[raw/articles/tangled-spindle-microvm-ci-runners-2026.md]
Argo CD の repo-server 欠陥は、deployment controller 自体が CI/CD runtime boundary になることを示す。The Hacker News / Synacktiv の報告では、内部 gRPC port に届く attacker が kustomize の --helm-command 経由で repo-server 上の code execution を得て、さらに Redis password を読んで deployment cache を poison し、次回 sync で attacker workload を cluster に入れられる。Synacktiv の一次解説は、CodeQL で taint flow を追い、repo-server の request handling から Kubernetes cluster compromise へつながる exploit path と自動化 tool まで示している。Helm chart では network policy が既定で無効なため、「cluster 内部だから安全」という前提が壊れる。CI/CD runtime security では runner だけでなく、repo-server、Redis/cache、GitOps controller、sync loop も最小到達性・署名・監査の対象になる。^[raw/articles/thehackernews-argo-cd-repo-server-unpatched-rce-2026.md] ^[raw/articles/synacktiv-argo-cd-codeql-rce-2026.md]
AI が生成した GitHub Actions YAML は、動作確認だけでなく trigger、checkout 対象、token 権限、cache / artifact / secret の信頼境界を人間が読む必要がある。Zenn の整理では、pull_request_target で外部 PR 側の code を checkout して実行しないこと、permissions を省略せず read-only から始めること、untrusted trigger からの cache を信用しないこと、workflow_run や artifact 経由で権限境界をまたがないことが確認点として挙げられている。これは ai-agent-command-safety と接続し、AI が作った自動化設定そのものを privileged runtime code としてレビューする必要を示す。^[raw/articles/zenn-ai-generated-github-actions-yaml-security-2026.md]
GMO Flatt Security の GitHub Actions 解説は、OIDC / Trusted Publishing を入れても「認証後に runner 上へ置かれる派生クレデンシャル」は残る、という runtime 視点を強調する。GITHUB_TOKEN は actions/checkout の credential persistence や Runner.Worker のメモリから読まれうるし、AWS/GCP/Azure/Docker などの認証 Action は一時クレデンシャルや設定ファイルを後続 step から到達可能な場所へ置く。Environment 保護、ruleset、claim の数値 ID 検証、job 分離、短い session duration は有効だが、依存関係・Action・正規レビュアー経由で信頼済み経路に悪意ある code が入ると、漏洩を完全には防げない。したがって runner 側の process/network/file trace と cloud 側の異常検知を合わせ、漏洩後の検知・調査・失効手順まで設計する必要がある。^[raw/articles/flatt-github-actions-credential-leakage-2026.md]
1Password Credential Broker は、この OIDC / Workload Identity Federation を credential 配布側へ寄せる実装例である。GitHub Actions job が platform-issued signed token で repo・branch・workflow・environment・commit を証明し、1Password が trust policy と照合して item-level の credential だけを job-scoped window で渡す。これは runner 上の派生 credential 問題を完全には消さないが、vault への常時 access と広い service account token を減らし、誰のどの workflow がどの credential を取ったかを監査可能にする。将来の AI agent 対応では、agent も同じく task-scoped short-lived token を受け取るため、ai-agent-identity-security の実装パターンとしても重要である。^[raw/articles/1password-credential-broker-2026.md]
GitHub の Secret Protection による public monitoring は、secret leak detection の境界を「自社 repo」から GitHub の公開面全体へ広げる例である。企業メンバーや verified domain の metadata から、個人 fork、OSS repo、issue、pull request、discussion などに漏れた secret を enterprise に帰属させる。これは CI/CD runtime そのものの隔離策ではないが、agent・bot・開発者が組織外の公開面へ token を誤って出す前提で、公開漏洩の発見を incident response loop に入れる実務的な補助線になる。^[raw/articles/github-secret-scanning-public-monitoring-2026.md]
Microsoft の GitHub Quick Review (ghqr) は、GitHub Enterprise / org / repo / GHES を横断して security posture を棚卸しする CLI である。Dependabot、secret scanning、code scanning、2FA/SAML、branch protection、CODEOWNERS、Actions workflow permissions、self-hosted runners、audit log、Copilot policy、MCP settings までを Markdown / Excel / JSON に出せるため、CI/CD runtime security を「個別 YAML のレビュー」から「GitHub tenant 全体の定期診断」へ広げる道具として位置づけられる。^[raw/articles/microsoft-ghqr-github-quick-review-2026.md]
GitHub Actions の workflow execution protections は、runtime boundary を YAML 内の自己防衛から enterprise / org / repository policy へ引き上げる機能である。Actor rule で workflow を起動できる user / role / GitHub App / Copilot / Dependabot を制限し、event rule で pull_request_target や workflow_dispatch などを制御できる。これは malicious workflow file が commit に入った後で runner が動く前に、中央 ruleset が「その actor/event は workflow を走らせてよいか」を判定するため、AI が生成した YAML のレビューや open-source-package-supply-chain-attacks の依存実行対策と補完関係にある。^[raw/articles/github-actions-workflow-execution-protections-2026.md]
strix は、CI/CD に入る security testing が SAST や設定監査だけでなく、実行中の application へ AI pentest agent を当て、reconnaissance、exploitation、PoC validation、修正案、report まで返す方向へ広がる例である。これは「runner が何をしたかを監視する」cicd-sensor 型の runtime evidence と対になる。Strix のような tool を PR gate に置くなら、検査対象の sandbox、network egress、test credential、false-positive review、auto-fix の human gate まで含めて CI/CD runtime security として設計する必要がある。^[raw/articles/strix-ai-pentesting-agent-2026.md]
Design implications
For Yuta-style automation, the useful distinction is not just "scan code before it runs" but "record and reason about privileged automation while it runs." Agentic coding systems, scheduled jobs, and deployment workflows should treat CI/CD runtime logs, provenance, and least-privilege boundaries as first-class product requirements. This connects to ai-agent-identity-security when agents need scoped credentials, and to wiki-maintenance-loop as an example of recurring automation that should be observable and auditable.
scrutineer extends the same supply-chain concern toward open-source vulnerability discovery and disclosure. Instead of watching CI runtime behavior, it uses skill-based AI scans, threat models, maintainer discovery, patch drafting, and release watching to keep unverified model findings inside a human-gated workflow before they reach maintainers.^[raw/articles/scrutineer-oss-security-workflow-2026.md]
Open questions
- How should teams balance runtime blocking, forensic logging, and false positives in developer-facing pipelines?
- What evidence format is durable enough to connect runtime traces with artifact provenance and code review history?
- Where should CI/CD runtime controls live when agents can run locally, in cloud sandboxes, and inside hosted CI at different stages of one task?