T08 · Insecure Dependencies
Warning
- Location
- SKILL.md:171
- Finding
- Unpinned Third-Party SDK Installation Creates a Supply-Chain Risk## Vulnerability Details **File Location**: `SKILL.md:171-181` **Vulnerability Type**: Unpinned third-party dependencies **Risk Level**: Medium ### Vulnerable Code ```bash ohpm install @zztsdk/zztcore ohpm install @zztsdk/moblink ``` The workflow subsequently validates that dependencies were added using unconstrained placeholder versions: ```json5 "dependencies": { "@zztsdk/zztcore": "^x.x.x", "@zztsdk/moblink": "^x.x.x" } ``` ### Technical Analysis The integration workflow installs the current registry versions of `@zztsdk/zztcore` and `@zztsdk/moblink` without requiring an exact, previously reviewed version. It also does not require checksum validation, package provenance verification, lockfile review, or inspection of package lifecycle scripts. As a result, the effective code installed by the Skill can change after the Skill itself has been audited. Even when a legitimate package is currently safe, a compromised publisher account, registry compromise, or malicious future release could introduce hostile build-time or runtime behavior. Caret version ranges can also allow later compatible releases to be selected during subsequent installations, causing non-reproducible builds and bypassing the security assumptions of the original review. ### Attack Path 1. An attacker compromises the publisher account, package registry, or SDK release process. 2. The attacker publishes a malicious version under one of the expected package names. 3. A user invokes the Skill and approves dependency installation. 4. The Agent executes the unpinned `ohpm install` commands. 5. The malicious package is added to the HarmonyOS project. 6. Package-controlled code may execute during installation or build, or become part of the resulting application. 7. The payload operates with the privileges available to the developer's build process or, at runtime, with the permissions granted to the application. ### Impact Assessmen ...[truncated 561 chars]
- Remediation
- ## Remediation Suggestions - Require exact, reviewed package versions rather than installing the current release. - Avoid permissive caret ranges for security-sensitive SDK dependencies. - Commit and verify the ohpm lockfile to make installations reproducible. - Review package provenance, publisher identity, release signatures, and package lifecycle scripts before installation. - Record approved package versions and checksums in the Skill documentation. - Require explicit user approval before changing an already approved dependency version. - Run dependency installation and builds in a restricted environment without unnecessary credentials or filesystem access. - Incorporate dependency vulnerability and integrity scanning into CI.
