Update security standards (#125)

Author: johnwatson484

docs/guides/continuous_integration.md

@@ -1,7 +1,5 @@
 # Continuous integration
 
-NOTE: This guidance only applies to repositories and projects which are public on GitHub and can therefore take advantage of several free integrations. We intend to expand upon this guide in the future to cover the rest of our ecosystem.
-
 > Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.
 >
 > [ThoughtWorks](https://www.thoughtworks.com/continuous-integration)
@@ -28,10 +26,27 @@ There are lots of other tools which can integrate with GitHub, especially if you
 
 These tools check the security of your project. This can include reporting vulnerabilities in your dependencies, or doing static analysis on your code.
 
-- Use [Dependabot](https://docs.github.com/en/code-security/tutorials/secure-your-dependencies/dependabot-quickstart-guide) and/or [npm audit](https://docs.npmjs.com/cli/v9/commands/npm-audit) for Node.js projects
-- Use [Hakiri](https://hakiri.io/) for Ruby projects
+#### Dependabot
+
+Enable [Dependabot](https://docs.github.com/en/code-security/dependabot) in each repository to automatically raise pull requests when vulnerable or outdated dependencies are detected. 
+
+Dependabot depends on the [dependency graph](https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-the-dependency-graph) being enabled.
+
+> Dependency graph will shortly be automatically enabled for all repositories by default.
+
+Grouped Dependabot updates are recommended to reduce pull request noise.
+
+#### Dependency review action
+
+Add the [dependency review action](https://github.com/actions/dependency-review-action) to your pull request workflows. It checks whether a PR is introducing any packages with known vulnerabilities and fails the check if so, preventing vulnerable dependencies from being merged.
+
+The review won't catch vulnerabilities in existing dependencies, but it will help prevent new ones from being added.
+
+See the [security standards](../standards/security_standards.md) for more details and an example workflow.
+
+#### GitHub Security tab
 
-These tools are free to use for open source GitHub repositories.
+Regularly review the **Security** tab in your GitHub repository. It provides a continuously-updated view of Dependabot alerts, code scanning results, and secret scanning alerts without needing to trigger a build.
 
 ### Maintainability and test coverage
 
@@ -45,6 +60,6 @@ It will then include your test coverage in its assessment of your code.
 
 SonarQube Cloud is free to use for open source GitHub repositories.
 
-## CI with Jenkins
+### Significant changes
 
-We use Jenkins for our internal build servers.
+GitHub Advanced Security integration added 1 May 2026.

docs/standards/node_standards.md

@@ -2,7 +2,7 @@
 
 ### General
 - Node.js code is JavaScript code and should follow the [JavaScript standards](javascript_standards.md).
-- Don't use TypeScript.
+- Don't use TypeScript without an approved exemption.
 - Session state should not be stored on the node app server. Don't tie a session to a particular node server instance. Use a distributed cache or document storage database and not something like express-session. 
 - Avoid blocking the [main event loop and the worker pool](https://nodejs.org/en/docs/guides/dont-block-the-event-loop/). In short "you shouldn't do too much work for any client in any single callback or task." and consider passing CPU intensive tasks off to another service.
 - Prefer await over callbacks and avoid nested callbacks. This is easily done in [Node 8 and above](https://nodejs.org/api/util.html#util_util_promisify_original).
@@ -16,12 +16,40 @@
 - Don't progress beyond Active LTS versions.
 
 ### Package Management
-- Use NPM.
+- Use npm.
 - Use a package.json and package-lock.json for repeatable builds.
+- Use `npm ci` instead of `npm install` in automated production builds to ensure  the exact versions in `package-lock.json` are installed.  It will also fail if the `package-lock.json` and `package.json` are out of sync, which can help catch mistakes.
 - Use an automated checker such as Dependabot or npm audit to ensure that your dependencies are up to date with the
   latest patches.
 - Separate dependencies and dev dependencies.
 - Update your version number inline with the [semantic versioning standard](https://semver.org/).
+- Vet third-party packages before adding them as dependencies by following this [guide](../guides/choosing_packages.md).
+
+#### .npmrc security settings
+
+Create an `.npmrc` file at the root of each repository with the following settings:
+
+```ini
+save-exact=true
+ignore-scripts=true
+min-release-age=7
+```
+
+| Setting | Purpose |
+|---|---|
+| `save-exact=true` | Saves exact dependency versions rather than version ranges. Prevents version-range drift from silently pulling in a later, potentially vulnerable release. |
+| `ignore-scripts=true` | Prevents npm from running lifecycle scripts such as `preinstall` and `postinstall` during package installation. This blocks a common vector for arbitrary code execution from malicious or compromised packages. Note: some packages that compile native bindings require lifecycle scripts to function. If any packages genuinely need it, then `--ignore-scripts=false` can be passed to the relevant `npm install` command. |
+| `min-release-age=7` | Refuses to install packages published fewer than 7 days ago. This provides a window to detect package takeover or typosquatting attacks before they reach your codebase. Studies have shown that most malicious packages are detected within this timeframe. |
+
+To apply these settings globally across all projects on your machine, either run:
+
+```sh
+npm config set save-exact=true
+npm config set ignore-scripts=true
+npm config set min-release-age=7
+```
+
+or add the three lines directly to your global npm configuration file at `~/.npmrc`.
 
 ### Server framework
 - Our standard framework is [Hapi](https://hapijs.com/).
@@ -43,3 +71,4 @@ This standard was formally adopted on 8 January 2020.
 ### Significant changes
 
 Clarification on preference between CommonJS and ESM added 29 July 2024.
+Add .npmrc security settings added 1 May 2026.

docs/standards/security_standards.md

@@ -9,3 +9,39 @@ The way we build software and systems is rapidly evolving, becoming more and mor
 Use the [OWASP Secure coding practices - quick reference guide](https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide) for details of the standards to apply.
 
 **Important note.** We are using version 2
+
+## GitHub Advanced Security
+
+Defra has GitHub Advanced Security enabled across its organisation. Teams should maximise use of these built-in features rather than relying on third-party tools.
+
+### Dependency graph
+
+Ensure the [dependency graph](https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-the-dependency-graph) is enabled in every repository. It is the foundation for Dependabot alerts and the dependency review action.
+
+### Dependabot
+
+Enable [Dependabot](https://docs.github.com/en/code-security/dependabot) to automatically raise pull requests when vulnerable or outdated dependencies are detected. Grouped updates are recommended to reduce noise — see [grouping Dependabot version updates](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#groups) for configuration details.
+
+### Dependency review action
+
+Add the [GitHub dependency review action](https://github.com/actions/dependency-review-action) to your pull request workflow. It compares the dependencies introduced by a PR against the GitHub Advisory Database and fails the check if any known-vulnerable packages are being added, preventing vulnerabilities from being merged rather than detecting them after the fact.
+
+An example workflow can be found in the [fcp-audit repository](https://github.com/DEFRA/fcp-audit/blob/309fc8ed7022ed981ee620d97bd455799a704cf0/.github/workflows/).
+
+### GitHub Security tab
+
+Regularly review the **Security** tab in your repository. It provides a continuously-updated view of:
+
+- Dependabot alerts for vulnerable dependencies already in the repo
+- Code scanning alerts from static analysis
+- Secret scanning alerts
+
+This means you do not need to wait for a build to run to discover a vulnerability, issues are surfaced as soon as they are detected.
+
+### Snyk
+
+Snyk has been assessed alongside GitHub Advanced Security. As GitHub Advanced Security provides largely equivalent capability and is already available to all Defra teams, teams should look to maximise usage of GitHub Advanced Security rather than relying on Snyk.
+
+### Significant changes
+
+GitHub Advanced Security integration added 1 May 2026.