T08 · Insecure Dependencies
- Location
workflows/ralph.md:50- Finding
Automatic Installation of Untrusted Dependencies
- Content
View full analysis
Vulnerability Details
File Location:
workflows/ralph.md, lines 50–54
Vulnerability Type: Supply-chain compromise through automatic dependency installation
Risk Level: MediumVulnerable Code Snippet:
markdown ## 自动修复策略 1. 编译错误 → 自动修复语法 2. 测试失败 → 分析原因并修复 3. 依赖缺失 → 自动安装 4. 逻辑错误 → 重新分析并修复The relevant instruction at line 53 translates to: “Missing dependency → install automatically.”
Technical Analysis
The persistent execution workflow directs the Agent to install dependencies automatically when it determines that a dependency is missing. It does not require:
- Explicit user approval before installation
- Validation against a reviewed dependency manifest
- Use of an existing lockfile
- Exact version pinning
- Package-name verification
- Registry or source allowlisting
- Package integrity or signature verification
- Disabling package-manager lifecycle scripts
An attacker-controlled repository could contain a crafted import, dependency declaration, build error, or test failure that names a malicious or typo-squatted package. When the workflow attempts to repair the reported missing dependency, it may install the attacker-controlled package.
Many package managers execute installation hooks with the permissions of the invoking process. Therefore, package installation can become a code-execution path even if the installed dependency is never imported by the application.
Attack Path
- An attacker prepares a repository containing a reference to a nonexistent, typo-squatted, dependency-confusion, or otherwise attacker-controlled package.
- The user asks the Agent to process the repository through the
$ralphpersistent completion workflow. - A build, test, or static-analysis step reports the package as missing.
- The Agent follows
workflows/ralph.md:53and installs the dependency without obtaining explicit approval or validating its provenance. - The package manager retrieves the attacker-controlled package.
- A malici ...[truncated 928 chars]
- Remediation
View remediation
Remediation Suggestions
Replace automatic dependency installation with a controlled approval and verification process:
- Require explicit user confirmation before running any package-manager installation command.
- Display the exact package name, version, registry, resolved URL, and proposed command before approval.
- Only install dependencies declared in a reviewed project manifest.
- Require and enforce a committed lockfile with integrity metadata.
- Pin dependencies to exact reviewed versions rather than ranges or latest releases.
- Restrict package resolution to approved registries and reject unexpected Git, URL, local-path, or alternate-registry sources.
- Detect package-name similarity, dependency-confusion conditions, and unexpected namespace changes.
- Verify package integrity, signatures, or provenance attestations where the ecosystem supports them.
- Disable lifecycle scripts during initial installation where practical, then review any required scripts before allowing execution.
- Run package installation in a restricted sandbox with minimal filesystem access, no unnecessary credentials, and limited network access.
- Change the workflow instruction to state that missing dependencies must be reported to the user rather than installed automatically.
A safer replacement for line 53 would be:
markdown 3. Missing dependency → identify the exact package and version, verify it against the reviewed manifest and lockfile, and request explicit user approval before installation