Every program needs to make some assumptions about what operations it's going to trust and what it's going to verify. Most programs, for example, assume that (length + 1) [where 'length' is a simple 32-bit integer] will have no side effects, even though there's no absolute guarantee that the NSA hasn't backdoored your compiler or a Chinese supplier hasn't backdoored your CPU to open a rooted shell remotely. Most programs will also assume that (length + 1 > length), even though in many languages this isn't universally true because of integer overflow. If your program never deals with integers that large, it doesn't matter.
For most public programs, the trust boundary is generally assumed to be the process. Any I/O the process does is assumed to be untrusted; it could do anything. But anything inside the process is assumed to work as the language says it does, because the OS is assumed to provide memory protection that prevents other processes from tampering with it. (Some big companies go a step further and dictate that you're not to trust 3rd-party libraries unless the code has been specifically audited; this is generally a sensible practice security-wise, but a huge drag on developer velocity.) If you couldn't trust the basic machine operators, you'd never get anything done - you'd have to write sanity checks everywhere, and then you have no guarantee that the sanity checks themselves aren't backdoored.
For many internal apps, the network is inside the trust boundary. It's assumed that any network connection comes from a trusted source, because otherwise the firewall would've rejected this. And being able to assume this saves a lot in developer velocity; it becomes feasible to write one-off internal tools without the devs having to carefully audit all the I/O & cross-process code for vulnerabilities. If you didn't have this trust, most of these apps wouldn't get written, because the productivity benefit they provide isn't greater than the cost of writing a hardened, secure system. It's not just networking calls; if you can assume that your users are non-malicious employees, you also don't need to worry about XSS or XSRF, pathological regexps, DOS attacks based on large payloads, etc.
And sometimes you don't trust the operations. I've heard tales of flight computer software running on 3 computers from 3 vendors running 3 implementations of software from 3 independent teams. Then the 3 computers voted on a course of action.
Thank you. I heard it about SAAB Gripen fighter/attack/recon craft in the 90s, but for me it's faded memory of hearsay - so it's cool to read a more substantial reference. :)
