Climbing the Production Mountain: Practical CI/CD Attacks Using CI/CD Goat

The speakers, both from a company focused on CI/CD security, start from the problem that build and deployment pipelines hold production credentials yet are rarely practised by defenders. They present CI/CD Goat, an open-source, Docker-based capture-the-flag lab that combines a Git server, Jenkins, a local AWS emulator and a small web server, with challenges that map to the top CI/CD security risks.

They then work through three attacks in the lab. The first is poisoned pipeline execution: with only read access to a public repository, a modified Jenkinsfile submitted from a fork ran inside the build, exposed a token that had write access, and let them push straight to the main branch. The second abuses an auto-merge step that approves pull requests when simple checks pass, such as changes limited to a version file and a balanced count of added and removed words. Padding the change to satisfy the naive word count got the pull request merged into a protected branch. The third is a supply chain scenario: a pull request title was injected into a shell command to leak a deployment key, and a remote script fetched on every run without integrity checks showed how a compromised upstream could steal secrets from downstream users.

For each attack the speakers explain the root causes and remedies. Keep secrets away from builds triggered by forks, scope secrets to individual jobs rather than agents, grant tokens only the permissions they need, and require reviewed branch protection. Avoid auto-merge unless its logic is airtight, never place untrusted input in shell commands, restrict outbound connections, and verify hashes or signatures on fetched artifacts. Their closing point is that a single weak link in a CI/CD environment can be enough to reach production.