Topic starter
10/07/2026 9:16 pm
TL;DR: Attackers are increasingly abusing build servers, runners, service accounts, and developer workstations to turn trusted software delivery infrastructure into an intrusion path, according to SentinelOne. The security problem is not just malware in the pipeline, but implicit trust in automation that lets malicious activity blend into normal release workflows.
Editorial analysis by NHI Mgmt Group, based on content published by SentinelOne: “Living Off the Pipeline: Defending Against CI/CD Subversion”.
Key questions
Q: What breaks when CI/CD access is not tightly governed?
A: Build and deployment systems become an easy path to bypass application defenses.
Q: Why do compromised build pipelines create identity risk beyond AppSec?
A: Because build pipelines often hold publishing rights, signing secrets, and automation tokens that function like privileged identities.
Q: How do security teams know whether pipeline access is actually under control?
A: Look for three signals: no long-lived deploy secrets in repository or pipeline settings, tight Kubernetes roles scoped to the smallest viable namespace and verbs, and audit logs that tie each deploy to a specific workflow run.
Practitioner guidance
- Harden build runner enrolment Require explicit approval for self-hosted runners, maintain a current inventory of every registered runner, and alert on new or renamed build agents that appear outside approved change windows.
- Constrain service account scope and lifespan Limit pipeline service identities to the minimum repositories, workflows, and artifacts they need, then revoke any token that can create projects or trigger jobs outside its intended purpose.
- Inspect workflow-triggered execution paths Review jobs that start from comments, repository events, or other indirect triggers, and flag any workflow that can execute code without a human reviewing the exact change first.
Bottom line: CI/CD compromise succeeds when attackers inherit trusted automation rather than fighting their way through perimeter controls.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
10/07/2026 9:39 pm
CI/CD trust has become a governance problem, not just a tooling problem. Build systems are being targeted because they already hold the authority to execute code, move artifacts, and touch secrets. That means the core failure is implicit trust in automation, not simply weak malware detection. Practitioners need to govern build-time trust as a privileged identity problem, not a generic endpoint issue.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What should organisations do when build infrastructure is used as an attack path?
A: They should investigate runner enrolment, revoke suspicious tokens, rotate exposed secrets, and review every workflow that could have executed under stolen automation identity. The priority is containment of the trusted path before the same identities are reused for persistence or further spread.
👉 Read our full editorial: CI/CD subversion is turning trusted build infrastructure into attack surface