I'm asking this here and not on the security related site because this one is a question about "software architecture" and "development methodologies", which are both covered by the FAQ.

EDIT: I'm talking about purely remote root / admin software exploits. Not about insider physically breaking into labs / companies / houses / networks / machines.

Everytime there's a blog entry or article about a new security exploit there are lots and lots of people basically writing that: "No software shall ever be secure, every single software out there can be exploited. Give any pirate sufficient time and he'll eventually exploit any high-target software." This is a constant. These type of comments always get modded like crazy and most people seems to accept it as a fact.

And it really gets me wondering: can any software architecture and development methodologies be used to ever come up with secure software or is there something technical that prevents us from writing secure systems/programs/OSes/servers?

The more I think about it, the more I don't understand why we couldn't, technically, build 100% secure software. All the way down from the OS and then up: browsers, plugins...

Note that I'm not interested in a discussion here: I want to know if technically there is something or not that can prevent, say, an OS, to be written in a 100% secure way and why it's that way.

Now if there's nothing technically that prevents us from writing a 100% secure OS and from then writing a 100% secure server, why hasn't it been done? Does it means our architecture and development methodologies (and tools?) are deeply flawed?

  • By better methodologies, maybe for example that in the future a team / company could maybe use formal verification to prove that a microkernel is 100% bug-free, failure-free and resilient to security issues, a bit like here: schneier.com/blog/archives/2009/10/proving_a_compu.html Would this be science-fiction? Jan 26, 2013 at 1:41
  • Have you looked at Propellerheads's Reason 6? Is it cracked?
    – Cole Tobin
    Jan 26, 2013 at 2:16
  • What keeps us from writing 100% secure code? The same thing that prevents 100% secure prisons, or 100% secure fortresses, or 100% secure bank vaults, or ... Software isn't unique in this respect.
    – Eric King
    Jan 26, 2013 at 4:33
  • We haven't even bothered using memory-safe languages to [practically] remove memory corruption vulnerabilities. Similarly we know how to [practically] eradicate injection vulnerabilities. We are well away from needing formal methods to improve security. Jan 26, 2013 at 5:00
  • To argue why something should exist, one only needs a positive example. To argue why something doesn't exist, one needs a theorem that can prove that it couldn't. Thus, question of this type requires argumentation, which is subject to discussion.
    – rwong
    Jan 26, 2013 at 8:20

4 Answers 4


No, it means that the world isn't secure. Software, like any other human endeavor, can be breached, circumvented, or otherwise done in. The question is not whether we can make it 100% but whether the security in place will slow the aggressor down/annoy him enough to make it temporally or economically unfeasible for him to bother whilst not making it economically or temporally unfeasible for us.

Software is not perfect because humans are not perfect.


It's the complexity that gets you: it's pretty easy to build a simple system that is 100% error-proof. The problem is, such system would not be very useful. As soon as you start piling up complexity, you start creating trouble.

Even the simplest web application requires interaction of many parts. Here is an oversimplified list:

  • The OS of the client
  • The browser on the client
  • The network I/O library on the client
  • The networking infrastructure of the client Internet provider
  • The networking infrastructure on the way to your server's internet provider
  • The networking infrastructure of the server's Internet provider
  • The OS of the server
  • The application server
  • The network I/O library on the server
  • Your server application

If you go deeper, you get more components: XML parsers, HTML renderers, image processing libraries, encryption libraries, database client libraries, RDBMS servers, disk I/O libraries, regular expression libraries, libraries for interacting with third-party components, and so on.

Now comes the bad part: a security problem in any of your multiple layer makes the overall system insecure. Let one component break - and the whole system comes down. Let's say each of your many components is 99.9% reliable - that's between "very good" and "incredible". Let's suppose that your system is composed of thirty such very reliable components. The overall reliability of your system is then 0.999 ^ 30, or about 97%. A good attacker would take these odds in a heartbeat!

So the answer to your question is that a sufficiently complex system contains its own undoing. You can greatly reduce the risk by lowering the complexity, but the usefulness of your system would come down as well.


90% of unauthorized access comes from people within the network. Disgruntled accountants, bored secretaries, overly ambitious middle management... Even if you make the technology 100% secure, there's still people to worry about.

  • +1: This begs the question of where authorization comes from. A fraction of software exploits come from software overstepping their authorization, but then software can only imperfectly model the idea of authorization in their human owners' mind.
    – rwong
    Jan 26, 2013 at 8:52

I did more reading and realized that there is actually some hope. I edited the question to point out that I was talking only about purely software exploits, not about people pointing a gun to your head and forcing you to give your data.

There's actually right now, in production (and apparently already used in many devices: tens of millions if not hundreds of millions), a micro-kernel that has been formally proofed as being immune to:

  • buffer overflows / overruns
  • memory leaks
  • no null pointer exceptions
  • no arithmetic overflows

In other words: it is impossible for a security exploits to happen by using any of the above because it has been mathematically prooved (by using an automated theorem prover) that it its, for example, impossible to trigger a buffer overflow in that microkernel.

That's the first of its kind and it shows that there's a way out. It is apparently a very active area of research and I'm willing to bet we're going to see more of this in the future.

The implication are huge: no userland process can do privilege escalation leading to control of the microkernel.

There can of course still exist other ways to pirate the system as of now: right now it's just the micro-kernel (and, partially, the compiler) that have been proved to be resilient to these attack vectors. There may be other attack vectors which haven't been tested yet but still...

It shows that, technically, it is totally possible to not only create an OS that is immune to software exploits but that, moreover, it is possible to mathematically prove that the protection in place aren't exploitable.

I expect this area of research to gain more and more traction.

(*) The Isabelle / HOL theorem prover uncovered 160 bugs (which have been all fixed) in the 7500 lines of C and 600 lines of assembly in the seL4 microkernel, which is now guaranteed to make it impossible, for example, to have a buffer overflow (a typical attack vector) or a null pointer exception in the seL4 microkernel.

  • 1
    Guaranteed by whom? Also, how was the correctness of the theorem prover verified?
    – Caleb
    Jan 26, 2013 at 17:14
  • @Caleb: the point is: it's a very active field of research and instead of saying "This is impossible" there are people who are thinking outside the box, trying to make our (computer) science go forward. Of course there are going to be nay-sayers and people seeing only the obstacles, instead of the goal. "The reasonable man adapts himself to the world while the unreasonable tries to adapt the world to himself, therefore all progress depends on unreasonable man". But I understand that post-fact rationalization makes some accept insecurity as a fatality ; ) Jan 28, 2013 at 13:34
  • I never said it was impossible. I'm just pointing out that "guaranteed" is a pretty strong word. Unless somebody really did guarantee the correctness of some program, you shouldn't use that word. And if someone did offer a guarantee, I'd like to know more about its terms and what makes them so confident.
    – Caleb
    Jan 28, 2013 at 14:47

Not the answer you're looking for? Browse other questions tagged or ask your own question.