Add package management clarification (#135)

Author: johnwatson484

docs/standards/node_standards.md

@@ -41,6 +41,8 @@ min-release-age=7
 | `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. |
 
+> Note: from v12 of npm, `ignore-scripts` is set to `true` by default.
+
 To apply these settings you must also configure them globally across all projects on your machine. Run the following commands to ensure you are protected from any repository you interact with, even if you don't own it.
 
 ```sh
@@ -53,6 +55,23 @@ Or add the three lines directly to your global npm configuration file at `~/.npm
 
 > There may be scenarios where it would be advantageous to bypass the seven day release age requirement, such as when you need to immediately patch a vulnerability. In these cases, you should do appropriate due diligence on the package and its publisher before installing it, and consider temporarily disabling the setting if necessary. You can bypass the setting for a single install command with `--min-release-age=0`.
 
+#### Other package management tools
+
+npm has been chosen as our standard package management tool as it is the most widely used and supported.  Using a common package management tool enables us to share knowledge and best practices across teams.  Particularly in response to supply chain attacks.
+
+There may be scenarios where there is evidence that another package management tool is more appropriate for a more niche project setup.
+
+These potential benefits must be weighed against the disadvantages of using a less common package management tool, such as:
+- less community support and documentation
+- less knowledge sharing across teams
+- isolated and increased response effort to supply chain attacks
+- requirement to learn how the tool's package resolution and dependency management works, which may be different to npm
+- because dependency resolution and vulnerability auditing vary between package managers, teams need to understand the different supply-chain risks and attack paths each tool introduces.
+
+Any package management tool must be supported by GitHub Advanced Security for vulnerability and malware scanning to the same level as npm.
+
+Use of package management tools other than npm must be approved at the appropriate governance level.  Please speak to a Principal Developer for more information.
+
 ### Server framework
 - Our standard framework is [Hapi](https://hapijs.com/).
 - Be aware of the [Hapi support timeline](https://hapi.dev/support/#plans).
@@ -61,6 +80,7 @@ Or add the three lines directly to your global npm configuration file at `~/.npm
   considered unmaintainable and unsupportable until brought up to an appropriate version.
 
 ### CommonJS vs ES modules
+
 - ES modules should be used by default over CommonJS modules.
 - For scenarios where ES modules are not appropriate then CommonJS may be used.
 
@@ -72,5 +92,7 @@ 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.
+- Clarification on preference between CommonJS and ESM added 29 July 2024.
+- Add `.npmrc` security settings added 1 May 2026.
+- Clarification on use of other package management tools added 18 June 2026.
+