T08 · Insecure Dependencies
- Location
scripts/package.json:12- Finding
Non-Reproducible Dependency Installation Through an Unpinned Version Range
- Content
View full analysis
Vulnerability Details
File Location:
scripts/package.json, line 12; related installation instructions inSKILL.md, lines 22–24
Vulnerability Type: Supply-chain risk caused by an unlocked dependency
Risk Level: MediumVulnerable Code
json "dependencies": { "@mondaydotcomorg/api": "^14.0.0" }The documented installation process executes:
bash npm install --prefix ~/.agents/skills/monday/scriptsNo dependency lockfile is included in the audited project.
Technical Analysis
The caret constraint
^14.0.0permits npm to install later compatible releases rather than the exact dependency version represented at audit time. Because the project does not include a lockfile, dependency resolution is not reproducible and may change between installations.Although the dependency name and referenced sources appear to belong to the official monday.com client, future or compromised releases matching this range would not have been covered by this audit. npm may also execute dependency lifecycle scripts during installation. At runtime, the dependency receives the
MONDAY_API_TOKENthrough the client configuration, making dependency integrity particularly important.Attack Path
- An attacker compromises the package publisher, registry delivery path, or a future package release that satisfies
^14.0.0. - The user follows the documented
npm installcommand. - npm resolves the compromised release because no reviewed lockfile fixes the dependency graph.
- Malicious package code may execute through an npm lifecycle script during installation or when imported by
scripts/monday.js. - Runtime dependency code may access the Node.js process environment, including
MONDAY_API_TOKEN, and may act with the operating-system privileges of the user running the Skill.
Impact Assessment
Successful exploitation could execute arbitrary code under the account installing or invoking the Skill. This may expose
MONDAY_API_TOKEN, ...[truncated 466 chars]- An attacker compromises the package publisher, registry delivery path, or a future package release that satisfies
- Remediation
View remediation
Remediation Suggestions
- Pin the dependency to an exact reviewed version rather than using a caret range:
json "dependencies": { "@mondaydotcomorg/api": "14.0.0" }- Generate, review, and commit a
package-lock.jsonso the complete dependency graph and integrity hashes are fixed. - Replace the documented
npm installworkflow withnpm ci, which installs strictly from the lockfile and fails if the manifest and lockfile disagree. - Use
npm ci --ignore-scriptswhen dependency lifecycle scripts are not required. If scripts are required, review them before installation. - Run dependency vulnerability and provenance checks in CI, and use automated update tooling that subjects dependency changes to review and testing.
- Install and run the Skill with least privilege, and expose
MONDAY_API_TOKENonly to the process that requires it. - Rotate the monday.com token immediately if dependency compromise is suspected.
