T08 · Insecure Dependencies
- Location
development/SKILL_EN.md:23- Finding
Unpinned Third-Party Boilerplate Introduces Supply-Chain Risk
- Content
View full analysis
Vulnerability Details
File Location:
development/SKILL_EN.md:23
Vulnerability Type: Unpinned and insufficiently verified third-party dependency source
Risk Level: MediumVulnerable Code Snippet:
markdown * Do not build from scratch. Select an appropriate starter template from [awesome-saas-boilerplates](https://github.com/smashing-mag/awesome-saas-boilerplates) based on your tech stack.The equivalent instruction also appears in
development/SKILL_ZH.md:23, whiledevelopment/SKILL_ZH.md:51explicitly describes cloning a boilerplate and configuring environment variables.Technical Analysis
The development skill instructs the agent to select third-party starter code from a mutable external catalog. It does not specify an approved repository, immutable commit hash, signed release, checksum, dependency lockfile, or mandatory security review.
The catalog and repositories it references can change after this skill package has been audited. A selected template may contain malicious or compromised package dependencies, lifecycle scripts, build plugins, CI workflows, configuration files, or application code. If the agent clones the template and installs or builds it without additional review, attacker-controlled code could execute in the developer or CI environment.
The issue is classified as an insecure dependency rather than direct remote payload execution because this package does not itself implement a download-and-execute command. Exploitation depends on a subsequent development workflow selecting and executing unsafe third-party components.
Attack Path
- An attacker compromises a repository listed in the external boilerplate catalog, or gets a malicious repository added to it.
- The agent follows the skill instruction and selects that repository based on the requested technology stack.
- The repository is cloned without pinning it to a previously reviewed commit or verifying its pro ...[truncated 1117 chars]
- Remediation
View remediation
Remediation Suggestions
- Replace open-ended catalog selection with an explicit allowlist of reviewed repositories.
- Pin every approved template to an immutable commit hash or cryptographically signed release.
- Record and verify repository ownership, release signatures, and expected checksums before use.
- Require explicit user approval before cloning a repository or running installation, setup, build, or migration commands.
- Review package manifests, lockfiles, lifecycle scripts, build plugins, CI workflows, container definitions, and setup scripts before execution.
- Install dependencies with lockfile-enforcing and integrity-verifying modes where supported.
- Run initial installation and builds in an isolated container or sandbox with no production credentials, SSH keys, cloud tokens, or unrelated filesystem access.
- Grant CI jobs only the minimum required permissions and do not expose deployment secrets to untrusted pull requests or initial template validation jobs.
- Add automated dependency, secret, malware, and static-analysis scans before accepting generated starter code.
- Apply the same controls to the equivalent instruction in
development/SKILL_ZH.md.
