T08 · Insecure Dependencies
Error
- Location
- package.json:17
- Finding
- Unpinned and Non-Reproducible Credential-Handling Dependency## Vulnerability Details **File Location**: `package.json:17`; related lockfile evidence at `package-lock.json:12`, `package-lock.json:24-26`, and `package-lock.json:2104-2106` **Vulnerability Type**: Insecure third-party dependency and unsafe dependency source **Risk Level**: High ### Vulnerable Code `package.json:15-19`: ```json "dependencies": { "bring-shopping": "*", "chalk": "^4.1.2", "commander": "^11.1.0" } ``` `package-lock.json:2104-2107`: ```json "node_modules/bring-shopping": { "resolved": "../../skills-temp", "link": true }, ``` The dependency receives the user's Bring! credentials in `index.js:6` and `index.js:57-65`: ```js const Bring = require('bring-shopping'); ``` ```js const bring = new Bring({ mail: process.env.BRING_EMAIL, password: process.env.BRING_PASSWORD }); try { await bring.login(); ``` ### Technical Analysis The security-sensitive `bring-shopping` dependency is declared using the unrestricted wildcard version `"*"`. This permits future installations to select package releases that were not reviewed as part of this audit. The lockfile does not mitigate that exposure reliably because it resolves the package to `../../skills-temp`, a linked local directory outside the audited project. The implementation of that target is absent from the supplied artifact, and the lockfile entry provides neither an immutable registry artifact nor an integrity hash for this dependency. This dependency is security-critical because the application imports it and directly supplies the user's `BRING_EMAIL` and `BRING_PASSWORD` values to its constructor before invoking `login()`. Any malicious or substituted implementation would execute within the CLI's Node.js process and could access those credentials, the environment, files available to the user, and the user's network permissions. ### Attack Path 1. An attacker publishes or compromises a future `bring-shopping` release accepted by the wildcard constraint, or modifies/su ...[truncated 1468 chars]
- Remediation
- ## Remediation Suggestions 1. Replace the wildcard dependency with an exact, reviewed version: ```json "bring-shopping": "2.0.1" ``` 2. Regenerate `package-lock.json` using the intended official registry. Verify that the resulting entry records: - An exact version. - An HTTPS registry URL. - A package integrity hash. - No `link: true` or relative external path. 3. Reject local, file-based, Git-based, or workspace-link dependency sources in release artifacts unless they are deliberately vendored and included in the security review. 4. Enforce reproducible installations in CI with `npm ci` and fail builds if the lockfile changes unexpectedly. 5. Add automated dependency-policy checks that prohibit wildcard versions and unexpected non-registry sources. 6. Review the selected `bring-shopping` release, including install scripts, runtime network behavior, credential handling, and transitive dependencies. 7. Use a restricted API token instead of an account password if the service supports token-based authentication. Avoid granting third-party libraries long-lived primary credentials where possible. 8. Correct `SKILL.md:145`, which says the implementation uses `node-bring-api`, so that documentation accurately identifies the dependency that receives user credentials.