Parent's original point is just that libraries/frameworks are a much safer way of writing programs that handle untrusted input in security-critical settings. N

Parent's original point is just that libraries/frameworks are a much safer way of writing programs that handle untrusted input in security-critical settings. Nothing you've said contradicts this original point (and I think it's a correct assessment). A compelling counter-argument, IMO, would be a demonstration of how to incorporate tried-and-trusted security checks into a bash script. >> I would struggle to justify the work I'd need to do to write the equivalent in C (or python, where it would be slower) for one command that's only run in the release process. The original article lists the CVEs that justify the extra work. You may say "that doesn't matter because any input to the release process must come from a trusted source anyways", but: 1) missing input validation can cause accidental catastrophic bugs just as easily as it can cause intentional catastrophic vulnerabilities, and 2) the whole point of defense in depth is that you shouldn't go around punching preventable holes in your defenses. IMO it shouldn't be possible to escalate from "request a build of the branch named 'X'" to "owning the release server".