T08 · Insecure Dependencies
- Location
SKILL.md:8- Finding
Unpinned External Executable Dependencies
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 8–15
Vulnerability Type: Unpinned third-party executable dependencies
Risk Level: MediumVulnerable Code
yaml install: - kind: npm package: seaportal bins: [seaportal] - kind: go package: github.com/pinchtab/seaportal/cmd/seaportal@latest bins: [seaportal]Technical Analysis
Both supported installation methods retrieve executable third-party code without selecting an immutable, previously reviewed version. The npm package declaration has no version constraint, while the Go installation path explicitly uses the mutable
@latestversion.This creates a supply-chain risk because the code installed in the future may differ from the code intended or reviewed when the Skill was published. If the upstream package, maintainer account, release process, or package registry is compromised, a malicious release could be installed without requiring any modification to this Skill.
The package and repository names are consistent with the declared project homepage. No evidence of dependency confusion, typosquatting, or an actively malicious upstream package was identified in the audited artifact. The vulnerability is therefore the unsafe use of mutable executable dependencies rather than confirmed malicious dependency content.
Attack Path
- An attacker compromises the upstream npm package, Go repository, maintainer credentials, or release pipeline.
- The attacker publishes a malicious version as the current release.
- An Agent installs the dependency using the unversioned npm declaration or the Go
@latestreference. - The package installation process or subsequently invoked
seaportalexecutable runs attacker-controlled code. - The malicious code operates with the permissions and accessible resources of the Agent or user that performed the installation.
Impact Assessment
Successful exploitation coul ...[truncated 611 chars]
- Remediation
View remediation
Remediation Suggestions
- Pin the npm dependency to a specific reviewed version rather than resolving the registry's current release.
- Replace the Go
@latestreference with an explicit semantic version, such as@vX.Y.Z, after reviewing that release. - Where supported, verify package integrity using lockfiles, cryptographic hashes, signed releases, provenance attestations, or trusted checksums.
- Execute installation and the resulting CLI under a non-privileged account with access limited to the files and network destinations required for website retrieval.
- Adopt a controlled dependency-update process in which new versions are scanned, reviewed, tested, and explicitly approved before updating the pinned version.
- Document the expected publisher, repository, package identity, and verified release digest so substitutions can be detected.
