Skip to main content

EUCS IDAM - Working in the Open

Using version control and source control methodologies is essential for maintaining code and documentation for our services across Tech Services. MoJ has selected GitHub as the common place for digital teams to store their code and documentation

In order to ensure our use of GitHub is secure, we should follow the GDS Service manual and CDDO guidelines for working in the open.

Working in the Open

Working in the open should be our default position when creating code. We should not rely on closed code as a security measure. We should instead use countermeasures such as “defence in depth”.

If the only countermeasure is the code is closed (internal/private) then this has a tendency to increase the chances that other appropriate security measures for the service are not in place, should that repository be accidentally exposed.

Working in the Open is an already established Government strategy that has been defined and refined. We should not look to rewrite what has already been written, but ensure we meet the same standards and practices as other Government agencies.

To provide context on this stance, this document will reference a range of existing Government standards that should be followed. It will not replicate the text from the resources provided, it will instead summarise the links to which you should read and adhere too.

Making code Open Source - Service Standard 12

Reference: 12. Make new source code open - Service Manual - GOV.UK

This document gives a high level overview about why it’s important and what making code Open Source means.

Technology Code of Practice (TCoP) - Be open and use open source

Reference: Be open and use open source - GOV.UK

Point 3 of the TCoP requires you to publish your code and use open source where possible. This document delves a little deeper on why this is important, including the ability for others to contribute and share resources across MoJ and wider Government.

Making source code open and reusable

Reference: Making source code open and reusable - Service Manual - GOV.UK

This document goes into greater detail about how to make your code open and when you should or shouldn’t. It also provides guidance to help decide on whether your repository should be internal or private. It covers areas such as secrets and credentials, security enforcing functions and configuration as code.

When code should be open or closed

Reference: When code should be open or closed - GOV.UK

An additional document to the previous can be found at the link above. This covers in further detail what should be closed code, what should not.

GDS & CDDO Security considerations when coding in the open

Reference: Security considerations when coding in the open - GOV.UK

This document covers considerations you should explore when creating code. This includes security measures, credentials, vulnerability management and compromised scenarios with links to further resources that can help.

GitHub Teams

It is important that any repositories created are not owned by individuals. People come and go and if repositories are not properly owned and governed, services can be left without ownership incurring technical debt and security vulnerabilities. As such repositories should also be owned by service teams and not individuals with all team members onboarded to understand how repositories work.

In order to maintain the correct ownership of our repositories, we should ensure Tech Services teams are assigned correctly to the repositories and each repository is setup with a baseline of security and metadata.

Each Tech Services team should have their architects/engineers/developers assigned to their appropriate GitHub Teams. These teams are assigned to their owned repositories with the appropriate level of access. This allows new team members to be added automatically to all repositories for that team when they start and ensure once someone leaves the organisation, their access is revoked.

Section Contents

Resources