T08 · Insecure Dependencies
Error
- Location
- SKILL.md:190
- Finding
- Unpinned MobSDK Gradle Plugin Allows Unreviewed Supply-Chain Updates<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:190-198` **Additional Locations**: `SKILL.md:55`, `assets/generate_excel_template.py:97`, `templates/MOBLINK_README.md:8` **Vulnerability Type**: Dynamic, unpinned third-party build dependency **Risk Level**: High ### Vulnerable Code ```groovy buildscript { dependencies { classpath "com.mob.sdk:MobSDK2:+" } } ``` The same dynamic dependency is also prescribed elsewhere: ```text com.mob.sdk:MobSDK2:+ ``` ### Technical Analysis The `+` version selector instructs Gradle to resolve the latest available `MobSDK2` release from the configured external MobTech Maven repository. Consequently, the dependency used by a build can change without any modification to the audited project. A Gradle plugin is executable build logic rather than a passive library. Once resolved, plugin code runs inside the Gradle process with the permissions of the developer or CI account performing the build. The workflow does not require dependency locking, checksum verification, repository content filtering, or review of newly resolved versions. This does not demonstrate that the current MobSDK package is malicious. The vulnerability is that the Skill automatically introduces future, unreviewed code into a privileged build environment. ### Attack Path 1. A user follows the Skill and adds `https://mvn.mob.com/android` as a Maven repository. 2. The user adds the dynamic dependency `com.mob.sdk:MobSDK2:+`. 3. An attacker compromises the upstream publishing account, repository, distribution infrastructure, or a future package release. 4. The attacker publishes a version newer than the previously reviewed release. 5. A subsequent local or CI build resolves the new version automatically. 6. Gradle loads and executes the plugin code with the build account's privileges. 7. Malicious plugin code could access source code, environment variables, signing material, build credentials, and writable files available to t ...[truncated 569 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Replace the dynamic selector with a specific, reviewed version: ```groovy buildscript { dependencies { classpath "com.mob.sdk:MobSDK2:REVIEWED_VERSION" } } ``` 2. Record the approved version centrally and require a security review before upgrading it. 3. Enable Gradle dependency locking so dependency resolution cannot change unexpectedly. 4. Enable Gradle dependency verification and commit trusted checksums or signatures. 5. Restrict the MobTech Maven repository with Gradle content filters so it can only provide expected MobTech groups. 6. Prevent CI builds from silently refreshing dependencies and fail builds when verification metadata does not match. 7. Run Android builds under a least-privileged account without unnecessary access to unrelated credentials or files. 8. Update all documentation and templates that currently recommend `MobSDK2:+` so users do not reintroduce the dynamic version. ]]>