People say there is no software crisis, but they neglect the countless sacrifices that we are expected to make just to mitigate software errors. Here is an article that suggests that (presumably server-based) software developers should completely lock down a machine that runs their program because any system state that is different from a tested system state cannot be relied upon. They recommend capturing a complete system image and even disallowing logins, because that alters the state.
I am not sure this goes far enough, though. Any system which allows instructions to be executed is at risk from a variety of sources. After all, it might be the wrong instruction. What we need is a mechanism to compute things without relying on the processor.
Therefore, I suggest you keep your server powered off. (This strategy requires some cooperation on the part of your users, of course, but we all have to make sacrifices in the interest of security and correctness.) If you see some blinking lights on your router, this means a user is attempting to contact your server application and you should expect a phone call. After the user connects with you acoustically, you will hear a series of beeps and bloops. The beeps denote 1's and the bloops denote 0's. It should be a simple matter to convert this sequence into an input message for your program, and for you to simulate the execution of the program on that input, resulting in a response of similar form which must be relayed acoustically to the user. (Be sure to tell them to wait a moment.)
The advantage of this strategy is that you, the developer, can examine the execution of your program on each input for errors, and mentally correct for them before you issue a response. Another advantage is that it is completely impervious to social engineering, as you can insist on only ever responding to beeps and bloops, not natural language. (Your users will learn to respect this.) Also, if you pick up the phone and the person at the other end is speaking English, you can be sure they are a hacker; hang up immediately. This will also save you the trouble of running your program on inputs which do not conform to the beep-bloop protocol, which lets you move more quickly through your connection queue.
Just a modest proposal.