fix(security): resolve S360/Component Governance alerts (0 high, 0 moderate)

[Jayanth Reddy Bujula (jbujula)]

Summary

Resolves the S360 / Component Governance alerts assigned for powerplatform-cli-wrapper (CG component 240491).

Component Governance flagged paths under /powerplatform-cli-wrapper/node_modules/**. Those copies are baked into the published @microsoft/powerplatform-cli-wrapper tarball, so they can only be fixed here - fixing them in powerplatform-build-tools has no lasting effect (it gets overwritten on the next wrapper release).

Result

npm audit: 17 high / 13 moderate -> 0 high / 0 moderate / 0 critical.

Changes

Package	Action	Advisory
brace-expansion	lock refresh -> 1.1.18 / 2.1.4 / 5.0.9	GHSA-rgw5-rvv9-x895 (ReDoS), zero-step infinite loop
lodash	override ^4.18.0	command injection / prototype pollution
nanoid	override ^3.3.17	predictable results with non-integer values
tmp	override ^0.2.6	arbitrary file write via symlink
js-yaml	override ^4.3.1	prototype pollution
serialize-javascript	override ^7.0.5	XSS
postcss	override ^8.5.23	line return parsing error
release-it	^17.3.0 -> ^21.0.1	@octokit/* ReDoS
minimatch / diff	via gulp-mocha > mocha override	ReDoS / jsdiff DoS

Note on the gulp-mocha override

gulp-mocha@8 bundles mocha@8.4.0, which pins exact versions:

{ "minimatch": "3.0.4", "diff": "5.0.0" }

Because they are exact pins, neither npm dedupe nor a range override can shift them, and a flat top-level minimatch override is unsafe (the tree spans majors 3, 5 and 10 - it would silently downgrade glob's minimatch@10).

The fix points gulp-mocha at the repo's own mocha devDependency:

"overrides": { "gulp-mocha": { "mocha": "$mocha" } }

This removes the entire bundled mocha@8.4.0 subtree, taking minimatch@3.0.4 and diff@5.0.0 with it. Upgrading gulp-mocha to v10 was tried first and rejected - it broke the test run.

Verification

• npm ci - clean, lock is self-consistent
• npm run ci - compile + lint pass
• Vulnerable versions confirmed gone on disk, not just in the lockfile
• Full CI on this PR (Node 16) is the authoritative check

Remaining (accepted risk)

6 low findings, all dev-only: rewiremock -> node-libs-browser -> crypto-browserify/elliptic. rewiremock@^3.14.6 is already the latest release and npm's suggested "fix" is a downgrade to 3.5.2. Not shipped to consumers.

Supersedes

Dependabot PRs #502, #503, #504, #500, #501, #495, #496, #487, #493, #486, #488, #498.

[Jayanth Reddy Bujula (jbujula)]

Heads-up: one new advisory landed after this PR was verified

GHSA-2v37-7h3g-55p8 (high) was published against nanoid < 3.3.18 - after this branch was audited clean. It also cascades to postcss, which npm audit flags purely via nanoid ("via": ["nanoid"]), not on its own.

No change is needed in this PR. The override here is already a caret range:

"nanoid": "^3.3.17"

which permits 3.3.18 - so this needs only a lockfile refresh, not a version bump.

Why it is not refreshed here yet: nanoid@3.3.18 is released upstream (tagged in ai/nanoid) but has not reached the internal feed proxy:

$ npm view nanoid@3.3.18 version
npm error code E404
npm error 404  'nanoid@3.3.18' is not in this registry.   (registry: https://packagefeedproxy.microsoft.io/npm/)

Pinning ^3.3.18 today would fail npm ci outright, so it is deliberately left alone.

This is precisely the recurring-alert pattern the automation in the companion PR is meant to absorb: its weekly npm update will pick up 3.3.18 on its own once the mirror syncs, with no human change. Until then it is a known, tracked gap rather than a silent one.