Coding in the open updates

using-github/coding-in-the-open.md

@@ -0,0 +1,50 @@
+# How to Meet Section 12: Make New Source Code Open (MOD / GOV.UK Standards)
+
+This guidance explains how teams can meet [**Section 12 – Make New Source Code Open**](https://www.digital.mod.uk/service-manual/meet-the-standard), following both the GOV.UK Service Standard and Defence‑specific considerations from the MOD Service Manual.
+
+## 1. Why this matters
+
+- **Public value**  
+  New source code created with public funds should be open by default—this maximises reuse, reduces duplication, and supports transparency and cost-efficiency across government.
+
+- **Defence-specific constraints**  
+  Defence teams should open code when appropriate, but withhold publishing code relating to SECRET or TOP SECRET systems or content that hasn't been publicly announced.
+
+## 2. What "make source code open" means
+
+### GOV.UK expectations
+
+- Write code in the open from the start, using a public repository—but never include secrets like API keys or credentials.
+- Always retain IP ownership of your service’s new code and license it openly (e.g., MIT or another Open Source Initiative–compatible licence).
+- If code must remain closed (e.g., unreleased policy or sensitive security mechanisms), provide a strong rationale—but open it as soon as permissible.
+
+### Additional GOV.UK technical guidance
+
+- Host code publicly (e.g., GitHub), ensuring departmental control and compliance with cybersecurity standards.
+- Avoid embedding secrets—manage them using secure secret-management systems.
+- Open configuration code, database schemas, and even security‑enforcing code (cryptographic or authentication logic) unless there's a specific reason—noting that openness often strengthens security.
+- Use a clear open-source licence, handle versioning (e.g. Semantic Versioning), provide contributing guidelines, manage issues, and encourage community contributions.
+- Track changes via version control and prepare to manage security vulnerabilities in public code responsibly.
+
+## 3. Defence (MOD)‑specific enhancements
+
+- **Do open code where possible**—unless the code deals with SECRET or TOP SECRET elements.
+- **Ensure classification awareness**: assess which parts of the codebase are sensitive and only withhold those as necessary, with intent to open once safe.
+
+## 4. Summary: Step‑by‑Step Guidance
+
+| Phase         | Actions                                                                 |
+|---------------|-------------------------------------------------------------------------|
+| **Planning**  | - Define IP and open licensing (e.g., MIT) <br> - Choose open repo tool within Defence and compliant with cyber policy |
+| **Development** | - Code openly from day one<br> - Exclude secrets and credentials (use secret management)<br> - Write clear documentation and commit history |
+| **Security Review** | - Conduct security checks before publishing<br> - Remove sensitive content and confirm what may remain closed (e.g., unreleased policy or SECRET parts) |
+| **Publishing** | - Release code publicly under an open licence<br> - Include versioning rules, contributing guidelines, issue tracking |
+| **Ongoing Management** | - Continue development openly<br> - Maintain version control and handle issues transparently<br> - Monitor and promptly patch security vulnerabilities |
+
+## 5. Tips & Best Practices
+
+- **Open by default, closed only for strong reasons** – and open as soon as those reasons no longer apply.
+- **Plan for openness from the start** – reducing the burden of retrospectively sanitising code.
+- **Favour openness even in security‑critical modules** – properly designed open cryptographic code can be more robust.
+- **Use secure development workflows** – store code in trusted repositories, manage secrets separately, and structure your release process to accommodate open-source norms.
+- **Provide clear governance** – licences, versioning, contribution policies, and response channels for external collaborators.

using-github/creating-a-contributing-file.md

@@ -4,7 +4,7 @@
 
 The CONTRIBUTING.md is the file that users will normally read before contributing to a project and it must provide them with the information needed to contribute to the project in a style which the owner wants. The CONTRIBUTING.md allows the owner to specify the standards and processes they want contributors to use thus setting the rules for everyone, including the rules for how the owner treats contributors. The CONTRIBUTING.md is written in [Markdown](https://en.wikipedia.org/wiki/Markdown) and placed in the root directory of the repository.
 
-If a repo does not have a CONTRIBUTING.md then we do not class it as "open" and the owner may not want external contributions.
+It is important to understand that contributions are not always in the form of code. Make sure that you specify how you wish people to interact and contribute through this file and how they will go about doing this.
 
 ### Must Have
 

using-github/readme.md

@@ -1,5 +1,7 @@
 # Our guidance for using GitHub
 
+We should be adhering to the MoD digital service manual and [point 12](https://www.digital.mod.uk/service-manual/meet-the-standard) states that we should be making new source code open. This is an extension of the [GDS guidelines](https://www.gov.uk/service-manual/service-standard/point-12-make-new-source-code-open) in which they talk about [what should be open and what should be closed](https://www.gov.uk/government/publications/open-source-guidance/when-code-should-be-open-or-closed). There is the additional care to be taken with [security classifications](https://www.digital.mod.uk/service-manual/security-classifications) and commercial protections however we should opt for a Public repo on creation unless agreed upon in threat modelling that a closed repo is required.
+
 ## Background
 
 This repository is to provide guidance on what must exist in open repos as a minimum with the aim of enabling people to feel familiar when browsing, find information and to become productive if contributing back.
@@ -11,9 +13,13 @@ All open repos must contain the following:
 * **A CONTRIBUTING.md within the root folder.** The file is a marker to people that this repo will accept changes from outside of the team. It must contain the processes that the owner of the repository needs people to follow when contributing to the project. [Guidance on how to write a CONTRIBUTING.md](creating-a-contributing-file.md).
 
 * **A LICENSE within the root folder.** This will be MIT in most cases. Having a license is critical as it states what others are allowed to do with the code.
+
 * **A README.md within the root folder.** This must contain some basic useful information for the user allowing them to quickly understand the project and get started using it. It isn't the place for extensive documentation. [Guidance on how to write a README.md](creating-a-readme-file.md).
 
-* **A continuous integration build process.** Each time a pull request is submitted a build is triggered which will run all the tests to ensure the change does not break any features. This will also give the contributor feedback and confidence that their code will work!
+> [!IMPORTANT]
+> An empty readme does not provide any useful information to ourselves, the reader or future maintainers. Please do not create the file just to tick a box.
+
+* **A continuous integration build process.** Each time a pull request is submitted a build is triggered which will run all the tests to ensure the change does not break any features. This will also give the contributor feedback and confidence that their code will work! This also supports in keeping your services up to date with dependency and vulnerability updates.
 
 Above is the minimum for what an open repo must contain, other useful things a repo may contain:
 
@@ -36,6 +42,18 @@ Above is the minimum for what an open repo must contain, other useful things a r
 
 All open repos must be using git and code contributions should be made using the standard Fork and Pull Request approach (or equivalent). [Guidance on how to make a pull request](pull-request-details.md).
 
+## Tooling
+
+All public repos will need to have the following tooling run against them to ensure that we are protecting ourselves:
+
+* SAST Tooling
+* SCA Scanning
+* Container Scanning (where applicable)
+* Infrastructure as Code scanning (where applicable)
+* Code quality scanning
+* Dependency/Vulnerability update checks (Dependabot or similar)
+* Pre-commit secret checks (GitHub advanced security)
+
 ## Terminology
 
 ```Contributing``` - This is more than just adding code, this also includes creating issues/bug reports, asking questions, improving documentation.