Topics left undiscussed¶
When writing a guide, you have to select what to discuss and what not. This guide focused on how to develop secure software in an open source software project. I did not include some topics, because they were not really relevant, or other people have done a much better job of explaining them. For yet other topics, there was simply not enough time. Perhaps a future version of this guide will include them. The following topics are related to building secure software, but this guide does not focus on them.
No matter how secure your software is, if users use it insecurely, there is not much that you can do. Security awareness and the field of usable security dive into this.
Since Edward Snowden revealed the modus operandi of some surveillance programs, more people are aware of the need of trustworthy software. Malicious developers who install backdoors in software are a realistic threat. Open source software has the advantage that it is open and can be reviewed by everybody. Detecting software backdoors is a difficult topic. The only advice I can give here, without trying to make you paranoid, is to be vigilant.
The developers on your project may not necessarily be malicious, but bad things can still happen to them. What if their Github SSH keys are stolen, or someone gets access to their computer? The people you trust with sensitive information should be careful with it. In a talk at the 34th Chaos Communication Congress, Stefan Grönke talks about this [Grönke].
The environment in which the software runs influences its security. As an open source software developer, the deployment of software is usually out of your control. The best you can do is tell users in the manual how they should secure their environment in order for the software to work securely.
Secure release and distribution¶
Installing the correct version of the software, and not a tampered copy, is important. There are many caveats when releasing and distributing software. The update framework is a project that has studied secure software updates. It documents the requirements and threats to the process of software updates and provides an implementation [TUF].
Some people tackle their application security problems by installing some appliance or software program that will secure them, or at least, so they believe. These bolt-on solutions have their shortcomings and do not deal with the source of the security problems in the first place. This guide advocates that it is usually better to secure software at the source than to rely on security software.
Privacy may seem like security, but although they are related, they can sometimes be conflicting. As such, they are very different aspects of a system. This guide does not explicitly deal with privacy concerns in your software, but the approach that is sketched in this guide is applicable to privacy as well. If we can find threats to privacy, have a privacy threat library, and we mitigate these threats, we can show how our software deals with privacy sensitive data. The LINDDUN project takes steps in this direction, following a STRIDE-like approach [LINDDUN].