Is that open source project secure (enough)?
Type the words "open source security" into a search engine and you will get dozens of links to articles, blog posts, emails, forum messages, and research papers. You can try to read them all, but I don't think you should bother. The opinions mostly fall under one of the following categories:
- Having access to source code is better than not having access to source code.
- Community-produced software is better than vendor-produced software.
- The freedom to modify source code is a fundamental right of every software user.
- Open source developers are careless, disorganised and fickle.
- Commercial vendors only care about money.
- Who are you going to blame when an open source product fails?
- Open source is dangerous, but you can pay us to help you deal with it.
Most of these claims have a grain of truth in them, but they almost always miss the point in trying to distil complex realities into simple convenient truths. That just doesn't work. The simple truth is that every single project is unique, and must be observed on its own merits. But therein lies the difficulty: how do you determine if a given software product is secure?
I know the proper answer: design an assessment methodology (or use one that already exists—the Software Assurance Maturity Model is nearing completion; Building Security In Maturity Model is expected in a week or so), then use it to make informed decisions. While this approach is suitable for academia, it is too inefficient in real life, where you need to make your decisions quickly and effectively. So what do you do?
Did I mention that I spent almost 6 years of my life working on a fairly popular open source project? In that time I struggled to use my limited resources to do what's best for the project, security being only one of my concerns. I did reasonably well, but made many mistakes along the way. That experience (along with a similar experience in developing closed-source software) has given me an insight into what makes software developers tick and, especially, what makes open source software tick.
So I came up with an idea to avoid measuring the quality of code itself (because that's too difficult and time consuming), instead focusing on the external manifestations of good and bad practices. I call it a Project Security Posture Review. A review might focuses on the following aspects:
- Does the organisation follow good software development practices?
- How are security issues handled?
- Are there any public-facing services available (e.g. source code repository, issue tracking, wiki, etc.)?
- Is the source code tidy?
- Is the project mature and popular?
- Does the project have a reputation for quality?
The idea is that you can answer most of the questions by simply looking at the project's web site, browsing through its code and documentation, and looking at the experiences of other people with it. The obvious advantage of this approach is that it is quick, even though it may be somewhat inaccurate.
If you think the above list is, well, vague—you are absolutely right. I am currently working on a comprehensive list, which I will present during the Open Source Security talk for the Open Source Specialist Group (OSSG) on March 30th.
Update (March 5th): BSSIM is available at http://bsi-mm.com.
