| > 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. |