Storing Code in Private and Internal Repositories: A Do’s and Don'ts Guide
Introduction
This document aims to outline the guidelines and best practices for developers to store their source code in private and internal repositories. Private repositories are exclusive to your team or project, whereas internal repositories are accessible to anyone within the organisation.
Do’s
These practices will help you maintain the integrity and security of private repositories and provide guidelines on when to make a repository private
✅ Go Private for Keys and Credentials
Make sure secret data such as keys or credentials are kept closed, as this information could allow someone to gain access to your system. when code should be open
✅ Go Private for Fraud Detection Algorithms
Algorithms used for fraud detection should remain private. Additionally, separate any code that utilises these algorithms from the algorithms themselves. when code should be open
✅ Go Private for Unreleased Policy
If the code makes clear details of a policy that has not yet been announced, you should keep the code closed until the policy is announced. when code should be open
✅ Publish Code and Data Early
Start sharing your code and data from the beginning of your project to encourage collaboration, clearer documentation, and a more maintainable codebase. be and use open by default
✅ Implement Security Measures for Sensitive Data
Ensure clarity around data that needs to remain protected and implement measures to achieve security. be and use open by default
✅ Separate Secrets from Source Code
Always keep secrets, keys, and sensitive information out of the source code. secrets in code
✅ Provide Clear Documentation
Ensure that there’s enough documentation for someone new to get started with the project. documenting your code
✅ Be Mindful of GitHub Action Usage
Running GitHub Actions against both private and internal repositories counts towards our organisation’s overall GitHub Action usage limits. For this reason it is important to regularly review your GitHub Action estate on private and internal repositories, to ensure you’re not running unnecessary or unneeded checks.
✅ Follow Good Development Practices
Use clear commit messages, comprehensive documentation, code reviews, automated tests, and style enforcement. development principles
✅ Keep Dependencies Up to Date
Whether your configuration code is open or closed, make sure to update your dependencies to prevent vulnerabilities. be and use open by default
✅ Use Third-Party Libraries for Authentication
Consider leveraging third-party libraries for authentication as they will likely be more secure and robust. be and use open by default
✅ Utilise Security Scanning Tools
Make use of tools like Brakeman, Sonarcloud, and Talisman to supplement manual code reviews. security considerations for open source software
✅ Have Mechanisms to Change and Rotate Keys
Be prepared to change and rotate keys and credentials easily if accidental disclosure occurs. security considerations for open source software
✅ Address Security Vulnerabilities Swiftly
Follow specific and general practices to deal with vulnerabilities quickly, including emergency fixes if necessary. security considerations for open source software
Don'ts
❌ Do Not Make Private Repositories Public Without Review
Before converting a private or internal repository to public, ensure there’s no sensitive data in the commit history. secrets in code
❌ Avoid Closed Source When Possible
If possible, consider using open source solutions instead of closed source, as open source often provides more flexibility and collaboration opportunities. private repositories
❌ Do Not Ignore Security Practices
Always consult with the security team and follow best practices for handling sensitive data. security considerations for open source software
❌ Do Not Rely on Closed Code as a Security Measure
Use multiple countermeasures to keep your system secure, known as the ‘defence in depth’ approach. You should not rely on keeping code closed to keep it secure. security considerations for open source software
❌ Forking Private and Internal Repositories
Forking private and internal repositories is prevented at an organisational level across bot moj-analytical-services and ministryofjustice orgs. This is to prevent the accidental exposure of information into the public domain. security considerations for open source software
Moving from Private or Internal to Public
You may be in a situation where you want to make your source code open to the public after it was kept private. An important consideration here is to ensure no sensitive data has been left in the commit history - while the code may have changed to mitigate this, commit history retains this information.
You can follow this guide to scrub your git history and remove sensitive data, however it’s recommended to talk to security and data teams before proceeding.
Some other considerations:
- Evaluate readiness to engage with the broader community and the possibility of external contributions.
- Ensure all stakeholders are aligned on the decision to move from private/internal to public.
- As the repository will become part of MoJ’s public domain, you may need to re-evaluate its standards compliance.
More information can be found in this guide.