T08 · Insecure Dependencies
Error
- Location
- SKILL.md:12
- Finding
- Unpinned Third-Party Package Is Retrieved and Executed Through bunx## Vulnerability Details **File Location**: `SKILL.md:12-17`; also referenced in `references/workflows.md:7` and `references/workflows.md:136` **Vulnerability Type**: Supply-chain risk caused by unpinned third-party package execution **Risk Level**: High **Vulnerable Code Snippet**: ```markdown Run with Bun (no install required): ```bash bunx antipattern-czar bunx antipattern-czar --src lib bunx antipattern-czar --config my-config.json ``` ``` The execution instruction is reinforced by the workflow: ```markdown 2. Run detector: `bunx antipattern-czar` ``` The documented error-handling command also references the same unpinned package: ```markdown - Detector fails → report error, ask user to check Bun and package availability (`bunx antipattern-czar --version`) ``` ### Technical Analysis The Skill instructs the Agent to execute `antipattern-czar` through `bunx` without specifying an exact package version, integrity hash, lockfile, verified publisher, or trusted artifact source. If the package is not already available locally, the package runner may resolve and retrieve it from an external package registry before immediately executing its lifecycle or command-line code. Because dependency resolution is not pinned, the effective executable can change after this Skill has been reviewed. A malicious new release, compromised publisher account, registry compromise, package replacement, or dependency-confusion condition could cause attacker-controlled code to run when a user requests a scan. The package executes with the permissions of the Agent process. The intended detector already needs access to the target source tree, so malicious package code could abuse that access to inspect or alter project files. Depending on the surrounding runtime environment, it could also access environment variables, user-readable credentials, network resources, and other files available to the process. ...[truncated 1967 chars]
- Remediation
- ## Remediation Suggestions 1. Pin the detector to an exact, reviewed package version rather than resolving the latest release: ```bash bunx antipattern-czar@1.2.3 ``` Replace `1.2.3` with a version that has undergone security review. 2. Prefer declaring the package in a committed project manifest and lockfile. Install dependencies using a frozen-lockfile mode so unexpected dependency graph changes cause failure rather than silent updates. 3. Verify package provenance, publisher identity, registry source, release signatures, and integrity metadata before execution. Configure the package manager to use only an approved registry. 4. Require explicit user approval before the first dependency download or execution. The prompt should identify the exact package version, registry, and commands that will run. 5. Execute the detector in a restricted environment with: - Access limited to the intended project directory. - No unnecessary credentials or secrets in environment variables. - Network access disabled after verified installation when feasible. - Read-only source access during scan-only operations. - Write access granted only when the user has selected a fix workflow. 6. Review the selected package version and its transitive dependencies, including installation hooks and executable entry points. Record the reviewed artifact digest. 7. Update all command references consistently, including `SKILL.md:15-17`, `references/workflows.md:7`, and `references/workflows.md:136`, so no documented path falls back to unpinned execution.