harden: the package in package.json

[anupamme]

Summary

Harden input handling in package.json (flagged by multi_agent_ai).

Vulnerability

Field	Value
ID	V-001
Severity	HIGH
Scanner	multi_agent_ai
Rule	V-001
File	package.json:28
Assessment	Defensive hardening

Description: The package.json specifies 5 development dependencies using caret (^) version ranges, allowing automatic updates to minor/patch versions. A compromised package in the @ehmicky scope or a typosquatting attack could inject malicious code into the build pipeline. These dependencies have build-time execution and could exfiltrate source code, inject backdoors, or steal environment variables during CI/CD execution.

Threat Model Context

This is a Node.js library - vulnerabilities affect downstream consumers who use this package.

Changes

• package.json

Behavior Preservation

This change touches only dependency manifest (package.json); no source file in the repository is modified.

---

This patch removes an exploit primitive — a code pattern that, while not independently exploitable today, could be chained with other weaknesses by automated exploit-development tooling. Proactive removal of such primitives raises the bar against increasingly capable automated attack tools.

---

Automated security fix by OrbisAI Security

[ehmicky]

Thanks for this PR.

I get your point, and that's a fair point. But on the other hand, one can argue that the caret notation allows users of this library to get security fixes automatically. This is one of the main ideas behind semantic versioning.

Also, pinning down dependencies versions is a decision that should belong to library users, not to library authors. That decision is highly dependent on the context in which the library is used. For example, it is much more important to pin dependencies deeply in a production environment than a local/dev environment.

Opening PRs in all npm packages that currently exist to pin versions in their package.json is not the way. Instead, users should use the existing settings with their package manager to decide themselves whether they want to pin dependencies deeply or not.

[anupamme]

Thanks for the detailed explanation; that’s a fair distinction. I agree that pinning all devDependencies isn’t necessarily the right policy for the project, especially given the existing lockfile and the fact that these aren’t runtime dependencies.

I’ll close this out rather than pursue the pinning change. I appreciate the context around leaving dependency-version policy to the package/project users and maintainers.