[laumars]

> If I have owned a dev and can push code to a branch I can likely execute code in their build environment.

But then you’re also executing that code as a trusted user. Ie the real hack is owning the dev.

> This is how the vast majority of build systems are configured.

No. The vast majority of build systems are either locked to private repositories, and/or a subset of developers, and/or run in an ephemeral sandbox.

> But I do wonder what the cumulative impact of every binary on your system being memory safe would be.

I’d already answered that. It’s negligible because if someone can exploit a buffer overflow in awk then they can already run arbitrary code in awk (remember, awk is a programming language). So if you’re not already taking precautions about who is running what on your build system and how running code is sandboxes then it’s not going to take a buffer overflow bug to RCE it.

[staticassertion]

> But then you’re also executing that code as a trusted user. Ie the real hack is owning the dev.

That's like saying the real hack is sending a phishing email, ignoring all privesc, lateral movement, etc.

> No. The vast majority of build systems are either locked to private repositories, and/or a subset of developers, and/or run in an ephemeral sandbox.

I didn't say otherwise. I said that the majority allow untrusted execution. If you consider your engineers laptops to be trusted you're thinking about networks the way people did ~10+ years ago.

> It’s negligible because if someone can exploit a buffer overflow in awk then they can already run arbitrary code in awk

This isn't true, but even if it were you can just replace awk with anything else that's not turing complete.

[laumars]

> I said that the majority allow untrusted execution. If you consider your engineers laptops to be trusted you're thinking about networks the way people did ~10+ years ago.

i never said anything about trusting engineers laptops.

Let me put it another way, are you running your build pipelines bare metal, allowing anyone to instantiate the pipeline against a branch of code that anyone in the public has written? Or is that build pipeline running against a private repository, or triggered by trusted users, or does it run inside a temporary VM or container that gets destroyed afterwards? That’s where you harden CI/CD. I’m not suggesting fixing buffer overflows aren’t worthwhile (security should be multilayered after all) but it’s missing the real risk since you’ve already got code remotely executing. Thus your threat model should be about ensuring you minimise the blast radius of that code.

To use your colourful language: if your build pipelines are running bare metal then you’re thinking about infra like people did ~10 years ago.

> This isn't true, but even if it were you can just replace awk with anything else that's not turing complete.

But you’re still not addressing the real issue. If you can’t trust the the code executing and you’re not sandboxing that code then you’ve already lost the fight. You can’t give unrestricted access to execute code remotely and then moan “we wouldn’t have been exploited if everything was written in Rust”. The bone headed design was allowing unrestricted remote code execution and not the buffer overflow bug in ‘cat’.

> That's like saying the real hack is sending a phishing email, ignoring all privesc, lateral movement, etc.

It’s really not. What I’m taking about is the equivalent of saying “phishing attacks are always going to happen so you need MFA et al to harden against the array of of ways one can manipulate the system”

You’re entire security model seems to be focused around fixing every fucking executable against every possible class of bug and that’s insanely impractical. Whereas I’m suggesting one shouldn’t implicitly trust remote code in build pipelines to begin with.