Notifications
Clear all
Topic starter
07/06/2026 8:23 pm
TL;DR: AI-driven code volume is turning CI/CD from a pass-through stage into a production system with new security and trust requirements, and Depot says build failures, hidden third-party dependencies, and outbound traffic controls are now core concerns. The governance issue is no longer speed versus safety alone; build pipelines now need identity, network, and supply-chain controls that assume compromise can happen mid-delivery.
NHIMG editorial — based on content published by WorkOS: Depot is making builds fast enough for the AI era
Questions worth separating out
Q: How should security teams govern CI/CD pipelines as identity-bearing systems?
A: Security teams should treat CI/CD as a governed production surface, not a transient utility.
Q: Why do build pipelines become riskier when AI increases code volume?
A: AI increases the number of build, test, and release events, which expands the opportunity for dependency failure, credential misuse, and unnoticed exfiltration.
Q: What breaks when CI jobs can contact any outbound domain?
A: Open outbound access turns the build environment into a data movement channel.
Practitioner guidance
- Classify CI runners as governed non-human identities Assign owners, scope, and review cadence to every build runner, service token, and registry credential.
- Add outbound allow lists to build jobs Require GitHub Action runners and other CI jobs to use monitored egress rules, then fail any job that attempts to reach an unapproved domain.
- Map hidden delivery dependencies before outages expose them Document which external services, package sources, caches, and internal systems a build depends on.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- The interview discussion on how Depot expanded from Docker image acceleration into build runners, remote caching, agent sandboxes, and a container registry.
- The specific rationale behind making correctness the first priority before performance in build acceleration.
- The explanation of why GitHub Action runner egress controls matter for preventing build-phase data exfiltration.
- The broader developer tooling discussion around APIs, MCP, and why flexible building blocks matter when humans and agents both call the same services.
👉 Read WorkOS's interview on Depot and AI-era build pipeline security →
CI/CD security in the AI era: what IAM teams need to rethink?
Explore further
07/06/2026 10:16 pm
CI/CD governance is now an identity problem as much as a delivery problem. When build runners hold credentials, fetch artifacts, and reach production-adjacent services, they behave like non-human identities with operational authority. That means the old assumption that pipelines are temporary infrastructure is too weak for AI-era delivery. Practitioners should govern runners, tokens, and egress as a single control surface.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: How do organisations reduce blast radius in software delivery pipelines?
A: They reduce blast radius by limiting what each build identity can access, where it can connect, and how much trust it receives by default. The goal is to keep compromise or failure in one job from becoming a pipeline-wide or environment-wide incident.
👉 Read our full editorial: CI/CD is becoming a security boundary in the AI era
