This guide takes you through the world of software security, and discusses what you can do in your open source software project to ensure a more secure piece of software. What is even better is that you can be open and transparent about the security of your project, so that it is easier for people to verify whether the software’s security matches their needs, or to encourage people to adapt the software to different security needs. Making security visible will help the world to use software that is more secure.
This guide will not tell you how to deal with specific vulnerabilities or security problems. For that, plenty of books and web sites exist. Instead, we will focus on security practices that you can integrate into your development process. So let’s get started!
The need for secure software¶
As our society becomes more dependent on software, the need for software security becomes more apparent, mostly because we see that security is lacking in many software products. This is because:
users do not explicitly ask for security (i.e. for the developer it is not a requirement),
developers lack security awareness and knowledge,
the speed to market makes security a low priority,
software developers are not liable for defects, so it is not their problem.
All these reasons make sense for each party, but together, they cause a difficult problem. Users often have security expectations of software, but they do not know how to phrase them. They may not be aware of what can go wrong or they may not understand it. Most software developers have never learned secure software development, although this is changing. Getting software to the market quickly makes sense from a business point of view, otherwise a competing product conquers the market. And if software developers would be liable for their mistakes, software would cost a lot more.
In open source projects, the situation is similar. Speed to market may be less important, but if your project is idle for too long, users may move away to other software. Developers often work for free and can only spend little time on a project. ‘No liability’ is a key part of any open source license, and holding open source software developers liable for their mistakes would be unfair.
The conditions for secure open source software projects may in fact be worse than for secure proprietary software. Yet most users of open source software believe that it is more secure than proprietary software [OSSSurvey2017] 1. A big reason for that is the belief in Linus’ Law [WikipediaLinusLaw], which states that if enough people review software, bugs will be found quickly. Another reason is that ‘security through obscurity’, i.e. relying on keeping the design or implementation secret, does not work [WikipediaObscurity].
In practice we see that open source software is just as insecure as proprietary software, A famous example is OpenSSL, which you would expect to be secure, since security is one of its core features [CII3Years]! For security bugs, Linus’ Law does not apply [LinuxBugsNotShallow]. There are not enough ‘eyeballs’ and security, by its very nature, is invisible. In short, OSS projects need software security just as much as proprietary projects, and the key is to make security visible.
Structure of this guide¶
In this guide, we give you a short introduction to software security and some practices to help you make your software more secure. Since every project, proprietary or open source, has its own development process, I cannot give any specific advice for your particular project. Instead, you will have to find a way to integrate these (or similar) practices into your development process.
In this text, I may use some jargon typically used in agile software development methods. This does not mean that you will have to adopt an agile way of working. In fact, I will try to be as methodology neutral as possible, but instead of trying to invent a generic term, I have chosen to use the term that I am most familiar with. I am sure you can find an equivalent concept in the methodology that you know best.
I will first describe how you can define what ‘security’ actually means for your project. Then, we will look at how we can use that definition to write secure software. Next, we discuss some security practices to use in the software development lifecycle (SDLC) and how to integrate them in your way of working.
Reading this guide may bombard you with a lot of new information. You may want to read only the summary of some of the chapters and get back to them later. After reading this guide, you may feel that it is infeasible to follow up all the advice in this guide. Here is some good news: you do not have to. Select practices wisely, and improve your software’s security one little step at a time. Automation is another way to reduce the amount of work, and we are slowly seeing more tools to automate much of the work. Do not let security practices hamper your development process too much. After all — and this is difficult to admit for security people —, having software that does the job is still more important than having it secure.
About this guide¶
This guide is part of the best practices documents for projects supported by the NGI Zero initiative.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.