> Instead, code that shells out with programmatically constructed commands is typically riddled with potential bugs in the best case and massive security holes

> Instead, code that shells out with programmatically constructed commands is typically riddled with potential bugs in the best case and massive security holes in the worst case. This sentence sounds eerily similar to what we have with SQL Injection. Same concept: constructing raw commands for untrusted user input. The solution is equally simple: input validation (where possible), parameterized queries/shellescape. The barriers to people shelling out securely are the same we had/have with SQL Injection: 1- Education: Many people are unaware of these solutions. 2- Bad habits reenforced by bad code examples. People don't use these security best practices in the simplified code examples included in a blog post, documentation, or a Stack Overflow answer. I joke that the only SQL code example on MSDN that isn't SQL Injectable was the example for parameterized queries (I'm not that far off). Sadly It's not much better for escaping/defanging shell code. Shelling out also had the added problem that far fewer people do it than use SQL, so the propagation of security best practices is going to be slower. Luckily it also means there are fewer places that screw it up.