[amit-kanswal-cs]

Problem

DX-29607: the committed package-lock.json on master had 46 npm audit findings (4 critical, 25 high, 15 moderate, 2 low). All of them come from devDependencies: the build, test and docs toolchain.

Repo kind: LIBRARY

@contentstack/ui-extensions-sdk is published on npm (main + files: ["dist"], not private). Consumers never see this repo's lock file or overrides; they resolve our package.json ranges. The two runtime dependencies (post-robot 8.0.29 and wolfy87-eventemitter 5.2.4, both pinned) had no findings. What consumers actually get is the webpack bundle in dist/, so the build toolchain does matter for the shipped artefact.

Fix

• Lock file: a fresh install fails with ERESOLVE on master today. eslint-config-airbnb@19 wants peer eslint ^7 || ^8, and the repo is on eslint ^9. CI works around this with npm ci --legacy-peer-deps. So instead of regenerating the lock, I kept the committed lock and updated only the 46 flagged packages within their existing ranges (npm update <pkgs> --package-lock-only --force). This keeps peer deps in the lock, so Snyk's lock parser still reads it.
• Floor raised (LIBRARY rule): webpack ^5.70.0 → ^5.112.2 (devDependency). The old range allowed the vulnerable 5.49.0–5.104.0. Note: webpack 5.112 swaps its default minimizer (terser-webpack-plugin → minimizer-webpack-plugin), so dist/ui-extension-sdk.js comes out 372 bytes larger. The build output is otherwise equivalent.
• Overrides: none. Every remaining finding needs a cross-major (uuid 8 → 11). Overrides would only fix our own dev install anyway, because overrides and the lock file never reach consumers.
• Package version: not bumped. It was bumped once (2025-12-23, 2.2.4) and not repeatedly in 2026. Releases go through a GitHub release → npm-publish.yml; there are no changesets and no CHANGELOG, so the maintainer bumps at release time.

npm audit, before → after

Severity	Before (master lock)	After
Critical	4	0
High	25	0
Moderate	15	5
Low	2	0
Total	46	5

The Snyk CLI could not be used for this run (the account gets 403 "user does not have required permission on org"), so these numbers come from npm audit only. The org's security-sca check on this PR will give the Snyk view.

What remains, and why

All 5 are moderate, all in devDependencies, and all need a major bump:

• uuid 8.3.2 (<11.1.1, missing buffer bounds check), reached via:
  • nyc 17.1.0 → istanbul-lib-processinfo 2.0.3. Fixed in nyc@18 (major).
  • webpack-dev-server 5.2.7 → sockjs 0.3.24. Fixed in webpack-dev-server@6 (major).

Neither nyc nor webpack-dev-server is used by any script in this repo. Tests use karma-coverage, and the devServer block in webpack.config.js uses v3-only options (contentBase, watchContentBase). The simplest follow-up is to remove both devDependencies, or bump them to their next major.

Also pre-existing and not changed here: the eslint-config-airbnb@19 / eslint@9 peer conflict, which is why CI needs --legacy-peer-deps.

Verification

• npm run build passes (webpack 5.112.2, 0 errors, the same lint warnings as master).
• npm test (karma, ChromeHeadless): 128/133 pass on both master and this branch. The same 5 postMessage-ack specs fail on master too, so these failures are pre-existing.
• CI's own install command, npm ci --legacy-peer-deps, installs the new lock cleanly.
• Snyk's lock parser (with dev deps) reads both the master lock and the new lock: OK.

🤖 Generated with Claude Code

Release prep: version 2.2.5 and compatibility check

Version bump

• package.json / package-lock.json: 2.2.4 → 2.2.5 (patch). SDK_VERSION, which is read from package.json at build time and sent to the host on init(), becomes 2.2.5.
• Note: npm's latest is 2.2.3. 2.2.4 was never published, so the next release goes from 2.2.3 to 2.2.5.
• README.md and blueprint.json were regenerated with the repo's own generate:sri + readme flow. The CDN snippet now points to @2.2.5, with the integrity hash of the 2.2.5 bundle. The URL resolves once 2.2.5 is published.

Is anything breaking for consumers? No.

The steps of npm-publish.yml were reproduced on Node 16 (npm ci --legacy-peer-deps → prepare → webpack build → npm test → npm pack), for both master and this PR:

Check	master	this PR
npm ci --legacy-peer-deps + build on Node 16	✅	✅
Runtime dependencies	post-robot 8.0.29, wolfy87-eventemitter 5.2.4	identical
Public API of the UMD bundle	ContentstackUIExtension with init, SDK_VERSION	identical
dist/ui-extension-sdk.css	—	byte-identical, so the existing CSS SRI is still valid
dist/ui-extension-sdk.js	77,296 B	77,668 B (+372 B: webpack 5.112's default minimizer)
Files in npm pack	8	same 8
Karma tests (ChromeHeadless)	128/133	128/133. The same 5 tests fail on master (init, init failure, getField Invalid Uid, Extension initialize, setReady), so they predate this PR.

• Build reproducibility: building master on Node 16 reproduces the README's existing CSS hash. The README's JS/CSS hashes match the files published for 2.2.3. Two Node 16 builds of 2.2.5 produce the same JS hash. So the new README hash will match what the publish workflow builds, as long as it stays on Node 16 and this lock file.
• After publishing 2.2.5, double-check the CDN hash: curl -s https://unpkg.com/@contentstack/ui-extensions-sdk@2.2.5/dist/ui-extension-sdk.js | openssl dgst -sha512 -binary | base64 should print in0mMjQmxKUrHCmC1+9I7IzBQMTA3FVUI+/txGpGSFdgy65iYuQR9eGFSJ4H/qgR1Qd40NOLsaE/bTGDLAQP7A==.

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[github-actions]

🔒 Security Scan Results

ℹ️ Note: Only vulnerabilities with available fixes (upgrades or patches) are counted toward thresholds.

Check Type	Count (with fixes)	Without fixes	Threshold	Result
🔴 Critical Severity	0	0	10	✅ Passed
🟠 High Severity	0	0	25	✅ Passed
🟡 Medium Severity	0	0	500	✅ Passed
🔵 Low Severity	0	0	1000	✅ Passed

⏱️ SLA Breach Summary

✅ No SLA breaches detected. All vulnerabilities are within acceptable time thresholds.

Severity	Breaches (with fixes)	Breaches (no fixes)	SLA Threshold (with/no fixes)	Status
🔴 Critical	0	0	15 / 30 days	✅ Passed
🟠 High	0	0	30 / 120 days	✅ Passed
🟡 Medium	0	0	90 / 365 days	✅ Passed
🔵 Low	0	0	180 / 365 days	✅ Passed

✅ BUILD PASSED - All security checks passed

[github-actions]

🔒 Security Scan Results

ℹ️ Note: Only vulnerabilities with available fixes (upgrades or patches) are counted toward thresholds.

Check Type	Count (with fixes)	Without fixes	Threshold	Result
🔴 Critical Severity	0	0	10	✅ Passed
🟠 High Severity	0	0	25	✅ Passed
🟡 Medium Severity	0	0	500	✅ Passed
🔵 Low Severity	0	0	1000	✅ Passed

⏱️ SLA Breach Summary

✅ No SLA breaches detected. All vulnerabilities are within acceptable time thresholds.

Severity	Breaches (with fixes)	Breaches (no fixes)	SLA Threshold (with/no fixes)	Status
🔴 Critical	0	0	15 / 30 days	✅ Passed
🟠 High	0	0	30 / 120 days	✅ Passed
🟡 Medium	0	0	90 / 365 days	✅ Passed
🔵 Low	0	0	180 / 365 days	✅ Passed

✅ BUILD PASSED - All security checks passed

[github-actions]

🔒 Security Scan Results

ℹ️ Note: Only vulnerabilities with available fixes (upgrades or patches) are counted toward thresholds.

Check Type	Count (with fixes)	Without fixes	Threshold	Result
🔴 Critical Severity	0	0	10	✅ Passed
🟠 High Severity	0	0	25	✅ Passed
🟡 Medium Severity	0	0	500	✅ Passed
🔵 Low Severity	0	0	1000	✅ Passed

⏱️ SLA Breach Summary

✅ No SLA breaches detected. All vulnerabilities are within acceptable time thresholds.

Severity	Breaches (with fixes)	Breaches (no fixes)	SLA Threshold (with/no fixes)	Status
🔴 Critical	0	0	15 / 30 days	✅ Passed
🟠 High	0	0	30 / 120 days	✅ Passed
🟡 Medium	0	0	90 / 365 days	✅ Passed
🔵 Low	0	0	180 / 365 days	✅ Passed

✅ BUILD PASSED - All security checks passed