T08 · Insecure Dependencies
- Location
SKILL.md:13- Finding
Unpinned Third-Party npm Package Installed Globally
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 13–20 and 30–32
Vulnerability Type: Unpinned third-party dependency with global installation
Risk Level: MediumComplete Code Snippet
yaml "install": [ { "id": "npm", "kind": "npm", "package": "@spfunctions/cli", "bins": ["sf"], "label": "Install @spfunctions/cli (npm)", }, ],bash npm install -g @spfunctions/cli sf setup # Interactive configuration wizardTechnical Analysis
The installation instructions retrieve
@spfunctions/cliwithout specifying an exact version or package integrity value. Consequently, the installed code depends on whichever release the npm registry resolves at installation time. This prevents the reviewed Skill definition from guaranteeing that users will receive a previously audited artifact.npm packages can execute lifecycle scripts during installation unless those scripts are explicitly disabled. The documented
-goption also exposes the resultingsfexecutable system-wide within the installing user's environment. The package implementation is not included in the audited project, so its installation scripts, credential handling, network behavior, and trading operations could not be independently reviewed.The same document directs users to run
sf setupand configureSF_API_KEY,KALSHI_API_KEY_ID, andKALSHI_PRIVATE_KEY_PATH. These credentials are legitimate for the declared functionality, but an unsafe or compromised package release could potentially access them.Attack Path
- An attacker compromises the npm publisher account, package build pipeline, or a future release of
@spfunctions/cli. - The attacker publishes a modified package version containing a malicious lifecycle script or executable.
- A user follows the documented
npm install -g @spfunctions/cliinstruction, which resolves the compromised releas ...[truncated 1346 chars]
- An attacker compromises the npm publisher account, package build pipeline, or a future release of
- Remediation
View remediation
Remediation Suggestions
- Pin
@spfunctions/clito a specific, reviewed version rather than allowing npm to select the latest release. - Record and verify the package's expected integrity hash before installation.
- Prefer a project-local installation governed by a committed lockfile instead of global installation.
- Disable npm lifecycle scripts during installation where compatible with the package, and separately review any scripts that must execute.
- Link to a verifiable official source repository and document how published artifacts correspond to reviewed source and builds.
- Run the CLI with a dedicated, least-privileged operating-system account or sandbox.
- Use narrowly scoped API credentials with only the permissions necessary for the requested operation. Separate read-only monitoring credentials from credentials capable of placing trades.
- Protect the Kalshi private key with restrictive filesystem permissions and avoid exposing secrets through command-line arguments, logs, or plaintext configuration.
- Require explicit human confirmation for trade execution and other irreversible financial actions.
- Establish package provenance verification, publisher-account protection, release signing, automated dependency scanning, and a documented credential-revocation procedure.
- Pin
