When I was a full-time software developer, one of my colleagues inherited a piece of code that he simply couldn’t make sense of. The thing was a tangled mess of globally defined variables with obscure names that gave no clear indication of their scope; functions spanning hundreds of lines and returning in dozens of places; and goto’s and early exits from loops. For the non-coders, imagine an amalgam of a dirt road and a Los Angeles freeway, with left and right exits — all unmarked — and traveled by BMWs and horse-drawn buggies alike.

He decided that instead of risking breaking the fragile balance of this monstrosity, he left it all alone and preceded every return from the freakish code with a call to his own, sensible functions. Imagine all exits on the highway send you off on a parallel, paved road with separate lanes for different classes of traffic and clearly signed exits.

This is far from the norm in software development. But like one comedian says, somewhere out there is the worst doctor in the world — and someone has an appointment with him tomorrow morning. None of us wants to admit we’re not particularly proficient at our craft, but empirical evidence suggests that the inept are among us. And that’s OK as long as there are checks and balances to compensate.

I’ve written before about secure coding practices. Training programmers on secure coding practices, doing code reviews, and performing automated scans on both source code and the application as it executes need to be part of vendors’ development and quality assurance processes. But consumers need to protect themselves against the residual vulnerabilities.

Case in point: Adobe Acrobat was a favorite avenue of exploitation, which enabled the RSA compromise last year as well as countless other incursions. Now, I’m not saying Adobe writes bad code; rather, Acrobat is ubiquitous, which makes it a tasty target and the bad guys focused much energy on finding flaws in it.

But according to the IBM X-Force 2012 Mid-year Trend and Risk Report “the vulnerabilities in Office and Portable Document Formats (PDF) declined sharply (since the last report).” The report goes on to correlate the decline with the inclusion of sandboxing technology in Adobe Acrobat Reader X.

Sandboxing isn’t a new concept; it’s been used in various forms for some time. Perimeter DMZs are a form of sandboxing, as is segmenting networks with enclave firewalls. Linux/UNIX has had the concept of root jails, or chroot, for some time. Applications have been developed with the concept of separation of privileges for processes and threads. Postfix was written as a secure replacement for Sendmail, substituting Sendmail’s monolithic process model with multiple processes running with minimal privileges, where the main process is the only one that needs to be run as root.

If that sounds like a bunch of techy jibber jabber, imagine the recent presidential national conventions: a big stadium with a bunch of people with widely differing roles and motives. There are the delegates in attendance to cast their votes and drink in the pageantry; the media, there to witness and report the goings-on; the organizers and staff, directing the activities; the nominees and their entourage of family, colleagues and guest speakers; and finally there’s the security detail, trying to keep the whole thing from turning into a recreation of “The Dead Zone.” This is what a typical operating system and all its applications look like: not much in the way of separation or segmentation to keep one angry person with a weapon from bringing down the house.

Now imagine if each of the separate factions had bulletproof, plexiglass domes surrounding them; interconnected as needed by common doors and controlled by a well-trained security guard. It would be impossible to pull out a handgun and fire on the dignitaries, or even the media. However, the media and the delegates will need to communicate and the guard mediates the individual meetings. This reduces the potential for mayhem.

But no security measure is foolproof. Security is not about absolute containment, it’s about deterrence and early detection. People are smarter than turtles and turtles can be blasted difficult to contain. I can think of a half-dozen ways to thwart the cone of silence thingy, but they’re far more involved than the alternative, and will almost certainly require two steps now instead of one: thwart the guard, then cause the intended damage.

Application sandboxes add one more layer of defense in the struggle to regain the right to peaceful enjoyment in our own networks. We already control the infrastructure and can design architectural sandboxing, so it’s important that application providers are putting skin in the security game, particularly because it adds a fair bit to their overhead and little to their direct bottom line.

So kudos to Adobe and others who are investing in sandboxing technology. Time will tell how effective it is in the long term. But at least as consumers are struggling with how to adopt cloud and mobile computing, which challenges my assertion a moment ago that we control our infrastructures, with application and service providers wrapping their own goods in a virtual prophylactic, we won’t feel as option-less when we agree to the EULA. And once they start down the road of building security into their applications, perhaps — just maybe — they’ll come up with a better mousetrap. Sounds like a good name for sandbox 2.0.