Blog post: My biggest problem with build and deployment pipelines

https://david.gardiner.net.au/2025/01/biggest-problem.html

#ContinuousIntegration #ContinuousDeployment #BuildPipelines #DevOps

Hey hey,
May as well do an intro post since I'm hoping this account will actually get used

My name is TJ and I'm a #dad of 3, husband, #communist and #developer from #novascotia

My interests lay mostly around #programming, #leftist #theory, #buildpipelines, #economics and #anthropology .

Exploiting the *privileges* from a privileged build pipelines to run an attacker's code is a notable extension to this fantastic article by @shortridge at https://kellyshortridge.com/blog/posts/attackers-have-better-things-to-do-than-corrupt-your-builds/

The build system exploits that have been on my mind:
Build pipelines are often designed to operate with high privileges — and to use the new build's pipeline instructions for performing the build!

As Kelly said, the attacker can get far more out of exploiting the ability to push their own code to run in the target environment — but the build system itself supplies the factor that elevates the severity and elevates the privileges by allowing the new build to define a series of actions that only the privileged build system can perform.

Build systems are great ways to make OTHER attacks more impactful or to evade detection. The main vulnerability is the ability for an attacker to run code — but the build system is a route along the way to augment that with privesc, confused deputy, evil maid, etc.

I'm wary of orgs that accept "well, of course if attacker gets X then they can deploy code" or "we allow users to run code by design" without taking care of basic controls to limit the blast radius of "working as designed; won't fix". I find it helpful to share some examples clarifying the impact and what they can do to provide guardrails for build systems.

#BuildPipelines #Exploits