From YAML To Root: CI/CD Pipeline Attacks And Countermeasures

CI/CD pipelines were once the preserve of developers and administrators, but they now serve marketing, HR and client sandboxes, which widens the attack surface. The speaker separates platform-hosted runners from self-hosted ones, and notes that shared self-hosted pipelines can let a compromise in a development environment reach production. The scenarios assume a standard contributor role and cover YAML files, official tasks, Terraform providers and a case where only the right to create service connections is available.

Inline script steps give direct code execution, and official cloud CLI tasks let an attacker use the pipeline's own rights to create service principals and download Terraform state files. Terraform's external and local provisioners can also run commands, and a renamed fork of the external provider, published to the public registry, got around a blocklist. Another path used the classic editor to point a pipeline at an attacker-controlled repository. Secrets can leak because base64-encoded values are not masked. Scans of published Microsoft address ranges found many reachable hosts, and a shell restriction was sidestepped with an interactive session. Runners often run as root and lack monitoring, so attacks often went unnoticed.

The practical lessons are that a generic checklist is not enough, since controls must match how each pipeline is used. Useful measures include isolating secrets, restricting network access, segmenting runners and alerting on pipeline logs. Short-lived runners complicate endpoint tools, and verbose logs carry cost, so defenders must decide per pipeline.