Making source code open and reusable
When you create new source code, you must make it open so that other developers (including those outside government) can:
- benefit from your work and build on it
- learn from your experiences
- find uses for your code which you had not found
Making the code open
You should make your code publicly available in an open internet source code repository. For example, GDS’ code is on GitHub. This includes code developed for you by a third party, such as a development agency.
When publishing your code you need to make sure:
- you’re clear about who owns the code and how others can use it
- you do not release information that should remain closed
- you store it in a repository managed by your department
- any third-party tools you use to host or manage your code follow the National Cyber Security Centre’s cloud security guidance
Make your code open from the start
It is much easier to write your code in the open from the beginning of a project than it is to to open an existing repository later, because you can address security and other issues as you go along. If you do not do this, you will have to spend a costly period of time at the end of the project checking your code is all safe to be released.
Coding in the open from the start means you can:
- plan how you’ll avoid publishing sensitive information later in the project
- follow best practices from the beginning, for example keeping good documentation
- set in place processes that will allow you to continuously publish code as it is written
- allow others to identify parts of your code for reuse which you might not have recognised yourself
- allow others to contribute ideas as the project is in progress; for example if they know of existing tools that could help
How to make existing code open
When making existing code open you must review the code to check for:
- security flaws
- inappropriate content, for example rude messages in comments
- good documentation, including good commit messages
You should make the code open while preserving the history as this provides useful documentation. If this is not possible, you may release a snapshot, but this should be a last resort.
Once the code is open you should move to a model where you continue development on the open code, but if you plan to continue to develop your code in a closed way you must explain how you are going to keep the open code up to date.
When it’s acceptable for code to be closed source
There are very few examples of code that must not be published in the open.
The main reason for code to be closed source is when it relates to policy that has not yet been announced. In this case, you must make the code open as soon as possible after the policy is published.
You may also need to keep some code closed for security reasons, for example code that protects against fraud. Follow the guidance on code you should keep closed and security considerations for open code.
You must not store secret keys or credentials in the source code
You must store secret keys and credentials separately, for example with a secret management system, and inject them into the code. This protects the keys from being accessed by unauthorised staff, and makes it easy to provision different keys for different environments and rotate keys if needed.
Making configuration code open
You should publish configuration code. For example, GOV.UK’s Puppet code is coded in the open. However, if you publish the exact versions of software used in the stack, it can be easier for attackers to identify out of date software. Whether your code is open or closed, you must have a plan for how to upgrade or patch software you use.
Making code with a security-enforcing function open
Code that contributes to your service’s security does not need to be kept closed. Many security-enforcing functions, such as cryptographic algorithms, are provably better when openly examined and understood while the keys are kept private. Most cryptographic standards are developed in the open by standards authorities. The US National Institute of Standards and Technology (NIST) recently concluded a 9-year process from open competition to standardisation for the SHA-3 cryptographic hashing algorithm.
Find out more about security considerations for code that is open.
If you’re not sure which parts of your code can be published in the open, talk to a third party that you trust. For example, a technical architect in your department or another government department.
You can find a technical architect by joining the technical architecture community.
Licensing your code
You should publish your code under an Open Source Initiative compatible licence. For example, GDS uses the MIT licence.
All code produced by civil servants is automatically covered by Crown Copyright.
Taking responsibility for open source code
When you make your code open, you should:
- use Semantic Versioning to make it clear when you release an update to your code
- be clear about how you’ll communicate with users of your code, for example on support channels and email lists
Encouraging contributions from people who use your code can help make your code more robust, as people will spot bugs and suggest new features. If you would like to encourage contributions, you should:
- include contributing guidelines
- set time aside to maintain your code
- maintain a public issues list
You might also find it useful to read:
Tracking changes to your code
When your code is open, you must keep track of changes to it using version control.
Services like GitHub make version control much easier. They allow you to track issues and read documentation alongside your code so you understand what has changed and why.
Dealing with security issues in published code
If you find a security issue in your code after you’ve published it, you need to be able to deploy fixes quickly without disclosing too much information about the vulnerability until you’ve dealt with it.
Fixing security issues in public copies of the code does not work for every team. It’s possible to use scripts to switch between private and public copies of the code to manage fixes securely.
You should follow the specific security policies in your team or organisation as well as general security best practices for dealing with vulnerabilities quickly.
Related guides
You might also find these guides useful:
- Last update:
-
Added more guidance on security in response to user feedback and input from cross-government technology community.
-
Guidance first published