Even between the true-blue penguinheads, we have a disagreement over where Linux ends and the applications start.
The overly-simplistic software stack looks something like this:
- Kernel
- Basic filesystems
- System libraries
- System programs
- Userland libraries
- Userland programs
Yes, this is my simplified model of the world, and I like it that way for the time being. It has it's problems: for instance, is the Bourne Again Shell (bash) a userland or system program? But my model is more of a spectrum of software, so think along those lines for a moment.
The trick to all this is to try to draw a line somewhere along this spectrum where Linux ends and the applications start. It's hard to do. If you look at most of the packages contained in the average Linux distribution, only a small percentage can really be called the core OS. The rest should be in the group that you call applications. If the applications are written correctly and in true Unix fashion, they can be compiled and built on Linux or any other Unix variant or work-alike.
Now the reason I'm bringing this up is because there is a simple fact when it comes to security in Linux and OSS projects: we have a huge dependency on the various applications which are in various states of production-quality code.
Unless I get the installation package from the distribution vendor, I don't really have much of a guarantee, and even then, it's questionable and I really have to assess each piece of software individually.
Yes, I can look at freshmeat.net and the keys of vitality, popularity, and current version to get a feel for the trustworthiness of the software, but anything above and beyond that is a judgement call, what I would even call "black magic" when it comes to picking one piece of software over another, functionally or security-wise.
In acknowledgement of this fact, The Department of Homeland Security announced a contract award to Coverity in January 2006 to perform code vulnerability scanning for open-source projects. The result of that contract is the scan project available at http://scan.coverity.com/index.html.
There was quite a bit of press at the time, but not much since then. The Scan project has been quietly scanning software code and providing support to the open-source projects. The project completed its first year, and the results are pretty good stats-wise.
Keeping in mind that code scanning is not completely foolproof, Scan is a step in the right direction. Where do we go from here? This is my tentative roadmap for what I need as a CISO:
- More projects moving up the Scan ladder
- More awareness of Scan and its accomplishments around the security and management circles
- Integration of Scan with other IA mechanisms (Common Criteria comes to mind, but there are others) and community information sites like freshmeat.net
- Preference of higher-rung projects over "competing" software
- More defense in depth with other application security techniques such as overflow protection libraries
