Secure Software Development: CII Best Practices

Last month the Core Infrastructure Initiative, or CII, launched their CII best practices project (now OpenSSF Best Practices Badge Program). Its primary goal is to gamify the process of building more secure software. Let’s have a look at the project, and how it can help.

Open Source and Security

If we look in the open source world of software, we see that many projects were created by volunteers. While doing this voluntary, this doesn’t say anything about the quality of the project. After all, half of the internet exists because of these small, yet powerful utilities. I personally created two projects myself: Rootkit Hunter (rkhunter) to detect malware, and Lynis to perform a security audit on Linux and UNIX systems. While these tools are focused on security, it is definitely not simple to make software itself secure. This is where a project of CII comes in, to provide a checklist of items to enhance the project and its quality.

Why Best Practices?

The last few years a lot of serious vulnerabilities have been discovered, like Hearthbleed, POODLE, and GHOST. The supporting organization behind CII is the Linux Foundation. They support projects which are considered to be critical for the open source community, and our society in general. With the core infrastructure initiative, they go a step further by allowing all software projects to perform a self-audit.

Best practices are considered to be steps and actions that are commonly accepted as good things to do. For example, when dealing with sensitive data on your website, that you make your website available via HTTPS. This ensures that the transfer of data is encrypted, increasing security for your visitors. As you can imagine, there is usually a huge list of best practices available for most activities, including software development.

Example: Lynis

For our auditing tool Lynis we applied to get a badge as well, to show that we are committed to do the right things. We are a security tool after all, right? So a few weeks ago we started the process. The first step is creating an account and providing some basic details about the project, like the name and website. From there on you directly move on to the specific best practices.

The CII project performs some testing, but mostly relies on you answering the questions honestly. Most questions might sound very obvious, like if there is a page which describes what the tool does. Still, as part of daily research I come across projects which don’t clearly describe that. So it is a good thing that these basic questions are asked to trigger the developer to think outside the technical boundaries of the project. After all, software is created for the users.

Doing secure software development means more than checking for buffer overflows. So CII asks questions about:

• Documentation (in English)
• Usage of HTTPS
• Selected license
• Version numbering
• Changelog

As you can see, from these first five items, only one is related to security. The others are more generic ways of testing the quality of a project. Not having a changelog file to describe the changes, is something to be considered bad by users. After all, you want to see what is changed and in what particular version. We went actually a step further and renamed our “CHANGELOG” to “CHANGELOG.md”, and added markdown to it. This way people can still read the log like before, but it is also rendered by sites like GitHub. A more visual attractive log file, and another improvement for quality of the project.

The best practices project has the following categories of tests:

• Basics
• Change Control
• Reporting
• Quality
• Security
• Analysis
• Future

By following each category, a list of questions and requirements is displayed. It is up to the “auditor” to provide an answer, or define if the requirement is met. In some cases you can mark an item as non-applicable and describe why that is. If you satisfied all the requirements, you are rewarded with a badge.

Lessons Learned

During the process of obtaining the CII best practices trophy badge, we actually learned more about our own project. For example, we are very strict when it comes to simplicity, as we want to make our software easy to use. On those areas, we had multiple questions which were easy to score. When it comes to code quality, things became a little bit harder to answer. The CII project assumes that most software projects are written with C++, or languages like Python. This is true, except for Lynis. With shell script things are a little bit different, so we had to answer to the best of our knowledge.

A big improvement, which we already had under discussion, was the usage of unit tests. With our new Lynis software development kit, we introduced quality testing (e.g. unit tests, code linting). Especially regarding unit testing we are now looking to improve in this area, to do more tests. Also we trigger these unit tests now automatically, when a pull request comes in. This is done with Travis CI, and ensures that the quality of the code is as high as possible.

Conclusion

What I like the most of the CII best practices project is the same approach it has like Lynis. Both measure quality and the next possible actions to take. The CII best practices project is therefore a great addition to the world of open source software. It helps software projects to question themselves if they are doing the right things. Having good functionality in your software project is a good start. What makes a project truly great, is when users have a great experience along the way. From the first time they visited the project website, to achieving their goals with the software. Getting everything right, including the “invisible” things, is difficult for most developers. The best practices project helps to make them visible, so the developer can improve the open source project step by step. This results in higher quality software, benefiting all of us.