From 19836ae4cb4f7a86e099141e326dd0ce0c782e5e Mon Sep 17 00:00:00 2001
From: Paul King <6100643+gyro2009@users.noreply.github.com>
Date: Wed, 10 Jun 2026 11:34:31 +0100
Subject: [PATCH 1/3] Cleanup of policies in the Security folder

---
 .../CvssScoringMetrics.md                     | 59 ------------
 .../ManagingSecurityConcerns.md               | 89 +++++--------------
 .../SecurityChampionResponsibilities.md       |  8 +-
 software-engineering-policies/README.md       |  2 +-
 4 files changed, 26 insertions(+), 132 deletions(-)
 delete mode 100644 security/ManagingSecurityConcerns/CvssScoringMetrics.md

diff --git a/security/ManagingSecurityConcerns/CvssScoringMetrics.md b/security/ManagingSecurityConcerns/CvssScoringMetrics.md
deleted file mode 100644
index e62c7a4f7..000000000
--- a/security/ManagingSecurityConcerns/CvssScoringMetrics.md
+++ /dev/null
@@ -1,59 +0,0 @@
-# CVSS Scoring Metrics
-
-- [CVSS Scoring Metrics](#cvss-scoring-metrics)
-  - [Exploitability Metrics](#exploitability-metrics)
-    - [Attack Vector (AV)](#attack-vector-av)
-    - [Attack Complexity (AC)](#attack-complexity-ac)
-    - [Privileges Required (PR)](#privileges-required-pr)
-    - [User Interaction (UI)](#user-interaction-ui)
-    - [Scope (S)](#scope-s)
-  - [Impact Metrics](#impact-metrics)
-    - [Confidentiality (C)](#confidentiality-c)
-    - [Integrity (I)](#integrity-i)
-    - [Availability (A)](#availability-a)
-
-## Exploitability Metrics
-
-The five Exploitability Metrics capture how the vulnerability is accessed and whether or not extra conditions are required to exploit it.
-
-### Attack Vector (AV)
-
-This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the Base Score) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable component. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater
-
-### Attack Complexity (AC)
-
-This metric describes the conditions beyond the attacker’s control that must exist in order to exploit the vulnerability. As described below, such conditions may require the collection of more information about the target, or computational exceptions. Importantly, the assessment of this metric excludes any requirements for user interaction in order to exploit the vulnerability (such conditions are captured in the User Interaction metric). If a specific configuration is required for an attack to succeed, the Base metrics should be scored assuming the vulnerable component is in that configuration. The Base Score is greatest for the least complex attacks.
-
-### Privileges Required (PR)
-
-This metric describes the level of privileges an attacker must possess *before* successfully exploiting the vulnerability. The Base Score is greatest if no privileges are required.
-
-### User Interaction (UI)
-
-This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable component. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner. The Base Score is greatest when no user interaction is required.
-
-### Scope (S)
-
-The Scope metric captures whether a vulnerability in one vulnerable component impacts resources in components beyond its *security scope*.
-
-Formally, a *security authority* is a mechanism (e.g., an application, an operating system, firmware, a sandbox environment) that defines and enforces access control in terms of how certain subjects/actors (e.g., human users, processes) can access certain restricted objects/resources (e.g., files, CPU, memory) in a controlled manner. All the subjects and objects under the jurisdiction of a single *security authority* are considered to be under one *security scope*. If a vulnerability in a vulnerable component can affect a component which is in a different *security scope* than the vulnerable component, a Scope change occurs. Intuitively, whenever the impact of a vulnerability breaches a security/trust boundary and impacts components outside the security scope in which vulnerable component resides, a Scope change occurs.
-
-The security scope of a component encompasses other components that provide functionality solely to that component, even if these other components have their own security authority. For example, a database used solely by one application is considered part of that application’s security scope even if the database has its own security authority, e.g., a mechanism controlling access to database records based on database users and associated database privileges.
-
-The Base Score is greatest when a scope change occurs.
-
-## Impact Metrics
-
-### Confidentiality (C)
-
-This metric measures the impact to the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones. The Base Score is greatest when the loss to the impacted component is highest.
-
-### Integrity (I)
-
-This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. The Base Score is greatest when the consequence to the impacted component is highest.
-
-### Availability (A)
-
-This metric measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of *data* (e.g., information, files) used by the impacted component, this metric refers to the loss of availability of the impacted component itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of an impacted component. The Base Score is greatest when the consequence to the impacted component is highest.
-
-More information on the CVSS score metrics can be found on the [specification document here](https://www.first.org/cvss/v3.1/specification-document).
diff --git a/security/ManagingSecurityConcerns/ManagingSecurityConcerns.md b/security/ManagingSecurityConcerns/ManagingSecurityConcerns.md
index a50c9f6ee..cabaa0b2a 100644
--- a/security/ManagingSecurityConcerns/ManagingSecurityConcerns.md
+++ b/security/ManagingSecurityConcerns/ManagingSecurityConcerns.md
@@ -10,25 +10,25 @@
     - [Implement](#implement)
     - [Monitor](#monitor)
     - [Changes and New Features with a Security Impact](#changes-and-new-features-with-a-security-impact)
-  - [Common Vulnerability Scoring](#common-vulnerability-scoring)
-    - [Base CVSS Score Metrics](#base-cvss-score-metrics)
-  - [Recording the CVSS Risk Assessment](#recording-the-cvss-risk-assessment)
-    - [Example: Service Account Credentials are Stored in Plain Text within Config File](#example-service-account-credentials-are-stored-in-plain-text-within-config-file)
   - [Raising a Security Concern](#raising-a-security-concern)
     - [Example](#example)
   - [Prioritising and Fixing Security Concerns](#prioritising-and-fixing-security-concerns)
 
 ## Introduction
 
-Security concerns are any issues that are related to the security of our applications. They may be items identified by the team during development, as part of formal penetration testing, by static analysis (such as the Dependency-Check tool) or reading security bulletins.
+Security concerns are any issues that are related to the security of our applications. They may be items identified by the team during development, as part of formal penetration testing, by analysis tooling (SAST. DAST, SCA, IAC or Container scanning) or reading security bulletins.
 
 To help ensure the security of applications, this process provides a common process to help manage all security concerns related to UKHO software.
 
 ## Managing a list of current Security Concerns
 
-Every software development team will keep a **prioritised** list of **current security concerns**. This list should be stored in the same work item tracking system that the team uses for bugs and general work (usually Azure DevOps) and identified using a standardised Tag of **Security Concern**.
+Every software development team will keep a **prioritised** list of **current security concerns**. This list should be stored in the same work item tracking system that the team uses for bugs and general work (usually Azure DevOps) and identified using a ticket type of Risk with a tag of Security.
 
-Each security concern requires a risk assessment and the Security Advisor will ensure that an initial risk assessment will be carried out within 2 working days of the concern being raised (although this may be carried out by another team member on their behalf). This should give the Security Concern a standard Common Vulnerability Scoring System (CVSS) score (see Common Vulnerability Scoring below for details). Security Concerns that score 7.0+ (High) will be highlighted with the IT Security Team.
+Each security concern requires an assessment and the Security Champion or Lead Technical Software Engineer (Security) will ensure that an initial assessment will be carried out within 2 working days of the concern being raised (although this may be carried out by another team member on their behalf). This should give the Security Concern a standard scoring using the Inherent, Residual and Target risk measures.
+
+> - Inherent Risk: Baseline risk before any preventative measures taken
+> - Residual Risk: Remaining risk after mitigations are in place
+> - Target Risk: The risk appetite your team/application/product is willing to accept
 
 Every sprint, the list of current security concerns should be reviewed by the team and all new security concerns should be highlighted as part of the sprint review.
 
@@ -51,14 +51,14 @@ Additionally, each concern should be assessed to determine if additional trainin
 
 ### Risk Assessment
 
-- Given a CVSS risk assessment score.
+- Given a risk assessment score.
 - More in-depth risk assessment as required, for example research online.
 
 :arrow_down:
 
 ### Prioritise Fix
 
-- Team works in conjunction with the IT Security Team and Product Owner to prioritise and schedule a fix.
+- Team works in conjunction with the IT Security Team, Product Owner and relevant Security Champions to prioritise and schedule a fix.
 
 :arrow_down:
 
@@ -66,6 +66,7 @@ Additionally, each concern should be assessed to determine if additional trainin
 
 - Team implements a fix for the security concern.
 - The fix is deployed and tested.
+- Any testing tools that indicated an issue are to retest the issue to ensure this has been resolve or that new issues are not being presented. 
 
 :arrow_down:
 
@@ -79,58 +80,14 @@ During development, a team will make some changes that will have a security impa
 
 ------
 
-## Common Vulnerability Scoring
-
-To provide a standard and quick way to characterise a security concern, every security concern will be scored using the NIST Standard Scoring for security concern assessment. An online calculator to assist the scoring can be [found here](https://www.first.org/cvss/calculator/3.1).
-
-To provide a common risk severity, scores are mapped as follows:
-
-| Severity | Base Score Range |
-| -------- | ---------------- |
-| Low      | 0.1-3.9          |
-| Medium   | 4.0-6.9          |
-| High     | 7.0-8.9          |
-| Critical | 9.0-10.0         |
-
-### Base CVSS Score Metrics
-
-The CVSS v3.* score we are interested in are the Base Score Metrics (Exploitability Metrics & Impact Metrics). Although useful, the Temporal Score or Environmental Score are not required for initial assessment of a security concern.
-
-The base metric group captures the characteristics of a vulnerability that are constant with time and across user environments.
-
-A reference guide to the CVSS Scoring Metrics can be [found here](./CvssScoringMetrics.md).
-
-## Recording the CVSS Risk Assessment
-
-To ensure that it is clear why a security concern has been given a score, the details for each metric selected should be recorded in the work item tracking system (Azure DevOps) along with a short description of why. To aid clarity of the calculation of the score, include the CVSS v3 Vector from the calculator.
-
-### Example: Service Account Credentials are Stored in Plain Text within Config File
-
-| Exploitability Metric | Rating    | Description                                                  |
-| --------------------- | --------- | ------------------------------------------------------------ |
-| Attack Vector         | Adjacent  | The attacker needs to be within UKHO network and exploit the vulnerability through other means e.g. Access to Azure DevOps. |
-| Attack Complexity     | Low       | Stored in a plain text file - File can be opened to access credentials. |
-| Privileges Required   | High      | Needs internal access to the UKHO network and an account that can access the source repository. |
-| User Interaction      | None      | No user interaction is required to access the config file.   |
-| Scope                 | Unchanged | Principle of least privilege ensures the scope remains unchanged. |
-| Integrity             | None      | Integrity of information is not changed.                     |
-| Availability          | High      | Having access to the service account could impact service availability i.e. changing the service account password. |
-
-Overall score: 5.2 (Medium) CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:H
-
-------
-
 ## Raising a Security Concern
 
-Once a security concern has been identified, it should be raised in the team's backlog. The bug should have the following characteristics:
+Once a security concern has been identified, it should be raised in the team's backlog. The Risk should have the following characteristics:
 
-- Tagged with **Security Concern**.
-- Title starts with **Security Concern**.
+- Tagged with **Security**.
 - Title contains detail such as the service name and type of security issue.
-- CVSS score should be included in the title.
-- The CVSS severity should be included as a tag. For example if the severity is high, tag as **Severity - High**
 - Include a detailed description of the security concern e.g. Services affected.
-- Bug should contain steps to reproduce the issue (if possible).
+- Risk should contain steps to reproduce the issue (if possible).
 - Detail information on key stakeholders (such as the service owner).
 - Any conversations relevant to the issue should be recorded in the comments section.
 
@@ -138,20 +95,18 @@ Once a security concern has been identified, it should be raised in the team's b
 
 A penetration test of the Contoso website has identified a XSS vulnerability on the customer details form.
 
-1. A bug is raised in the Azure DevOps backlog
-2. The bug is given the following title: *Security Concern: Contoso Website, XSS possible on customer details form. CVSS Score: 5.2 (Medium)*
-3. The bug is tagged with the following: Security Concern, Severity - Medium
+1. A Risk is raised in the Azure DevOps backlog
+2. The bug is given the following title: *Contoso Website, XSS possible on customer details form.*
+3. The bug is tagged with the following: Security
 
 ## Prioritising and Fixing Security Concerns
 
 Discussions of prioritisation will usually happen during the team's planning session. In most cases, the team has the capability to address the security concern within their sprint. The IT Security Team will drive very high priority security concerns, this is usually discussed during SWGs (Security Working Groups) or ad-hoc meetings. In order to escalate an issue use the following guidance:
 
-1. Raise the issue with the Security Advisor for the team (usually the Lead Developer)
-
-2. The Security Advisor will inform next step i.e. raise to an ITSO (IT Security Officer).
-3. ITSO will have an initial discussion with the Security Advisor to enable a review of the bug labelled **Security Concern** during the weekly IT Security Team meeting. With appropriate tagging, queries can be used to easily identify items of interest.
-4. In this review ITSO will discuss and verify the risk score. This may require further follow-up meetings with either the Security Advisor, or member of staff who raised the concern. Discussions are recorded in the bug.
+1. Raise the issue with the Security Champion for the team or Lead Technical Software Engineer (Security)
+2. You will inform next steps i.e. raise to an ITSO (IT Security Officer).
+3. ITSO will have an initial discussion with the relevant parties to enable a review of the risk labelled **Security**. With appropriate tagging, queries can be used to easily identify items of interest.
+4. In this review ITSO will discuss and verify the risk score. This may require further follow-up meetings with either the Security Champion, or member of staff who raised the concern. Discussions are recorded in the bug.
 5. If the issue is directly related to an existing project and benefits from an opportunity to easily address in a following sprint, this must be pursued first. If required ITSO can contact the Delivery Manager for inclusion in the next sprint planning meeting.
-6. If the issue fails to be remediated, ITSO will ensure that item is added to the agenda of the next Security Working Group (SWG).
-7. SWG will discuss the issue, assign a risk owner, agree an action and assign an action owner.
-8. The SWG will monitor progress of the issue and if no progress is made, the item will be escalated to the Information Assurance Governance Board managed by the Head of Business Resilience reporting to ExCo.
+6. If the issue fails to be remediated, the issue may need to be risk accepted in which a further conversation with ITSO will be required.
+7. ITSO will discuss the issue and will guide you through the process.
diff --git a/security/SecurityChampions/SecurityChampionResponsibilities.md b/security/SecurityChampions/SecurityChampionResponsibilities.md
index 5246e54fa..116ff07a4 100644
--- a/security/SecurityChampions/SecurityChampionResponsibilities.md
+++ b/security/SecurityChampions/SecurityChampionResponsibilities.md
@@ -10,13 +10,13 @@
 
 *I am a software engineer whose main job is to write code. I additionally have a responsibility to help the team write secure software, as a source of expertise and a coach.*
 
-I coach the team into creating security processes that make our systems secure while minimising the effect on development velocity. I ensure that these processes run effectively, but I don’t make myself a bottleneck or a single point of failure in the process.
+I coach the team into creating security processes that make our systems secure while minimizing the effect on development velocity. I ensure that these processes run effectively, but I don’t make myself a bottleneck or a single point of failure in the process.
 
 I ensure the team create an effective set of standards for securely developing their software.
 
-I help the team define a set of security training materials, and I make sure they are all consumed.
+I help the team understand the security training materials, and I work to ensure they are all consumed.
 
-I have expertise in pen testing tools and use them during development to harden our software.
+I have an understanding of security testing tools and use them during development to harden our software.
 
 I help the team run threat modelling sessions.
 
@@ -54,8 +54,6 @@ I have a broad knowledge of security risks and how to counter them.
 
 I'm an expert in how my team’s technologies must be used to keep them secure.
 
-I'm well trained and hold security-related qualifications.
-
 I'm an expert in my team’s security tooling (e.g. static analysis tools, third-party checkers).
 
 I understand the security aspects of solution architecture.
diff --git a/software-engineering-policies/README.md b/software-engineering-policies/README.md
index defa5ec9f..738dee386 100644
--- a/software-engineering-policies/README.md
+++ b/software-engineering-policies/README.md
@@ -16,7 +16,7 @@ The policies (and associated guidance) that should be followed during software d
 | Open Source Use | [Policy](OpenSourceUse/OpenSourceUsePolicy.md) | |
 | Pair Programming | [Policy](PairProgramming/PairProgrammingPolicy.md) | |
 | Secure Development | [Policy](SecureDevelopment/SecureDevelopmentPolicy.md) | |
-| &nbsp; Managing Security Concerns | [Policy](../security/ManagingSecurityConcerns/ManagingSecurityConcerns.md) | and [CVSS Scoring Guidance](../security/ManagingSecurityConcerns/CvssScoringMetrics.md)|
+| &nbsp; Managing Security Concerns | [Policy](../security/ManagingSecurityConcerns/ManagingSecurityConcerns.md)| |
 | Source Control | [Policy](SourceControl/SourceControlPolicy.md) | |
 | System Documentation | [Policy](SystemDocumentation/SystemDocumentationPolicy.md) | |
 | Technical Debt | [Policy](TechnicalDebt/TechnicalDebtPolicy.md) | [Guidance](TechnicalDebt/TechnicalDebtGuidance.md) |

From 067a6b01678f8542678b333882d19d58f60b4ed7 Mon Sep 17 00:00:00 2001
From: Paul King <6100643+gyro2009@users.noreply.github.com>
Date: Wed, 10 Jun 2026 11:56:05 +0100
Subject: [PATCH 2/3] Bump dependencies and fix linting issues

---
 package-lock.json                             | 293 ++++++++++--------
 package.json                                  |   2 +-
 security/ThreatModelling/ThreatModelling.md   |   4 +-
 .../OpenSourceUse/OpenSourceUsePolicy.md      |  26 +-
 .../Pipelines/Baseline_Policy.md              |   2 +-
 software-engineering-policies/README.md       |   2 +-
 .../roles/principal-developer.md              |  48 +--
 using-github/coding-in-the-open.md            |   6 +-
 8 files changed, 203 insertions(+), 180 deletions(-)

diff --git a/package-lock.json b/package-lock.json
index 1f0d5757c..642899c43 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -9,7 +9,7 @@
       },
       "devDependencies": {
         "husky": "^9.1.7",
-        "markdownlint-cli": "^0.45.0"
+        "markdownlint-cli": "^0.48.0"
       }
     },
     "node_modules/@babel/code-frame": {
@@ -35,29 +35,6 @@
         "node": ">=6.9.0"
       }
     },
-    "node_modules/@isaacs/balanced-match": {
-      "version": "4.0.1",
-      "resolved": "https://registry.npmjs.org/@isaacs/balanced-match/-/balanced-match-4.0.1.tgz",
-      "integrity": "sha512-yzMTt9lEb8Gv7zRioUilSglI0c0smZ9k5D65677DLWLtWJaXIS3CqcGyUFByYKlnUj6TkjLVs54fBl6+TiGQDQ==",
-      "dev": true,
-      "license": "MIT",
-      "engines": {
-        "node": "20 || >=22"
-      }
-    },
-    "node_modules/@isaacs/brace-expansion": {
-      "version": "5.0.0",
-      "resolved": "https://registry.npmjs.org/@isaacs/brace-expansion/-/brace-expansion-5.0.0.tgz",
-      "integrity": "sha512-ZT55BDLV0yv0RBm2czMiZ+SqCGO7AvmOM3G/w2xhVPH+te0aKgFjmBvGlL1dH+ql2tgGO3MVrbb3jCKyvpgnxA==",
-      "dev": true,
-      "license": "MIT",
-      "dependencies": {
-        "@isaacs/balanced-match": "^4.0.1"
-      },
-      "engines": {
-        "node": "20 || >=22"
-      }
-    },
     "node_modules/@isaacs/cliui": {
       "version": "8.0.2",
       "resolved": "https://registry.npmjs.org/@isaacs/cliui/-/cliui-8.0.2.tgz",
@@ -110,9 +87,10 @@
       }
     },
     "node_modules/@npmcli/map-workspaces/node_modules/glob": {
-      "version": "10.4.5",
-      "resolved": "https://registry.npmjs.org/glob/-/glob-10.4.5.tgz",
-      "integrity": "sha512-7Bv8RF0k6xjo7d4A/PxYLbUCfb6c+Vpd2/mB2yRDlew7Jb5hEXiCD9ibfO7wpk8i4sevK6DFny9h7EYbM3/sHg==",
+      "version": "10.5.0",
+      "resolved": "https://registry.npmjs.org/glob/-/glob-10.5.0.tgz",
+      "integrity": "sha512-DfXN8DfhJ7NH3Oe7cFmu3NCu1wKbkReJ8TorzSAFbSKrlNaQSKfIzqYqVY8zlbs2NLBbWpRiU52GX2PbaBVNkg==",
+      "deprecated": "Old versions of glob are not supported, and contain widely publicized security vulnerabilities, which have been fixed in the current version. Please update. Support for old versions may be purchased (at exorbitant rates) by contacting i@izs.me",
       "license": "ISC",
       "dependencies": {
         "foreground-child": "^3.1.0",
@@ -130,12 +108,12 @@
       }
     },
     "node_modules/@npmcli/map-workspaces/node_modules/minimatch": {
-      "version": "9.0.5",
-      "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-9.0.5.tgz",
-      "integrity": "sha512-G6T0ZX48xgozx7587koeX9Ys2NYy6Gmv//P89sEte9V9whIapMNF4idKxnW2QtCcLiTWlb/wfCabAtAFWhhBow==",
+      "version": "9.0.9",
+      "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-9.0.9.tgz",
+      "integrity": "sha512-OBwBN9AL4dqmETlpS2zasx+vTeWclWzkblfZk7KTA5j3jeOONz/tRCnZomUyvNg83wL5Zv9Ss6HMJXAgL8R2Yg==",
       "license": "ISC",
       "dependencies": {
-        "brace-expansion": "^2.0.1"
+        "brace-expansion": "^2.0.2"
       },
       "engines": {
         "node": ">=16 || 14 >=14.17"
@@ -292,9 +270,9 @@
       "license": "MIT"
     },
     "node_modules/@types/katex": {
-      "version": "0.16.7",
-      "resolved": "https://registry.npmjs.org/@types/katex/-/katex-0.16.7.tgz",
-      "integrity": "sha512-HMwFiRujE5PjrgwHQ25+bsLJgowjGjm5Z8FVSf0N6PwgJrwxH0QxzHYDcKsTfV3wva0vzrpqMTJS2jXPr5BMEQ==",
+      "version": "0.16.8",
+      "resolved": "https://registry.npmjs.org/@types/katex/-/katex-0.16.8.tgz",
+      "integrity": "sha512-trgaNyfU+Xh2Tc+ABIb44a5AYUpicB3uwirOioeOkNPPbmgRNtcWyDeeFRzjPZENO9Vq8gvVqfhaaXWLlevVwg==",
       "dev": true,
       "license": "MIT"
     },
@@ -369,7 +347,6 @@
       "resolved": "https://registry.npmjs.org/acorn/-/acorn-8.15.0.tgz",
       "integrity": "sha512-NZyJarBfL7nWwIq+FDL6Zp/yHEhePMNnnJ0y3qfieCrmNvYct8uvtiV41UvlSe6apAfk0fY1FbWx+NwfmpvtTg==",
       "license": "MIT",
-      "peer": true,
       "bin": {
         "acorn": "bin/acorn"
       },
@@ -786,13 +763,13 @@
       }
     },
     "node_modules/commander": {
-      "version": "13.1.0",
-      "resolved": "https://registry.npmjs.org/commander/-/commander-13.1.0.tgz",
-      "integrity": "sha512-/rFeCpNJQbhSZjGVwO9RFV3xPqbnERS8MmIQzCtD/zl6gpJuV/bMLuN92oG3F7d8oDEHHRrujSXNUr8fpjntKw==",
+      "version": "14.0.3",
+      "resolved": "https://registry.npmjs.org/commander/-/commander-14.0.3.tgz",
+      "integrity": "sha512-H+y0Jo/T1RZ9qPP4Eh1pkcQcLRglraJaSLoyOtHxu6AapkjWVCy2Sit1QQ4x3Dng8qDlSsZEet7g5Pq06MvTgw==",
       "dev": true,
       "license": "MIT",
       "engines": {
-        "node": ">=18"
+        "node": ">=20"
       }
     },
     "node_modules/concat-stream": {
@@ -1223,6 +1200,24 @@
         "url": "https://github.com/sponsors/wooorm"
       }
     },
+    "node_modules/fdir": {
+      "version": "6.5.0",
+      "resolved": "https://registry.npmjs.org/fdir/-/fdir-6.5.0.tgz",
+      "integrity": "sha512-tIbYtZbucOs0BRGqPJkshJUYdL+SDH7dVM8gjy+ERp3WAUjLEFJE+02kanyHtwjWOnwrKYBiwAmM0p4kLJAnXg==",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=12.0.0"
+      },
+      "peerDependencies": {
+        "picomatch": "^3 || ^4"
+      },
+      "peerDependenciesMeta": {
+        "picomatch": {
+          "optional": true
+        }
+      }
+    },
     "node_modules/find-up": {
       "version": "6.3.0",
       "resolved": "https://registry.npmjs.org/find-up/-/find-up-6.3.0.tgz",
@@ -1305,6 +1300,19 @@
         "url": "https://github.com/sponsors/ljharb"
       }
     },
+    "node_modules/get-east-asian-width": {
+      "version": "1.6.0",
+      "resolved": "https://registry.npmjs.org/get-east-asian-width/-/get-east-asian-width-1.6.0.tgz",
+      "integrity": "sha512-QRbvDIbx6YklUe6RxeTeleMR0yv3cYH6PsPZHcnVn7xv7zO1BHN8r0XETu8n6Ye3Q+ahtSarc3WgtNWmehIBfA==",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=18"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/sindresorhus"
+      }
+    },
     "node_modules/get-stream": {
       "version": "6.0.1",
       "resolved": "https://registry.npmjs.org/get-stream/-/get-stream-6.0.1.tgz",
@@ -2022,9 +2030,9 @@
       }
     },
     "node_modules/katex": {
-      "version": "0.16.22",
-      "resolved": "https://registry.npmjs.org/katex/-/katex-0.16.22.tgz",
-      "integrity": "sha512-XCHRdUw4lf3SKBaJe4EvgqIuWwkPSo9XoeO8GjQW94Bp7TWv9hNhzZjZ+OH9yf1UmLygb7DIT5GSFQiyt16zYg==",
+      "version": "0.16.47",
+      "resolved": "https://registry.npmjs.org/katex/-/katex-0.16.47.tgz",
+      "integrity": "sha512-Eeo8Ys1doU1z+x8AZsPpQu+p/QcZBI5PeOo7QGQdy2x2m0MU/hYagBbGOmXwr5KVbEfVuWv9LpnQWeehogurjg==",
       "dev": true,
       "funding": [
         "https://opencollective.com/katex",
@@ -2106,10 +2114,20 @@
       "license": "MIT"
     },
     "node_modules/linkify-it": {
-      "version": "5.0.0",
-      "resolved": "https://registry.npmjs.org/linkify-it/-/linkify-it-5.0.0.tgz",
-      "integrity": "sha512-5aHCbzQRADcdP+ATqnDuhhJ/MRIqDkZX5pyjFHRRysS8vZ5AbqGEoFIb6pYHPZ+L/OC2Lc+xT8uHVVR5CAK/wQ==",
+      "version": "5.0.1",
+      "resolved": "https://registry.npmjs.org/linkify-it/-/linkify-it-5.0.1.tgz",
+      "integrity": "sha512-wVoTjP4Q6R0NW5hiZkVJaFZPWgtXfoGF+6LucL3/FtiNjmcHhYjEr5f1Kqjirc1nBW07J/ZuRFumqr2oqccEWg==",
       "dev": true,
+      "funding": [
+        {
+          "type": "github",
+          "url": "https://github.com/sponsors/puzrin"
+        },
+        {
+          "type": "github",
+          "url": "https://github.com/sponsors/markdown-it"
+        }
+      ],
       "license": "MIT",
       "dependencies": {
         "uc.micro": "^2.0.0"
@@ -2193,9 +2211,9 @@
       "integrity": "sha512-CkYQrPYZfWnu/DAmVCpTSX/xHpKZ80eKh2lAkyA6AJTef6bW+6JpbQZN5rofum7da+SyN1bi5ctTm+lTfcCW3g=="
     },
     "node_modules/markdown-it": {
-      "version": "14.1.0",
-      "resolved": "https://registry.npmjs.org/markdown-it/-/markdown-it-14.1.0.tgz",
-      "integrity": "sha512-a54IwgWPaeBCAAsv13YgmALOF1elABB08FxO9i+r4VFk5Vl4pKokRPeX8u5TCgSsPi6ec1otfLjdOpVcgbpshg==",
+      "version": "14.1.1",
+      "resolved": "https://registry.npmjs.org/markdown-it/-/markdown-it-14.1.1.tgz",
+      "integrity": "sha512-BuU2qnTti9YKgK5N+IeMubp14ZUKUUw7yeJbkjtosvHiP0AZ5c8IAgEMk79D0eC8F23r4Ac/q8cAIFdm2FtyoA==",
       "dev": true,
       "license": "MIT",
       "dependencies": {
@@ -2221,9 +2239,9 @@
       }
     },
     "node_modules/markdownlint": {
-      "version": "0.38.0",
-      "resolved": "https://registry.npmjs.org/markdownlint/-/markdownlint-0.38.0.tgz",
-      "integrity": "sha512-xaSxkaU7wY/0852zGApM8LdlIfGCW8ETZ0Rr62IQtAnUMlMuifsg09vWJcNYeL4f0anvr8Vo4ZQar8jGpV0btQ==",
+      "version": "0.40.0",
+      "resolved": "https://registry.npmjs.org/markdownlint/-/markdownlint-0.40.0.tgz",
+      "integrity": "sha512-UKybllYNheWac61Ia7T6fzuQNDZimFIpCg2w6hHjgV1Qu0w1TV0LlSgryUGzM0bkKQCBhy2FDhEELB73Kb0kAg==",
       "dev": true,
       "license": "MIT",
       "dependencies": {
@@ -2234,7 +2252,8 @@
         "micromark-extension-gfm-footnote": "2.1.0",
         "micromark-extension-gfm-table": "2.1.1",
         "micromark-extension-math": "3.1.0",
-        "micromark-util-types": "2.0.2"
+        "micromark-util-types": "2.0.2",
+        "string-width": "8.1.0"
       },
       "engines": {
         "node": ">=20"
@@ -2244,23 +2263,24 @@
       }
     },
     "node_modules/markdownlint-cli": {
-      "version": "0.45.0",
-      "resolved": "https://registry.npmjs.org/markdownlint-cli/-/markdownlint-cli-0.45.0.tgz",
-      "integrity": "sha512-GiWr7GfJLVfcopL3t3pLumXCYs8sgWppjIA1F/Cc3zIMgD3tmkpyZ1xkm1Tej8mw53B93JsDjgA3KOftuYcfOw==",
+      "version": "0.48.0",
+      "resolved": "https://registry.npmjs.org/markdownlint-cli/-/markdownlint-cli-0.48.0.tgz",
+      "integrity": "sha512-NkZQNu2E0Q5qLEEHwWj674eYISTLD4jMHkBzDobujXd1kv+yCxi8jOaD/rZoQNW1FBBMMGQpuW5So8B51N/e0A==",
       "dev": true,
       "license": "MIT",
       "dependencies": {
-        "commander": "~13.1.0",
-        "glob": "~11.0.2",
-        "ignore": "~7.0.4",
-        "js-yaml": "~4.1.0",
+        "commander": "~14.0.3",
+        "deep-extend": "~0.6.0",
+        "ignore": "~7.0.5",
+        "js-yaml": "~4.1.1",
         "jsonc-parser": "~3.3.1",
         "jsonpointer": "~5.0.1",
-        "markdown-it": "~14.1.0",
-        "markdownlint": "~0.38.0",
-        "minimatch": "~10.0.1",
+        "markdown-it": "~14.1.1",
+        "markdownlint": "~0.40.0",
+        "minimatch": "~10.2.4",
         "run-con": "~1.3.2",
-        "smol-toml": "~1.3.4"
+        "smol-toml": "~1.6.0",
+        "tinyglobby": "~0.2.15"
       },
       "bin": {
         "markdownlint": "markdownlint.js"
@@ -2269,28 +2289,27 @@
         "node": ">=20"
       }
     },
-    "node_modules/markdownlint-cli/node_modules/glob": {
-      "version": "11.0.3",
-      "resolved": "https://registry.npmjs.org/glob/-/glob-11.0.3.tgz",
-      "integrity": "sha512-2Nim7dha1KVkaiF4q6Dj+ngPPMdfvLJEOpZk/jKiUAkqKebpGAWQXAq9z1xu9HKu5lWfqw/FASuccEjyznjPaA==",
+    "node_modules/markdownlint-cli/node_modules/balanced-match": {
+      "version": "4.0.4",
+      "resolved": "https://registry.npmjs.org/balanced-match/-/balanced-match-4.0.4.tgz",
+      "integrity": "sha512-BLrgEcRTwX2o6gGxGOCNyMvGSp35YofuYzw9h1IMTRmKqttAZZVU67bdb9Pr2vUHA8+j3i2tJfjO6C6+4myGTA==",
       "dev": true,
-      "license": "ISC",
+      "license": "MIT",
+      "engines": {
+        "node": "18 || 20 || >=22"
+      }
+    },
+    "node_modules/markdownlint-cli/node_modules/brace-expansion": {
+      "version": "5.0.6",
+      "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-5.0.6.tgz",
+      "integrity": "sha512-kLpxurY4Z4r9sgMsyG0Z9uzsBlgiU/EFKhj/h91/8yHu0edo7XuixOIH3VcJ8kkxs6/jPzoI6U9Vj3WqbMQ94g==",
+      "dev": true,
+      "license": "MIT",
       "dependencies": {
-        "foreground-child": "^3.3.1",
-        "jackspeak": "^4.1.1",
-        "minimatch": "^10.0.3",
-        "minipass": "^7.1.2",
-        "package-json-from-dist": "^1.0.0",
-        "path-scurry": "^2.0.0"
-      },
-      "bin": {
-        "glob": "dist/esm/bin.mjs"
+        "balanced-match": "^4.0.2"
       },
       "engines": {
-        "node": "20 || >=22"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/isaacs"
+        "node": "18 || 20 || >=22"
       }
     },
     "node_modules/markdownlint-cli/node_modules/ignore": {
@@ -2303,60 +2322,17 @@
         "node": ">= 4"
       }
     },
-    "node_modules/markdownlint-cli/node_modules/jackspeak": {
-      "version": "4.1.1",
-      "resolved": "https://registry.npmjs.org/jackspeak/-/jackspeak-4.1.1.tgz",
-      "integrity": "sha512-zptv57P3GpL+O0I7VdMJNBZCu+BPHVQUk55Ft8/QCJjTVxrnJHuVuX/0Bl2A6/+2oyR/ZMEuFKwmzqqZ/U5nPQ==",
-      "dev": true,
-      "license": "BlueOak-1.0.0",
-      "dependencies": {
-        "@isaacs/cliui": "^8.0.2"
-      },
-      "engines": {
-        "node": "20 || >=22"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/isaacs"
-      }
-    },
-    "node_modules/markdownlint-cli/node_modules/lru-cache": {
-      "version": "11.1.0",
-      "resolved": "https://registry.npmjs.org/lru-cache/-/lru-cache-11.1.0.tgz",
-      "integrity": "sha512-QIXZUBJUx+2zHUdQujWejBkcD9+cs94tLn0+YL8UrCh+D5sCXZ4c7LaEH48pNwRY3MLDgqUFyhlCyjJPf1WP0A==",
-      "dev": true,
-      "license": "ISC",
-      "engines": {
-        "node": "20 || >=22"
-      }
-    },
     "node_modules/markdownlint-cli/node_modules/minimatch": {
-      "version": "10.0.3",
-      "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-10.0.3.tgz",
-      "integrity": "sha512-IPZ167aShDZZUMdRk66cyQAW3qr0WzbHkPdMYa8bzZhlHhO3jALbKdxcaak7W9FfT2rZNpQuUu4Od7ILEpXSaw==",
-      "dev": true,
-      "license": "ISC",
-      "dependencies": {
-        "@isaacs/brace-expansion": "^5.0.0"
-      },
-      "engines": {
-        "node": "20 || >=22"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/isaacs"
-      }
-    },
-    "node_modules/markdownlint-cli/node_modules/path-scurry": {
-      "version": "2.0.0",
-      "resolved": "https://registry.npmjs.org/path-scurry/-/path-scurry-2.0.0.tgz",
-      "integrity": "sha512-ypGJsmGtdXUOeM5u93TyeIEfEhM6s+ljAhrk5vAvSx8uyY/02OvrZnA0YNGUrPXfpJMgI1ODd3nwz8Npx4O4cg==",
+      "version": "10.2.5",
+      "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-10.2.5.tgz",
+      "integrity": "sha512-MULkVLfKGYDFYejP07QOurDLLQpcjk7Fw+7jXS2R2czRQzR56yHRveU5NDJEOviH+hETZKSkIk5c+T23GjFUMg==",
       "dev": true,
       "license": "BlueOak-1.0.0",
       "dependencies": {
-        "lru-cache": "^11.0.0",
-        "minipass": "^7.1.2"
+        "brace-expansion": "^5.0.5"
       },
       "engines": {
-        "node": "20 || >=22"
+        "node": "18 || 20 || >=22"
       },
       "funding": {
         "url": "https://github.com/sponsors/isaacs"
@@ -2858,6 +2834,23 @@
       ],
       "license": "MIT"
     },
+    "node_modules/markdownlint/node_modules/string-width": {
+      "version": "8.1.0",
+      "resolved": "https://registry.npmjs.org/string-width/-/string-width-8.1.0.tgz",
+      "integrity": "sha512-Kxl3KJGb/gxkaUMOjRsQ8IrXiGW75O4E3RPjFIINOVH8AMl2SQ/yWdTzWwF3FevIX9LcMAjJW+GRwAlAbTSXdg==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "get-east-asian-width": "^1.3.0",
+        "strip-ansi": "^7.1.0"
+      },
+      "engines": {
+        "node": ">=20"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/sindresorhus"
+      }
+    },
     "node_modules/mdast-comment-marker": {
       "version": "2.1.2",
       "resolved": "https://registry.npmjs.org/mdast-comment-marker/-/mdast-comment-marker-2.1.2.tgz",
@@ -4165,9 +4158,9 @@
       }
     },
     "node_modules/minimatch": {
-      "version": "5.1.6",
-      "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-5.1.6.tgz",
-      "integrity": "sha512-lKwV/1brpG6mBUFHtb7NUmtABCb2WZZmm2wNiOA5hAb8VdCS4B3dtMWyvcoViccwAW/COERjXLt0zP1zXUN26g==",
+      "version": "5.1.9",
+      "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-5.1.9.tgz",
+      "integrity": "sha512-7o1wEA2RyMP7Iu7GNba9vc0RWWGACJOCZBJX2GJWip0ikV+wcOsgVuY9uE8CPiyQhkGFSlhuSkZPavN7u1c2Fw==",
       "license": "ISC",
       "dependencies": {
         "brace-expansion": "^2.0.1"
@@ -4590,6 +4583,19 @@
       "integrity": "sha512-xceH2snhtb5M9liqDsmEw56le376mTZkEX/jEb/RxNFyegNul7eNslCXP9FDj/Lcu0X8KEyMceP2ntpaHrDEVA==",
       "license": "ISC"
     },
+    "node_modules/picomatch": {
+      "version": "4.0.4",
+      "resolved": "https://registry.npmjs.org/picomatch/-/picomatch-4.0.4.tgz",
+      "integrity": "sha512-QP88BAKvMam/3NxH6vj2o21R6MjxZUAd6nlwAS/pnGvN9IVLocLHxGYIzFhg6fUQ+5th6P4dv4eW9jX3DSIj7A==",
+      "dev": true,
+      "license": "MIT",
+      "engines": {
+        "node": ">=12"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/jonschlinkert"
+      }
+    },
     "node_modules/pluralize": {
       "version": "8.0.0",
       "resolved": "https://registry.npmjs.org/pluralize/-/pluralize-8.0.0.tgz",
@@ -5223,9 +5229,9 @@
       "license": "MIT"
     },
     "node_modules/smol-toml": {
-      "version": "1.3.4",
-      "resolved": "https://registry.npmjs.org/smol-toml/-/smol-toml-1.3.4.tgz",
-      "integrity": "sha512-UOPtVuYkzYGee0Bd2Szz8d2G3RfMfJ2t3qVdZUAozZyAk+a0Sxa+QKix0YCwjL/A1RR0ar44nCxaoN9FxdJGwA==",
+      "version": "1.6.1",
+      "resolved": "https://registry.npmjs.org/smol-toml/-/smol-toml-1.6.1.tgz",
+      "integrity": "sha512-dWUG8F5sIIARXih1DTaQAX4SsiTXhInKf1buxdY9DIg4ZYPZK5nGM1VRIYmEbDbsHt7USo99xSLFu5Q1IqTmsg==",
       "dev": true,
       "license": "BSD-3-Clause",
       "engines": {
@@ -5576,6 +5582,23 @@
         "xtend": "~4.0.0"
       }
     },
+    "node_modules/tinyglobby": {
+      "version": "0.2.17",
+      "resolved": "https://registry.npmjs.org/tinyglobby/-/tinyglobby-0.2.17.tgz",
+      "integrity": "sha512-wXR/dYpcqKmfWpEdZjiKJOwCNFndD0DMnrW/cYjVGttEkBfVgcLFHoNrlj47mjOVic9yyNu65alsgF4NQyTa2g==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "fdir": "^6.5.0",
+        "picomatch": "^4.0.4"
+      },
+      "engines": {
+        "node": ">=12.0.0"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/SuperchupuDev"
+      }
+    },
     "node_modules/to-vfile": {
       "version": "7.2.4",
       "resolved": "https://registry.npmjs.org/to-vfile/-/to-vfile-7.2.4.tgz",
diff --git a/package.json b/package.json
index 917689a62..418ea96e5 100644
--- a/package.json
+++ b/package.json
@@ -24,6 +24,6 @@
   },
   "devDependencies": {
     "husky": "^9.1.7",
-    "markdownlint-cli": "^0.45.0"
+    "markdownlint-cli": "^0.48.0"
   }
 }
diff --git a/security/ThreatModelling/ThreatModelling.md b/security/ThreatModelling/ThreatModelling.md
index f277a69c5..e6cbb256d 100644
--- a/security/ThreatModelling/ThreatModelling.md
+++ b/security/ThreatModelling/ThreatModelling.md
@@ -65,12 +65,12 @@ All findings that come out of a session should be logged so that if required it
 
 Questions around the system should utilise the 6 aspects of STRIDE. There can be some crossover with these aspects so wherever possible call out the most prominent one (or if there are indeed multiple aspects for a single issue, log them as such)
 
-|Name |	Meaning | Desired Security Property | Example |
+| Name | Meaning | Desired Security Property | Example |
 | --- | ------- | ------------------------- | ------- |
 | __Spoofing__ | Pretending to be another user/system |	Authentication | Unauthenticated API with username header |
 | __Tampering__	| Modifying data in the application | Integrity | SQL Injection through unvalidated parameters |
 | __Repudiation__ |	Accountability of action | Non-repudiation | Deletion of data with information logged as to who and what. |
-| __Information Disclosure__ | Access of allowed information | Confidentiality  |Bleed of information between users |
+| __Information Disclosure__ | Access of allowed information | Confidentiality | Bleed of information between users |
 | __Denial of Service__	| Availability of application |	Availability | Degradation of service due to high volumes of requests |
 | __Elevation of Privilege__ | Access to the right privileged information | Authorization | Ability to self-promote to admin via a unvalidated parameter |
 
diff --git a/software-engineering-policies/OpenSourceUse/OpenSourceUsePolicy.md b/software-engineering-policies/OpenSourceUse/OpenSourceUsePolicy.md
index 35edd91aa..cdfcfcda0 100644
--- a/software-engineering-policies/OpenSourceUse/OpenSourceUsePolicy.md
+++ b/software-engineering-policies/OpenSourceUse/OpenSourceUsePolicy.md
@@ -16,11 +16,11 @@ For the purposes of this policy, free open source software (FOSS) is [as defined
 
 | Risk | Description | Mitigation |
 | ---- | ----------- | ---------- |
-|**The licensing terms of OS asset cause us to inadvertently lose control of valuable IPR if we use it, or prevent us from using an OS asset that performs a function we require.**| Certain OS licenses, especially those that include so-called "[copyleft](https://en.wikipedia.org/wiki/Copyleft)" provisions may require that linked code or solutions built on incorporated code are also distributed under similar terms and conditions. Copyleft licenses may prevent us exploiting specific OS assets that would otherwise be our choice to meet a requirement.|See Permitted licenses, below |
-|**Using OS assets results in unexpected costs to either exploit or support that asset.**|This is the issues that arise from so-called "open wash" (https://www.quora.com/What-is-openwashing) and "open core" (https://en.wikipedia.org/wiki/Open_core) software. A typical "open core" problem is where the main asset is released as OS, but to really exploit it requires the use of proprietary, paid-for SW, or commercial support from a single vendor. A typical "open wash" problem is where an asset purports to be OS but the owner of the OS asset refuses to allow certain features to be added by the community to the core. This is typically where a paid for module exists that meets the same requirement. The two problems are typically associated with each other – and are both common where the OS software is developed and supported by a single commercial company rather than being adopted by a wider community. | Evaluation criteria 1. and 2. |
-|**An OS asset that we rely on becomes unmaintained.**| Not all OS assets are adopted and maintained by an active community. Similarly, not every OS asset has commercial companies that provide support.| Evaluation criteria 5,6 |
-|**We expose ourselves to security issues by using OS assets.** | There may be cyber-security risk associated with OS assets, either in terms of its development, packaging and distribution or maintenance. | See Security vulnerabilities below.|
-|**We utilise OS assets that infringe someone's IPR OS assets may contain code, algorithms or data that includes 3rd party IPR that hasn't been licensed for use in the code concerned.** | The risk is that we need to stop using the software concerned and/or pay for a license and/or damages for past use. | Evaluation criteria 7 below |
+| **The licensing terms of OS asset cause us to inadvertently lose control of valuable IPR if we use it, or prevent us from using an OS asset that performs a function we require.** | Certain OS licenses, especially those that include so-called "[copyleft](https://en.wikipedia.org/wiki/Copyleft)" provisions may require that linked code or solutions built on incorporated code are also distributed under similar terms and conditions. Copyleft licenses may prevent us exploiting specific OS assets that would otherwise be our choice to meet a requirement. | See Permitted licenses, below |
+| **Using OS assets results in unexpected costs to either exploit or support that asset.** | This is the issues that arise from so-called "open wash" (https://www.quora.com/What-is-openwashing) and "open core" (https://en.wikipedia.org/wiki/Open_core) software. A typical "open core" problem is where the main asset is released as OS, but to really exploit it requires the use of proprietary, paid-for SW, or commercial support from a single vendor. A typical "open wash" problem is where an asset purports to be OS but the owner of the OS asset refuses to allow certain features to be added by the community to the core. This is typically where a paid for module exists that meets the same requirement. The two problems are typically associated with each other – and are both common where the OS software is developed and supported by a single commercial company rather than being adopted by a wider community. | Evaluation criteria 1. and 2. |
+| **An OS asset that we rely on becomes unmaintained.** | Not all OS assets are adopted and maintained by an active community. Similarly, not every OS asset has commercial companies that provide support. | Evaluation criteria 5,6 |
+| **We expose ourselves to security issues by using OS assets.** | There may be cyber-security risk associated with OS assets, either in terms of its development, packaging and distribution or maintenance. | See Security vulnerabilities below. |
+| **We utilise OS assets that infringe someone's IPR OS assets may contain code, algorithms or data that includes 3rd party IPR that hasn't been licensed for use in the code concerned.** | The risk is that we need to stop using the software concerned and/or pay for a license and/or damages for past use. | Evaluation criteria 7 below |
 
 ## General guidance
 
@@ -59,15 +59,15 @@ For other (smaller) decisions, the responsible person is the relevant Lead Engin
 ### FOSS evaluation criteria
 
 | | Reason | Positive indicators | Negative indicators |
-|-| ------ | ------------------- | ------------------- |
-| **1. Is it controlled by an open foundation, or by a commercial entity** | Control by a foundation means it is less likely to be exploited for commercial gain. |Controlled by a foundation.  E.g. The Apache HTTP server is governed by the [Apache Software Foundation (ASF)](https://apache.org/foundation/).  The ASF is a charitable foundation with a clear and open governance, free from proprietary control.| Controlled by a single commercial entity.  E.g. NServiceBus [is open source](https://particular.net/sourcecode), issued under the IPL1.5 license.  However, it is entirely controlled by one company, Particular Software. |
-| **OR Is it under diverse control** | If several commercial organisations are in control, it is less likely that any one of them will exploit it for commercial gain.| Sometimes, multiple vendors form an organisation to govern an open source effort.  This diversity makes it less likely that the FOSS will be directly by the vendor. Cloud Foundry is an open source cloud application platform, whose [board of directors](https://www.cloudfoundry.org/board-of-directors/) includes representatives of VMWare, Dell, IBM & Cisco. | Sometimes a single vendor or organisation is in control (see Particular Software example above)|
-| **2. Is it part of an '[open-core](https://en.wikipedia.org/wiki/Open_core)' offering? **| The owners of an open core project will be unlikely to accept modifications that would undermine the value of their commercial offering. | The FOSS has a free offering which is fully functional. If the FOSS is governed by a single company, this company might make its money instead from support, training and consulting (e.g. [Hortonworks](https://hortonworks.com/))| The software consists of a FOSS core which is just about adequate for basic use, with proprietary add-ons providing more advanced functionality (e.g. [Cloudera](https://www.cloudera.com/)).| 
-| **3. Does it have a clear governance model?** | A comprehensive, published governance model will provide us clarity on how it is led and how it can be influenced.  It can also indicate that the project has reached a certain stage of maturity. | A clear governance model exists, e.g. that of [Ubuntu](https://community.ubuntu.com/community-structure/governance/). | No explicit governance model exists.  It isn't clear who owns the direction of the FOSS and how the UKHO could change it, e.g. by adding features that we need.|
-| **4. Is there a defined contribution process?** | UKHO might need to need to add features or fix bugs and feed these back into the project, so that we can avoid [forking](https://en.wikipedia.org/wiki/Fork_(software_development)) it. | A clear process is published, which invites direct contributions from external parties.  E.g. [Ubuntu](https://community.ubuntu.com/community-structure/governance/). There should also be a track record of accepting contributions.| No process is published, or the process does not invite contribution from external parties.|
+| - | ------ | ------------------- | ------------------- |
+| **1. Is it controlled by an open foundation, or by a commercial entity** | Control by a foundation means it is less likely to be exploited for commercial gain. | Controlled by a foundation.  E.g. The Apache HTTP server is governed by the [Apache Software Foundation (ASF)](https://apache.org/foundation/).  The ASF is a charitable foundation with a clear and open governance, free from proprietary control. | Controlled by a single commercial entity.  E.g. NServiceBus [is open source](https://particular.net/sourcecode), issued under the IPL1.5 license.  However, it is entirely controlled by one company, Particular Software. |
+| **OR Is it under diverse control** | If several commercial organisations are in control, it is less likely that any one of them will exploit it for commercial gain. | Sometimes, multiple vendors form an organisation to govern an open source effort.  This diversity makes it less likely that the FOSS will be directly by the vendor. Cloud Foundry is an open source cloud application platform, whose [board of directors](https://www.cloudfoundry.org/board-of-directors/) includes representatives of VMWare, Dell, IBM & Cisco. | Sometimes a single vendor or organisation is in control (see Particular Software example above) |
+| **2. Is it part of an '[open-core](https://en.wikipedia.org/wiki/Open_core)' offering? ** | The owners of an open core project will be unlikely to accept modifications that would undermine the value of their commercial offering. | The FOSS has a free offering which is fully functional. If the FOSS is governed by a single company, this company might make its money instead from support, training and consulting (e.g. [Hortonworks](https://hortonworks.com/)) | The software consists of a FOSS core which is just about adequate for basic use, with proprietary add-ons providing more advanced functionality (e.g. [Cloudera](https://www.cloudera.com/)). | 
+| **3. Does it have a clear governance model?** | A comprehensive, published governance model will provide us clarity on how it is led and how it can be influenced.  It can also indicate that the project has reached a certain stage of maturity. | A clear governance model exists, e.g. that of [Ubuntu](https://community.ubuntu.com/community-structure/governance/). | No explicit governance model exists.  It isn't clear who owns the direction of the FOSS and how the UKHO could change it, e.g. by adding features that we need. |
+| **4. Is there a defined contribution process?** | UKHO might need to need to add features or fix bugs and feed these back into the project, so that we can avoid [forking](https://en.wikipedia.org/wiki/Fork_(software_development)) it. | A clear process is published, which invites direct contributions from external parties.  E.g. [Ubuntu](https://community.ubuntu.com/community-structure/governance/). There should also be a track record of accepting contributions. | No process is published, or the process does not invite contribution from external parties. |
 | **5. Is it actively maintained?** | All software has bugs and security flaws.  Change to the codebase shows that these issues are being dealt with. | There is a stream of commits to the codebase.  There is a recent track record of minor releases, with a roadmap for future releases. | Codebase seems stagnant, with no plans or progress being made towards new releases. |
-| **6. Is it mature and well-used?** | Software that has been in use over time by large numbers of users will have be more stable| Software has been used for a long time and has a good reputation, e.g. Apache HTTP server | Software is new, with limited evidence that it is being seriously used. |
-| **7. Does the license contain a patent peace clause?** | A patent peace clause in a license protects the licensee of FOSS against a patent claim from a contributor. |The license contains a patent peace clause, e.g. [CDDL-1.0](https://en.wikipedia.org/wiki/Common_Development_and_Distribution_License) | The license does not contain a patent peace clause, e.g. BSD licenses |
+| **6. Is it mature and well-used?** | Software that has been in use over time by large numbers of users will have be more stable | Software has been used for a long time and has a good reputation, e.g. Apache HTTP server | Software is new, with limited evidence that it is being seriously used. |
+| **7. Does the license contain a patent peace clause?** | A patent peace clause in a license protects the licensee of FOSS against a patent claim from a contributor. | The license contains a patent peace clause, e.g. [CDDL-1.0](https://en.wikipedia.org/wiki/Common_Development_and_Distribution_License) | The license does not contain a patent peace clause, e.g. BSD licenses |
 
 > Note that this table contains only open-source-specific concerns.  Generic criteria, such as technical fit, security, performance etc. are not included. 
 
diff --git a/software-engineering-policies/Pipelines/Baseline_Policy.md b/software-engineering-policies/Pipelines/Baseline_Policy.md
index 617758a6f..617f6cd7c 100644
--- a/software-engineering-policies/Pipelines/Baseline_Policy.md
+++ b/software-engineering-policies/Pipelines/Baseline_Policy.md
@@ -81,7 +81,7 @@ Branch protection for main should be considered to avoid accidental or malicious
 When setting up checks and approvals on a Pipeline Environment; the default expiry is 30 days, this behaviour is queuing builds for days when they arent needed, in the scope of this a set of default values should be followed depending on the target environment.
 
 | Environment | Timeout |
-|-------------|---------|
+| ----------- | ------- |
 | DEV | < 30 minutes |
 | QA | < 3 hours |
 | LIVE | < 6 hours |
diff --git a/software-engineering-policies/README.md b/software-engineering-policies/README.md
index 738dee386..a1ad9a41a 100644
--- a/software-engineering-policies/README.md
+++ b/software-engineering-policies/README.md
@@ -16,7 +16,7 @@ The policies (and associated guidance) that should be followed during software d
 | Open Source Use | [Policy](OpenSourceUse/OpenSourceUsePolicy.md) | |
 | Pair Programming | [Policy](PairProgramming/PairProgrammingPolicy.md) | |
 | Secure Development | [Policy](SecureDevelopment/SecureDevelopmentPolicy.md) | |
-| &nbsp; Managing Security Concerns | [Policy](../security/ManagingSecurityConcerns/ManagingSecurityConcerns.md)| |
+| &nbsp; Managing Security Concerns | [Policy](../security/ManagingSecurityConcerns/ManagingSecurityConcerns.md) | |
 | Source Control | [Policy](SourceControl/SourceControlPolicy.md) | |
 | System Documentation | [Policy](SystemDocumentation/SystemDocumentationPolicy.md) | |
 | Technical Debt | [Policy](TechnicalDebt/TechnicalDebtPolicy.md) | [Guidance](TechnicalDebt/TechnicalDebtGuidance.md) |
diff --git a/software-engineering/roles/principal-developer.md b/software-engineering/roles/principal-developer.md
index fdf92a516..5f311c73b 100644
--- a/software-engineering/roles/principal-developer.md
+++ b/software-engineering/roles/principal-developer.md
@@ -3,34 +3,34 @@
 | Area | Tasks | Example stories |
 | --- | --- | --- |
 | Leading delivery of large programmes of work | Co-ordinating work across multiple teams | ADDS |
-|   |   | Data Hub |
-|   |   | Sailing Directions |
-|   |   | Dashboard Visibility Project |
-|   | Feedback to Senior Managers | Whilst individual delivery teams are responsible for their own progress feedback, the Principal Dev will be frequently reporting on overall progress, particularly from the technical perspective. |
-|   | Tech/non-tech translations at high level | |
+| | | Data Hub |
+| | | Sailing Directions |
+| | | Dashboard Visibility Project |
+| | Feedback to Senior Managers | Whilst individual delivery teams are responsible for their own progress feedback, the Principal Dev will be frequently reporting on overall progress, particularly from the technical perspective. |
+| | Tech/non-tech translations at high level | |
 | Technical Oversight | Technology Sharing | By working closely with multiple teams, the Principals can spot where a solution from one team can help another team. |
-|  |  | Identify and support shared libraries. |
-|   | Ensuring whole system security | With large programmes of work, the Principal Developer is responsible for ensuring a consistent security standard across the whole system, including ensuring that the security solutions in each component is compatible with the other components in the system so that we don't need any compromise in security to get the components to talk to each other. |
-|   | Ensuring whole system supportability | Promoting best practice in terms of SRE. Considering end-to-end software lifecycle (from requirements capture to software delivery, support and eventual sunset). |
-|   | Support Enterprise Capabilities as SME | Logging and Observability  (Elastic) |
-|   |   | Cloud Strategy |
-|   |   | SAST implementation (Snyk)  |
-|   |   | Containerisation (Kubernetes Platform)  |
-|   | Advising on changes to older systems | The Principal Developers have knowledge of a lot of the existing/older systems within the UKHO and will of often be called to advise on either fixing problems with existing systems, or for enhancement of existing systems |
+| | | Identify and support shared libraries. |
+| | Ensuring whole system security | With large programmes of work, the Principal Developer is responsible for ensuring a consistent security standard across the whole system, including ensuring that the security solutions in each component is compatible with the other components in the system so that we don't need any compromise in security to get the components to talk to each other. |
+| | Ensuring whole system supportability | Promoting best practice in terms of SRE. Considering end-to-end software lifecycle (from requirements capture to software delivery, support and eventual sunset). |
+| | Support Enterprise Capabilities as SME | Logging and Observability  (Elastic) |
+| | | Cloud Strategy |
+| | | SAST implementation (Snyk) |
+| | | Containerisation (Kubernetes Platform) |
+| | Advising on changes to older systems | The Principal Developers have knowledge of a lot of the existing/older systems within the UKHO and will of often be called to advise on either fixing problems with existing systems, or for enhancement of existing systems |
 | Technical Product Ownership | Work with architects to define target and transitional solution architectures | Data Hub/UDU, DashboardAvailability |
-|   | Own product backlog, create and detail PBI’s | Data Hub, DashboardAvailability |
-|   | Work with delivery managers to plan and align roadmaps | Data Hub/UDU, DashboardAvailability |
-|   | Contribute to business cases, and work with Service Owners to define a SoW for a product | Data Hub, DashboardAvailability |
-|   | Work with ITSO to ensure product meets security standards via SbD compliance | Data Hub |
+| | Own product backlog, create and detail PBI’s | Data Hub, DashboardAvailability |
+| | Work with delivery managers to plan and align roadmaps | Data Hub/UDU, DashboardAvailability |
+| | Contribute to business cases, and work with Service Owners to define a SoW for a product | Data Hub, DashboardAvailability |
+| | Work with ITSO to ensure product meets security standards via SbD compliance | Data Hub |
 | Strategic Planning for the Development Practice | Strategic selection of Technologies | Assessing new technologies for their appropriateness for UKHO Delivery Teams |
-|   | Implement PoC’s and demonstrate technologies and tooling | Argo Rollouts |
-|   | Contribute and oversee development of cloud and container policies | Container, Cloud Development |
-|   | Define required skills and training for technical teams| |
-|   | What is the long term? Where do we want to be? How do we want delivery teams to deliver software eng in 5 years' time: Technology, People, Skills | |
+| | Implement PoC’s and demonstrate technologies and tooling | Argo Rollouts |
+| | Contribute and oversee development of cloud and container policies | Container, Cloud Development |
+| | Define required skills and training for technical teams | |
+| | What is the long term? Where do we want to be? How do we want delivery teams to deliver software eng in 5 years' time: Technology, People, Skills | |
 | Bridge between teams & Practices | Linking Development and Architecture | Attend APF as Development Practice representative |
-|   | Links with Testing Practice | Working closely with the test leads to help ensure teams deliver using the most appropriate testing practices |
+| | Links with Testing Practice | Working closely with the test leads to help ensure teams deliver using the most appropriate testing practices |
 | Consultancy | | Providing consultancy across the teams and the wider business (TBC) |
 | 3rd Party Technical Contact | Supplier Management | Working with the ADDS Project Managers to define work packages for 3rd party delivery |
-|   || Working closely with the 3rd party delivery team to ensure that the delivery remains on track and provides the technical functionality to fit into the UKHO Systems |
-|   | Helping suppliers integrate into UKHO Systems | |
+| | | Working closely with the 3rd party delivery team to ensure that the delivery remains on track and provides the technical functionality to fit into the UKHO Systems |
+| | Helping suppliers integrate into UKHO Systems | |
 | Recruitment | Consulted on recruitment within software engineering | Although not responsible for recruitment, principals can be consulted to help where necessary, for example by helping to define a role |
diff --git a/using-github/coding-in-the-open.md b/using-github/coding-in-the-open.md
index 12c4ea331..4a01aac36 100644
--- a/using-github/coding-in-the-open.md
+++ b/using-github/coding-in-the-open.md
@@ -80,9 +80,9 @@ If you are uncertain about any commercial software boundary, consult your Securi
 
 ## 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 |
+| 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 |

From 565a6e174b74088abb7a6dee5ec07704b767b8a1 Mon Sep 17 00:00:00 2001
From: Paul King <6100643+gyro2009@users.noreply.github.com>
Date: Wed, 10 Jun 2026 14:28:37 +0100
Subject: [PATCH 3/3] Deal with PR feedback

---
 .../ManagingSecurityConcerns.md               | 23 ++++++++++---------
 .../SecurityChampionResponsibilities.md       |  4 +++-
 2 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/security/ManagingSecurityConcerns/ManagingSecurityConcerns.md b/security/ManagingSecurityConcerns/ManagingSecurityConcerns.md
index cabaa0b2a..98679d464 100644
--- a/security/ManagingSecurityConcerns/ManagingSecurityConcerns.md
+++ b/security/ManagingSecurityConcerns/ManagingSecurityConcerns.md
@@ -22,7 +22,7 @@ To help ensure the security of applications, this process provides a common proc
 
 ## Managing a list of current Security Concerns
 
-Every software development team will keep a **prioritised** list of **current security concerns**. This list should be stored in the same work item tracking system that the team uses for bugs and general work (usually Azure DevOps) and identified using a ticket type of Risk with a tag of Security.
+Every software development team will keep a **prioritised** list of **current security concerns**. This list should be stored in the same work item tracking system that the team uses for bugs and general work (usually Azure DevOps) and identified using a ticket type of Risk with a Risk Category of Security.
 
 Each security concern requires an assessment and the Security Champion or Lead Technical Software Engineer (Security) will ensure that an initial assessment will be carried out within 2 working days of the concern being raised (although this may be carried out by another team member on their behalf). This should give the Security Concern a standard scoring using the Inherent, Residual and Target risk measures.
 
@@ -30,7 +30,7 @@ Each security concern requires an assessment and the Security Champion or Lead T
 > - Residual Risk: Remaining risk after mitigations are in place
 > - Target Risk: The risk appetite your team/application/product is willing to accept
 
-Every sprint, the list of current security concerns should be reviewed by the team and all new security concerns should be highlighted as part of the sprint review.
+On a regular delivery cadence, the list of current security concerns should be reviewed by the team. For sprint teams this should happen during sprint review/planning activities, and for Kanban teams this should happen during their regular flow review or service review. All new security concerns should be highlighted during these reviews.
 
 Additionally, each concern should be assessed to determine if additional training is required to prevent further issues.
 
@@ -66,7 +66,8 @@ Additionally, each concern should be assessed to determine if additional trainin
 
 - Team implements a fix for the security concern.
 - The fix is deployed and tested.
-- Any testing tools that indicated an issue are to retest the issue to ensure this has been resolve or that new issues are not being presented. 
+- Any testing tools that indicated an issue are to retest the issue to ensure this has been resolve or that new issues are not being presented.
+- Update Risk PBI with any information that supports your remediation (PRs, supporting test results, pipeline successes) 
 
 :arrow_down:
 
@@ -76,7 +77,7 @@ Additionally, each concern should be assessed to determine if additional trainin
 
 ### Changes and New Features with a Security Impact
 
-During development, a team will make some changes that will have a security impact. This may be introducing new security features or changing the way that some existing security feature works. These features will be **tagged** with **Security** to highlight to the IT Security Team.
+During development, a team will make some changes that will have a security impact. This may be introducing new security features or changing the way that some existing security feature works. These Risks will be updated with the Category **Security** to highlight to the IT Security Team.
 
 ------
 
@@ -84,7 +85,7 @@ During development, a team will make some changes that will have a security impa
 
 Once a security concern has been identified, it should be raised in the team's backlog. The Risk should have the following characteristics:
 
-- Tagged with **Security**.
+- Risk Category set as **Security**.
 - Title contains detail such as the service name and type of security issue.
 - Include a detailed description of the security concern e.g. Services affected.
 - Risk should contain steps to reproduce the issue (if possible).
@@ -96,17 +97,17 @@ Once a security concern has been identified, it should be raised in the team's b
 A penetration test of the Contoso website has identified a XSS vulnerability on the customer details form.
 
 1. A Risk is raised in the Azure DevOps backlog
-2. The bug is given the following title: *Contoso Website, XSS possible on customer details form.*
-3. The bug is tagged with the following: Security
+2. The Risk is given the following title: *Contoso Website, XSS possible on customer details form.*
+3. The Risk is given the Category: Security
 
 ## Prioritising and Fixing Security Concerns
 
-Discussions of prioritisation will usually happen during the team's planning session. In most cases, the team has the capability to address the security concern within their sprint. The IT Security Team will drive very high priority security concerns, this is usually discussed during SWGs (Security Working Groups) or ad-hoc meetings. In order to escalate an issue use the following guidance:
+Discussions of prioritisation will usually happen during the team's regular prioritisation activities (for example sprint planning/refinement or Kanban replenishment/flow review). In most cases, the team has the capability to address the security concern within their planned work cycle. The IT Security Team will drive very high priority security concerns, this is usually discussed during SWGs (Security Working Groups) or ad-hoc meetings. In order to escalate an issue use the following guidance:
 
 1. Raise the issue with the Security Champion for the team or Lead Technical Software Engineer (Security)
-2. You will inform next steps i.e. raise to an ITSO (IT Security Officer).
-3. ITSO will have an initial discussion with the relevant parties to enable a review of the risk labelled **Security**. With appropriate tagging, queries can be used to easily identify items of interest.
+2. You will be informed of next steps based on the information i.e. raise to an ITSO (IT Security Officer) as High/Critical or raise to an ITSO as a long standing issue with mitigations.
+3. ITSO will have an initial discussion with the relevant parties to enable a review of the risk with the Category **Security**.
 4. In this review ITSO will discuss and verify the risk score. This may require further follow-up meetings with either the Security Champion, or member of staff who raised the concern. Discussions are recorded in the bug.
-5. If the issue is directly related to an existing project and benefits from an opportunity to easily address in a following sprint, this must be pursued first. If required ITSO can contact the Delivery Manager for inclusion in the next sprint planning meeting.
+5. If the issue is directly related to an existing project and benefits from an opportunity to be easily addressed in the next delivery window, this must be pursued first. If required ITSO can contact the Delivery Manager for inclusion in the next appropriate planning or prioritisation meeting.
 6. If the issue fails to be remediated, the issue may need to be risk accepted in which a further conversation with ITSO will be required.
 7. ITSO will discuss the issue and will guide you through the process.
diff --git a/security/SecurityChampions/SecurityChampionResponsibilities.md b/security/SecurityChampions/SecurityChampionResponsibilities.md
index 116ff07a4..c725c7885 100644
--- a/security/SecurityChampions/SecurityChampionResponsibilities.md
+++ b/security/SecurityChampions/SecurityChampionResponsibilities.md
@@ -14,7 +14,7 @@ I coach the team into creating security processes that make our systems secure w
 
 I ensure the team create an effective set of standards for securely developing their software.
 
-I help the team understand the security training materials, and I work to ensure they are all consumed.
+I help the team understand the security training materials, and I work to ensure they are all consumed. I support growth in our learning by feeding back on topics or certifications of interest. 
 
 I have an understanding of security testing tools and use them during development to harden our software.
 
@@ -56,6 +56,8 @@ I'm an expert in how my team’s technologies must be used to keep them secure.
 
 I'm an expert in my team’s security tooling (e.g. static analysis tools, third-party checkers).
 
+I'm well trained and willing to work towards security based qualifications
+
 I understand the security aspects of solution architecture.
 
 I have coaching and influencing skills.