There are two big concerns government organisations have around making source code open. They want to know which subsets of the code should be kept closed and how to code in the open securely. To address these questions I’ve introduced two pieces of guidance:
Both pieces of guidance are based on industry standards and have been reviewed by the GDS security engineering team as well as government colleagues from National Cyber Security Centre, Department for Work and Pensions, Home Office and Ministry of Justice.
We previously blogged about what code not to open in our post: 'When is it ok not to open all source code?', but as guidance, it is no longer relevant as our approach to specific areas such as configuration have changed. For example, last year we made GOV.UK's Puppet repository publically available on GitHub.
We’ve also evolved our thinking on security. The previous guidance discouraged people from sharing code that had anything at all to do with security. It didn’t take into account that coding in the open can actually make code more robust as it helps you design with security in mind.
The new guidance addresses why open sourcing code that performs a security-enforcing function is beneficial. In simple terms, we can compare coding in the open to how padlocks work. Everyone knows how padlocks work but they are still secure because you cannot open them without the key. Security enforcing software works in the same way, and good cryptographic algorithms are reviewed by many professional peers. Security is improved through public review.
We still specifically seek peer review on open code and subject our code to penetration testing, as part of following security design principles.
Most of the code produced by GDS has been coded in the open from the beginning. Some services started closed source, and to ensure that we are practicing what we preach, we are now opening those: we have recently completed open sourcing GOV.UK Pay and we are working on opening up more components of GOV.UK Verify.
This new guidance will make it easier for your organisation to develop and deploy secure and open services, and should address your concerns around coding in the open securely.
This post originally appeared on the GDS technology blog.