T08 · Insecure Dependencies
- Location
SKILL.md:39- Finding
Unpinned Autonomous Global SDK Installation
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 39-44
Vulnerability Type: Unpinned third-party dependency installation from mutable external instructions
Risk Level: MediumVulnerable Code Snippet
text 1. Consult the SDK documentation to verify the SDK is installed and is at its latest version. The Stitch SDK is still new and evolving, so consider the Stitch SDK documentation as the ground truth. 2. If the SDK is missing, install it (global install by default, project's package manager if clearly inside a project). 3. Verify `STITCH_API_KEY` is set. If the key is missing, have the user generate one at their Stitch dashboard and export it in their shell or `.env`. 4. Make one minimal SDK call to confirm auth. Diagnose and retry once on failure before involving the user. Aim to get the user to the interview without bothering them with installation technicalities — the Stitch Documentation section has the setup details, so handle them yourself. Never display, transcribe, or echo the key.Technical Analysis
The Skill directs the Agent to consult mutable external documentation and autonomously install the latest Stitch SDK globally. It does not specify an exact package name, trusted registry, pinned version, integrity hash, lockfile, or validated installation command.
Treating external documentation as the current “ground truth” means the effective installation procedure can change after this Skill has been audited. Installing the latest package also prevents reproducible dependency resolution. If the documentation, linked domain, package account, registry entry, or dependency chain is compromised, the Agent could install a malicious package. Package installation hooks could then execute arbitrary code with the Agent process's operating-system permissions.
A global installation is broader than required for a single landing-page project. It can modify shared executables and package directories, affect unrelated projects, an ...[truncated 1762 chars]
- Remediation
View remediation
Remediation Suggestions
- Specify the official SDK package name and approved registry explicitly rather than deriving installation commands from mutable documentation.
- Pin an audited SDK version instead of requesting the latest release.
- Record dependency resolution in a project lockfile and verify the package with a published integrity hash or signature.
- Install the SDK project-locally with the existing package manager rather than globally.
- Require explicit user confirmation before adding or upgrading any dependency.
- Disable package lifecycle scripts during installation where supported, then enable only reviewed build steps when necessary.
- Validate the package publisher, registry URL, resolved transitive dependencies, and downloaded integrity metadata before execution.
- Run SDK tooling with access limited to the current project and only the environment variables required for Stitch.
- Avoid placing
STITCH_API_KEYin broadly readable project files; prefer a scoped secret mechanism or process environment with restrictive permissions. - Document a reviewed installation command directly in the Skill so subsequent executions remain reproducible.