Participating in CII's Best Practices Program

And why Security by Design Open Source Security matters

Participating in CII’s Best Practices Program

A question I’m often asked by potential users of CAIRIS is, as a tool that supports design for security, how confident are you the tool itself is secure? I usually reply by explaining CAIRIS’ threat model, how we address it (and in some cases don’t), before inviting people to look at the source code of CAIRIS to let people judge the tool for themselves. But security is a process not a product, and sometimes knowing a bit about the practices and infrastructure used to build and maintain a tool can help inspire confidence individuals and companies want before investing time in it.

For this reason, we recently voluntarily self-certified CAIRIS against the Linux Foundation’s Core Infrastructure Initiative Badge Program. Given how prevalent open source software, there is a real need to take a pro-active approach to building security in, not just into the code, but also practices for producing software. The CII was formed in response to Heartbleed, but the initiative is concerned with the security of open source software infrastructures in general.

CAIRIS was developed to complement initiatives such as this by getting people to think about security when software and product designs still live on whiteboards or are just glints in an interaction designer’s or security engineer’s eye, and – like infrastructure – we want people to consider design as code too.

We’re proud to say that, on completing our submission, we were awarded the CII best practices ‘passing’ badge. That makes CAIRIS one of only 119 open-source projects to have currently met the criteria, out of over 1400 registered projects on the scheme.

Does this mean CAIRIS has been independently accredited as being secure or can be considered intrinsically trustworthy? No, but it does provide evidence we take best practice seriously and are transparent about the project’s infrastructure, and our posture when it comes to things like change control, reporting, quality, security, and code analysis. Aiming for the criteria also encouraged us to improve our documentation, contribution guidelines, and even ensure all project sites run over HTTPS. It’s also inspiring us to further improve our project practices and code quality as the CAIRIS community continues to grow.

Finally, if you’re reading this and maintain an open source code base, please consider submitting it to the CII’s badge program too. You may think your code does little more than gather dust on GitHub, but you never know who may end up using it in the future…