Feature request: support new npm allowScripts functionality

[GCHQDeveloper581]

Is your feature request related to a problem? Please describe.
For a write-up of the new functionality see https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/

Implication is this is necessary for project to work with npm>=12, and in any case is highly desirable to reduce supply chain risks of dependencies.

Describe the solution you'd like
Validate existing dependencies with preinstall/install/postinstall scripts and allow-list as appropriate

Then set allowScripts to off in package.json

Describe alternatives you've considered
Maintaining the status quo incurs avoidable supply-chain risks

[GCHQDeveloper581]

"npm install" or "npm ci" within github workflows is now reporting on this feature (producing warning for non-allow-listed packages with scripts)

eg https://github.com/gchq/CyberChef/actions/runs/28670059149/job/85031041066

[zainnadeem786]

Hi @GCHQDeveloper581,

I did investigation for npm v12 allowScripts support.

I found the following dependency lifecycle scripts:

Package	Lifecycle	Purpose	Recommendation
chromedriver@148.0.4	install	Downloads/installs ChromeDriver binary used by UI tests	allow
@nightwatch/nightwatch-inspector@1.0.1	postinstall	Builds the Nightwatch inspector extension artifact	allow
core-js@3.49.0	postinstall	Funding/banner script	deny
core-js-pure@3.49.0	postinstall	Funding/banner script	deny
tesseract.js@7.0.0	postinstall	OpenCollective/funding script	deny
fsevents@2.3.3	install	Optional macOS file-watcher native addon	allow or omit depending on desired macOS dev behavior

No dependency preinstall scripts were found.

A possible starting policy in package.json would be:

"allowScripts": {
  "@nightwatch/nightwatch-inspector@1.0.1": true,
  "chromedriver@148.0.4": true,
  "core-js@3.49.0": false,
  "core-js-pure@3.49.0": false,
  "tesseract.js@7.0.0": false,
  "fsevents@2.3.3": true
}

I also checked the current install points:

• .github/workflows/master.yml
• .github/workflows/pull_requests.yml
• .github/workflows/releases.yml
• Dockerfile

The Dockerfile already uses npm ci --ignore-scripts followed by the project’s own npm run postinstall, so I would leave that flow unchanged.

Before opening a PR, I wanted to confirm the preferred policy for fsevents: should it be explicitly allowed to preserve macOS watcher behavior, or explicitly denied/omitted for a stricter allowlist?

Once confirmed, I can open a PR adding the reviewed allowScripts policy and validation notes.

[GCHQDeveloper581]

Thanks for doing this analysis.

I'll check with my colleagues, but my initial take would be to deny fsevents and then put it back if it causing people problems.

Could you hold off a day or two whilst I'm waiting for them to respond.

[GCHQDeveloper581]

@zainnadeem786

Sorry for the delay in following this up. Let's deny fsevents for now, and see if anyone screams!

We'd welcome a PR based on this.

[zainnadeem786]

Hi @GCHQDeveloper581

Thanks for confirming, and no worries at all!

Sounds good I'll proceed with denying fsevents for now and prepare the PR with the reviewed allowScripts policy. I'll also keep the existing Docker workflow unchanged since it already uses npm ci --ignore-scripts followed by the project's own postinstall.

I'll submit the PR shortly. Thanks!