T08 · Insecure Dependencies
- Location
SKILL.md:123- Finding
Unverified Security-Sensitive CLI Dependency
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, line 123; dependency and credential-handling documentation at lines 283–290
Vulnerability Type: Unverified third-party executable with access to OAuth credentials and Google Workspace services
Risk Level: HighVulnerable command at line 123:
bash gog auth credentials /path/to/client_secret.jsonTechnical Analysis
The Skill requires the external
gogexecutable but does not identify an official repository, verified publisher, exact package identifier, pinned version, checksum, or digital-signature verification procedure. Lines 283–290 only direct users to obtain the CLI through an unspecified package manager and then use it to import a Google OAuth client-secret file.This creates a supply-chain trust gap. Multiple unrelated or malicious packages can use the same executable or package name, and an attacker-controlled executable earlier in the system
PATHcould also impersonate the expected tool. Because the CLI participates in OAuth authorization and requests Gmail, Calendar, and Drive access, substituting the executable could expose credentials and authorized Workspace data.The documentation states that credentials are stored locally in encrypted form, but it does not identify the storage implementation, encryption mechanism, key management, file permissions, or token revocation procedure. Therefore, this assertion cannot compensate for the missing dependency provenance and verification controls.
Attack Path
- An attacker publishes a malicious or typo-squatted package that installs an executable named
gog, or places a spoofedgogexecutable earlier in the victim'sPATH. - The user or Agent follows the Skill's unspecified package-manager installation guidance without verifying the package publisher, source, version, signature, or checksum.
- The user executes:
bash gog auth credentials /path/to/client_secret.json
...[truncated 1632 chars]
- An attacker publishes a malicious or typo-squatted package that installs an executable named
- Remediation
View remediation
Remediation Suggestions
-
Identify the dependency unambiguously:
- Provide the official project name, repository URL, publisher, and package-registry namespace.
- Document the exact package identifier separately for every supported package manager.
- Avoid relying only on a short executable name such as
gog.
-
Pin and verify the dependency:
- Pin an audited version rather than installing the latest mutable release.
- Publish expected cryptographic checksums for downloadable artifacts.
- Require package or artifact signature verification when supported.
- Document how users can verify the publisher and release provenance.
-
Defend against executable spoofing:
- Resolve the executable path before the first credential operation.
- Verify that the resolved path belongs to the expected installed package.
- Reject execution from untrusted or user-writable directories.
- Where practical, invoke a verified absolute executable path rather than relying on
PATH.
-
Minimize OAuth exposure:
- Request only the scopes required for the specific operation.
- Separate read-only authorization from email-send authorization.
- Display the requested scopes and require explicit user approval before authorization.
- Document how users can inspect and revoke granted access.
-
Harden credential storage:
- Specify the token-storage location, encryption implementation, key-management mechanism, and required file permissions.
- Prefer an operating-system credential vault or keychain over application-managed plaintext files.
- Never print client secrets, access tokens, or refresh tokens in command output or Agent logs.
- Provide a secure credential-removal and token-revocation command.
-
Add a preflight verification step before
gog auth credentialsthat confirms the executable version, publisher, installation source, resolved path, and artifact integrity. Abort credenti ...[truncated 38 chars]
-