But the monoculture argument still applies even when you are able to reduce the number of security-related bugs. It is not the defect _density_ of the application that counts. If a _single_ security-related bug is found in a networked application in widespread use, then it can be exploited by a worm that will spread through the population like wildfire.
Unless you can eliminate _all_ security-related bugs from your application, then it is still potentially vulnerable, especially if it is connected via the internet to other copies of itself containing the same _single_ bug.
The vulnerability here arises not because of the number of _bugs_, or security vulnerabilities, but because of the number of _interconnections_ with other applications sharing the same bug(s). In a monoculture, worms and viruses can still spread if the number of bugs is small, provided that the number of networked applications sharing these bugs is high.
But what if your Java Virtual Machine implementation contained a bug that meant that under certain circumstances it failed to deny system access to an untrusted Java applet?
If such a bug were discovered in the JVM of a popular browser, it would very quickly be exploited.
Since you cannot prove that any particular JVM contains _no_ bugs, you cannot preclude the possibility of this happening.
The monoculture argument does _not_ rely on assumptions relating to the defect-density or quality of the dominant software application, since even high-quality software will still contain some security-related bugs, and when these bugs are eventually discovered, they will be exploited if the application is in wide-spread use.
Formal methods, although useful, are not a silver bullet for producing bug free code. They may help to reduce bugs, but they cannot eliminate bugs completely.
To quote Frederick Brooks from "No Silver Bullet: Essence and Accidents of Software Engineering"
"Much of the effort in modern programming goes into testing and the repair of bugs. Is there perhaps a silver bullet to be found by eliminating the errors at the source, in the system-design phase? Can both productivity and product reliability be radically enhanced by following the profoundly different strategy of proving designs correct before the immense effort is poured into implementing and testing them?
I do not believe we will find productivity magic here. Program verification is a very powerful concept, and it will be very important for such things as secure operating-system kernels. The technology does not promise, however, to save labor. Verifications are so much work that only a few substantial programs have ever been verified.
Program verification does not mean error-proof programs. There is no magic here, either. Mathematical proofs also can be faulty. So whereas verification might reduce the program-testing load, it cannot eliminate it.
More seriously, even perfect program verification can only establish that a program meets its specification. The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification. "
Slashdot Mirror
But the monoculture argument still applies even when you are able to reduce the number of security-related bugs. It is not the defect _density_ of the application that counts. If a _single_ security-related bug is found in a networked application in widespread use, then it can be exploited by a worm that will spread through the population like wildfire.
Unless you can eliminate _all_ security-related bugs from your application, then it is still potentially vulnerable, especially if it is connected via the internet to other copies of itself containing the same _single_ bug.
The vulnerability here arises not because of the number of _bugs_, or security vulnerabilities, but because of the number of _interconnections_ with other applications sharing the same bug(s). In a monoculture, worms and viruses can still spread if the number of bugs is small, provided that the number of networked applications sharing these bugs is high.
But what if your Java Virtual Machine implementation contained a bug that meant that under certain circumstances it failed to deny system access to an untrusted Java applet? If such a bug were discovered in the JVM of a popular browser, it would very quickly be exploited. Since you cannot prove that any particular JVM contains _no_ bugs, you cannot preclude the possibility of this happening. The monoculture argument does _not_ rely on assumptions relating to the defect-density or quality of the dominant software application, since even high-quality software will still contain some security-related bugs, and when these bugs are eventually discovered, they will be exploited if the application is in wide-spread use.
Formal methods, although useful, are not a silver bullet for producing bug free code. They may help to reduce bugs, but they cannot eliminate bugs completely. To quote Frederick Brooks from "No Silver Bullet: Essence and Accidents of Software Engineering" "Much of the effort in modern programming goes into testing and the repair of bugs. Is there perhaps a silver bullet to be found by eliminating the errors at the source, in the system-design phase? Can both productivity and product reliability be radically enhanced by following the profoundly different strategy of proving designs correct before the immense effort is poured into implementing and testing them? I do not believe we will find productivity magic here. Program verification is a very powerful concept, and it will be very important for such things as secure operating-system kernels. The technology does not promise, however, to save labor. Verifications are so much work that only a few substantial programs have ever been verified. Program verification does not mean error-proof programs. There is no magic here, either. Mathematical proofs also can be faulty. So whereas verification might reduce the program-testing load, it cannot eliminate it. More seriously, even perfect program verification can only establish that a program meets its specification. The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification. "