Notifications
Clear all
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.
NHIMG editorial — based on content published by SentinelOne: an analysis of how attackers are subverting trusted software delivery infrastructure
By the numbers:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations.
Questions worth separating out
Q: What breaks when CI/CD runners and service accounts are not tightly governed?
A: When CI/CD identities are not tightly governed, attackers can inherit trusted execution inside the software delivery path.
Q: Why do non-human identities make supply chain attacks harder to detect?
A: Non-human identities make supply chain attacks harder to detect because build jobs and malicious actions often use the same tools, scripts, and permissions.
Q: How should security teams reduce blast radius in CI/CD environments?
A: Security teams should reduce blast radius by assigning each pipeline identity the minimum permissions needed, rotating credentials aggressively, and separating build, test, and deploy privileges.
Practitioner guidance
- Inventory every build identity and runner Create a complete register of self-hosted runners, service accounts, pipeline tokens, and developer automation credentials, then assign each one an owner, scope, and expiry date.
- Enforce short-lived access for pipeline automation Replace long-lived tokens where possible, scope credentials to a single workflow or environment, and revoke any automation secret that outlives the job it supports.
- Require provenance checks before execution Block workflow execution unless the job source, runner registration, and triggering identity match expected patterns for that repository and environment.
What's in the full article
SentinelOne's full report covers the operational detail this post intentionally leaves for the source:
- Threat-by-threat examples of runner compromise, workflow abuse, and dependency poisoning across 2025 incidents
- The specific signals used to distinguish malicious pipeline activity from expected automation in live environments
- Detailed guidance on monitoring self-hosted runners, service identities, and build artifacts for abuse
- Examples of how attacker tradecraft moved from developer compromise into CI/CD execution paths
👉 Read SentinelOne's analysis of CI/CD compromise and trusted infrastructure abuse →
CI/CD pipeline compromise: are your build controls keeping up?
Explore further
10/07/2026 9:39 pm
CI/CD compromise is now an identity governance problem, not only a pipeline security problem. The article shows attackers inheriting trust through service accounts, tokens, runners, and workflow triggers rather than breaking into production directly. That makes lifecycle control, least privilege, and provenance verification the core governance issues, not optional hardening steps. Practitioners should treat build identities as governed assets with owners, scopes, and expiry.
A question worth separating out:
Q: Who is accountable when a trusted build pipeline is used to deploy malware?
A: Accountability usually spans platform engineering, application owners, and security governance because the compromise sits at the intersection of code delivery and identity control. Organisations should map ownership for runners, tokens, workflow definitions, and release approvals before an incident occurs. Clear accountability is what makes containment and audit response possible.
👉 Read our full editorial: CI/CD subversion is turning trusted build infrastructure into attack surface
