T08 · Insecure Dependencies
- Location
SKILL.md:34- Finding
Unpinned Third-Party Dependency with Unspecified Provenance
- Content
View full analysis
com.zt zt-digital-common-i18n-starter ``` ### Technical Analysis The documented Maven dependency does not specify a version, trusted repository, checksum, or signature-verification procedure. Its resolved version consequently depends on dependency-management and repository settings inherited from the consuming project or build environment. This prevents the skill instructions from ensuring that consumers retrieve the intended, audited artifact. If dependency management or repository resolution is misconfigured or compromised, Maven could retrieve an unintended or malicious version containing executable code. Java dependency code can execute during application initialization and runtime with the privileges of the consuming Spring Boot process. No malicious dependency implementation is included in the audited project, and the audit did not establish that the named artifact is itself malicious. The risk arises from unsafe and externally mutable dependency resolution. ### Attack Path 1. A developer follows the instructions in `SKILL.md` and adds the versionless dependency to a Spring Boot project. 2. Maven obtains the version and repository from inherited dependency management, corporate mirrors, user settings, or other external build configuration. 3. An attacker compromises or influences one of those resolution sources, or a configuration error selects an unintended artifact version. 4. Maven downloads and packages the attacker-controlled or vulnerable dependency. 5. The dependency executes in the application through class loading, Spring auto-configuration, component initialization, or normal library invocation. 6. The payload operates with the permissions and data access availa ...[truncated 494 chars]- Remediation
View remediation
com.zt zt-digital-common-i18n-starter APPROVED_VERSION ``` 2. Document the authoritative repository and require HTTPS with valid certificate verification. 3. Configure Maven to reject unexpected repositories and route dependency resolution through a controlled, authenticated artifact mirror. 4. Verify artifact provenance using repository signatures, published checksums, or an organizational software-composition-analysis policy. 5. Generate and retain a software bill of materials and lock resolved transitive dependency versions in dependency management. 6. Enable automated vulnerability and integrity scanning for the direct dependency and its transitive dependency graph. 7. Review upgrades explicitly rather than allowing external dependency-management changes to silently alter the resolved version. ]]>
