From 91833c72cbcf88a2050645cf17c1a5a4baddead6 Mon Sep 17 00:00:00 2001 From: Paul King <6100643+gyro2009@users.noreply.github.com> Date: Mon, 13 Jul 2026 13:55:39 +0100 Subject: [PATCH 1/3] Add policy around dependency management --- package-lock.json | 51 +++------ package.json | 4 + .../ManagingDependencies.md | 108 ++++++++++++++++++ 3 files changed, 129 insertions(+), 34 deletions(-) create mode 100644 security/DependencyManagement/ManagingDependencies.md diff --git a/package-lock.json b/package-lock.json index 642899c4..57da4def 100644 --- a/package-lock.json +++ b/package-lock.json @@ -169,9 +169,9 @@ "license": "ISC" }, "node_modules/@pnpm/npm-conf": { - "version": "2.3.1", - "resolved": "https://registry.npmjs.org/@pnpm/npm-conf/-/npm-conf-2.3.1.tgz", - "integrity": "sha512-c83qWb22rNRuB0UaVCI0uRPNRr8Z0FWnEIvT47jiHAmOIUHbBOg5XvV7pM5x+rKn9HRpjxquDbXYSXr3fAKFcw==", + "version": "3.0.2", + "resolved": "https://registry.npmjs.org/@pnpm/npm-conf/-/npm-conf-3.0.2.tgz", + "integrity": "sha512-h104Kh26rR8tm+a3Qkc5S4VLYint3FE48as7+/5oCEcKR2idC/pF1G6AhIXKI+eHPJa/3J9i5z0Al47IeGHPkA==", "license": "MIT", "dependencies": { "@pnpm/config.env-replace": "^1.1.0", @@ -509,10 +509,13 @@ } }, "node_modules/balanced-match": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/balanced-match/-/balanced-match-1.0.2.tgz", - "integrity": "sha512-3oSeUO0TMV67hN1AmbXsK4yaqU7tjiHlbxRDZOpH0KW9+CeX4bRAaX0Anxt0tx2MrpRpWwQaPwIlISEJhYU5Pw==", - "license": "MIT" + "version": "4.0.4", + "resolved": "https://registry.npmjs.org/balanced-match/-/balanced-match-4.0.4.tgz", + "integrity": "sha512-BLrgEcRTwX2o6gGxGOCNyMvGSp35YofuYzw9h1IMTRmKqttAZZVU67bdb9Pr2vUHA8+j3i2tJfjO6C6+4myGTA==", + "license": "MIT", + "engines": { + "node": "18 || 20 || >=22" + } }, "node_modules/boxen": { "version": "7.1.1", @@ -549,12 +552,15 @@ } }, "node_modules/brace-expansion": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.1.0.tgz", - "integrity": "sha512-TN1kCZAgdgweJhWWpgKYrQaMNHcDULHkWwQIspdtjV4Y5aurRdZpjAqn6yX3FPqTA9ngHCc4hJxMAMgGfve85w==", + "version": "5.0.7", + "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-5.0.7.tgz", + "integrity": "sha512-7oFy703dxfY3/NLxC1fh2SUCQ0H9rmAY+5EpDVfXjUTTs+HEwR2nYaqLv+GWcTsumwxPfiz6CzCNkwXwBUwqCA==", "license": "MIT", "dependencies": { - "balanced-match": "^1.0.0" + "balanced-match": "^4.0.2" + }, + "engines": { + "node": "18 || 20 || >=22" } }, "node_modules/bubble-stream-error": { @@ -2289,29 +2295,6 @@ "node": ">=20" } }, - "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": "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": { - "balanced-match": "^4.0.2" - }, - "engines": { - "node": "18 || 20 || >=22" - } - }, "node_modules/markdownlint-cli/node_modules/ignore": { "version": "7.0.5", "resolved": "https://registry.npmjs.org/ignore/-/ignore-7.0.5.tgz", diff --git a/package.json b/package.json index 418ea96e..7ca4cbdc 100644 --- a/package.json +++ b/package.json @@ -25,5 +25,9 @@ "devDependencies": { "husky": "^9.1.7", "markdownlint-cli": "^0.48.0" + }, + "overrides": { + "@pnpm/npm-conf": "3.0.2", + "brace-expansion": "5.0.7" } } diff --git a/security/DependencyManagement/ManagingDependencies.md b/security/DependencyManagement/ManagingDependencies.md new file mode 100644 index 00000000..19d45f3d --- /dev/null +++ b/security/DependencyManagement/ManagingDependencies.md @@ -0,0 +1,108 @@ +# Managing Dependencies + +- [Managing Dependencies](#managing-dependencies) + - [Introduction](#introduction) + - [Policy Statement](#policy-statement) + - [Required Controls](#required-controls) + - [Tooling Approach](#tooling-approach) + - [Snyk](#snyk) + - [Dependabot](#dependabot) + - [Using Snyk and Dependabot Together](#using-snyk-and-dependabot-together) + - [Vulnerability Prioritisation and Timescales](#vulnerability-prioritisation-and-timescales) + - [Exceptions and Escalation](#exceptions-and-escalation) + - [Evidence and Auditability](#evidence-and-auditability) + - [References](#references) + +## Introduction + +Managing dependencies is a core part of maintaining secure, reliable software. This policy sets out the minimum expectations for repository-level dependency management, including the use of Dependabot, Snyk, or a combination of both. + +## Policy Statement + +All software repositories must have a defined and active dependency management approach that: + +- Identifies vulnerable or outdated dependencies early. +- Creates a clear path to remediation through tracked work. +- Supports timely remediation in line with internal policy. +- Produces auditable evidence of decisions, fixes and exceptions. + +Dependency and vulnerability management activities must follow the internal **Patch and Vulnerability Management Policy - POL218**. + +## Required Controls + +Teams must ensure that: + +- Dependency and vulnerability checks are enabled for active repositories. +- Dependency updates are reviewed and merged through standard pull request controls. +- Security fixes are prioritised based on risk and business impact. +- Remediation work is tracked in the team's backlog and linked to pull requests. +- Suppressions, accepted risks or deferred fixes are documented with justification and review date. + +## Tooling Approach + +Teams may use Snyk, Dependabot, or both, provided policy outcomes are met. + +### Snyk + +Snyk dependency management is enabled by default for repositories. + +- Teams should use Snyk results to identify vulnerable packages and prioritise remediation. +- Where tuning is needed (for example policy behaviour, project configuration or alert handling), contact the **Lead Technical Security Engineer (Security)** for support. + +### Dependabot + +Dependabot should be enabled to support: + +- Dependabot alerts +- Dependabot security updates +- Dependabot version updates + +Dependabot setup instructions: + +- [Configuring Dependabot version updates](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuring-dependabot-version-updates) +- [Configuring Dependabot security updates](https://docs.github.com/en/code-security/dependabot/dependabot-security-updates/configuring-dependabot-security-updates) +- [About Dependabot alerts](https://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts) + +Repository baseline expectations for security tooling are also described in the [Repository Setup Policy](/software-engineering-policies/SourceControl/RepositorySetupPolicy.md). + +### Using Snyk and Dependabot Together + +Using both tools is recommended where possible: + +- Dependabot supports automated pull requests for updates. +- Snyk provides additional vulnerability insight and policy-driven prioritisation. +- Combined usage improves visibility, remediation speed and confidence in dependency hygiene. + +## Vulnerability Prioritisation and Timescales + +All dependency vulnerabilities must be assessed and remediated in line with **POL218** severity and remediation timescales. + +- Teams should adhere to POL218 timescales wherever possible. +- If a timescale cannot be met, teams must record rationale, mitigations and revised target date. +- Any decision to defer remediation must be agreed with the appropriate risk owner and captured in team tracking. + +## Exceptions and Escalation + +Where remediation cannot be completed within policy timescales, teams must: + +- Raise and track the security concern in the team backlog. +- Define interim mitigations and owner. +- Escalate through the team's Security Champion and/or the Lead Technical Security Engineer (Security) where required. + +For guidance on security concern handling, see [Managing Security Concerns](../ManagingSecurityConcerns/ManagingSecurityConcerns.md). + +## Evidence and Auditability + +Teams should retain evidence showing dependency management is operating effectively, including: + +- Enabled tool configuration (Snyk and/or Dependabot). +- Open and closed dependency/security pull requests. +- Vulnerability remediation records and linked backlog items. +- Documented exceptions, suppressions and approvals. + +## References + +- Patch and Vulnerability Management Policy - POL218 (internal policy) +- [Repository Setup Policy](/software-engineering-policies/SourceControl/RepositorySetupPolicy.md) +- [Secure Development Policy](/software-engineering-policies/SecureDevelopment/SecureDevelopmentPolicy.md) +- [Managing Security Concerns](../ManagingSecurityConcerns/ManagingSecurityConcerns.md) From 81125868053fba594c1106a1499b3501f2a9a57d Mon Sep 17 00:00:00 2001 From: Paul King <6100643+gyro2009@users.noreply.github.com> Date: Mon, 13 Jul 2026 14:09:29 +0100 Subject: [PATCH 2/3] Updated to remove old tech --- .../Pipelines/Baseline_Policy.md | 18 +++++++----------- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/software-engineering-policies/Pipelines/Baseline_Policy.md b/software-engineering-policies/Pipelines/Baseline_Policy.md index 617f6cd7..cbb7257d 100644 --- a/software-engineering-policies/Pipelines/Baseline_Policy.md +++ b/software-engineering-policies/Pipelines/Baseline_Policy.md @@ -107,20 +107,16 @@ Legacy applications may well be exempt from this statement due to existing desig Pipeline Threat Modelling should be carried out in all design, innovation and development work relating to pipelines, considering where threats may develop or emerge over time. Security is a vital aspect of how our pipelines should be designed and developed, the following approaches are detailed and should be considered per product pipeline: ### Must - -- Dependency Checking - we recommend the OWASP dependency checker, other options are valid but consider impact on support and required knowledge for future changes. -- Static Application Security Testing (SAST) - Coverity is the current SAST offering, alternate options must be equivalent in provision. +- Implementation of the UKHO Snyk scan task is high recommended + - [Dependency Checking](https://github.com/UKHO/ukho-azure-pipeline-scan-task) - Implementation of the UKHO Snyk scan task is high recommended. + - [Static Application Security Testing (SAST)](https://github.com/UKHO/ukho-azure-pipeline-scan-task) + - [Infrastructure as Code Scanning](https://github.com/UKHO/ukho-azure-pipeline-scan-task) + - [Container Scanning](https://github.com/UKHO/ukho-azure-pipeline-scan-task) - Secret values required by deployment must be backed by an Azure key vault -### Should - Added by UKHO - -- Static Code Analysis (SCA) - Coverity contains the functionality to do this, future implementation examples to follow. Alternatives are available but should be justified (consider support and knowledge impact/requirement when using alternatives). -- Container Security Screening - Currently trialing Snyk and ECR (currently used by Data Science/Engineering) depending on technology stack. - -### Could - Added by UKHO +### Should -- Software Composition Analysis - Coverity also has the ability to provide this. -- Dynamic Application Security Testing (DAST) - No set or experimental implementations currently, future research to follow. +- Dynamic Application Security Testing (DAST) - Invicti is setup to perform this. If you require the ability to perform testing from a pipeline, contact your Lead Technical Software Engineer (Security) to discuss the details. ## Working Principles From 2bc08fd859bc6380702d95f95acb18fe9be9a443 Mon Sep 17 00:00:00 2001 From: Paul King <6100643+gyro2009@users.noreply.github.com> Date: Mon, 13 Jul 2026 14:10:11 +0100 Subject: [PATCH 3/3] Fix policy --- software-engineering-policies/Pipelines/Baseline_Policy.md | 1 + 1 file changed, 1 insertion(+) diff --git a/software-engineering-policies/Pipelines/Baseline_Policy.md b/software-engineering-policies/Pipelines/Baseline_Policy.md index cbb7257d..2d39f67c 100644 --- a/software-engineering-policies/Pipelines/Baseline_Policy.md +++ b/software-engineering-policies/Pipelines/Baseline_Policy.md @@ -107,6 +107,7 @@ Legacy applications may well be exempt from this statement due to existing desig Pipeline Threat Modelling should be carried out in all design, innovation and development work relating to pipelines, considering where threats may develop or emerge over time. Security is a vital aspect of how our pipelines should be designed and developed, the following approaches are detailed and should be considered per product pipeline: ### Must + - Implementation of the UKHO Snyk scan task is high recommended - [Dependency Checking](https://github.com/UKHO/ukho-azure-pipeline-scan-task) - Implementation of the UKHO Snyk scan task is high recommended. - [Static Application Security Testing (SAST)](https://github.com/UKHO/ukho-azure-pipeline-scan-task)