T08 · Insecure Dependencies
- Location
SKILL.md:15- Finding
Unpinned EAS CLI Execution Through npx
- Content
View full analysis
npx eas-cli submit --platform android --id # Build + submit in one step npx eas-cli build --platform ios --profile production --auto-submit ``` ### Technical Analysis The documented commands invoke `eas-cli` through `npx` without specifying a reviewed, immutable package version. When the package is unavailable locally, `npx` can resolve and download it from the configured npm registry before executing it. Consequently, the code executed by these instructions may change after the Skill has been reviewed. This is an insecure dependency practice because the deployment workflow does not provide an exact version, committed lockfile, package-integrity verification, or trusted installation procedure. A compromised upstream release, registry account, registry configuration, or dependency in the resolved package graph could cause arbitrary package or CLI code to run with the invoking user's privileges. ### Attack Path 1. An attacker compromises a version of `eas-cli`, one of its transitive dependencies, or the package distribution channel. 2. A user or agent follows `SKILL.md` and invokes an unversioned `npx eas-cli` command. 3. If no suitable local package is installed, `npx` resolves and downloads the package version available through the configured registry. 4. The downloaded package and its dependency code execute with the permissions of the invoking user. 5. Malicious code can inspect accessible application sour ...[truncated 983 chars]- Remediation
View remediation
``` 2. Commit the generated lockfile and install dependencies in automation with a lockfile-enforcing command: ```bash npm ci ``` 3. Invoke the lockfile-controlled local package and prevent `npx` from downloading missing packages: ```bash npx --no-install eas-cli build --platform ios --profile production ``` 4. Where package-manager support permits, prefer a command that explicitly refuses remote package acquisition if the local dependency is absent. 5. Review version upgrades through a controlled change process, including dependency-diff inspection, provenance checks, vulnerability scanning, and verification of package integrity. 6. Run deployment tooling under a least-privileged account and expose only the credentials required for the selected platform and operation. Keep unrelated secrets out of the process environment. ]]>
