feat: onboarding setup-ruby action

[Raj-StepSecurity]

No description provided.

[github-actions]

PR Review

Action Type

Node-based — uses node24 runtime as declared in action.yml, with dist/index.js as the bundled entry point.

---

Passed Checks

• License: LICENSE file present with dual copyright — original author Benoit Daloze (2019) and StepSecurity (2026).
• action.yml: Present with author: 'step-security'.
• SECURITY.md: Present at repo root.
• No FUNDING.yml: Absent as required.
• Workflow files: Both .github/workflows/auto_cherry_pick.yml and .github/workflows/actions_release.yml are present.
• No renovate.json: Absent as required.
• No PULL_REQUEST.md: Absent as required.
• No ISSUE_TEMPLATE folder: Absent as required.
• No CHANGELOG.md: Absent as required.
• No .vscode folder: Not tracked in the repository (correctly listed in .gitignore).
• dist folder: dist/index.js is present and committed.
• README banner: StepSecurity maintained action banner is present on line 1 of README.md.
• README versioning: All usage examples reference step-security/setup-ruby@v1 (major version only, no full semver tags).
• Subscription check: index.js calls https://agent.api.stepsecurity.io/v1/github/${process.env.GITHUB_REPOSITORY}/actions/maintained-actions-subscription.
• Upstream variable: upstream = 'ruby/setup-ruby' correctly matches original-owner: "ruby" and repo-name: "setup-ruby" from auto_cherry_pick.yml.
• package.json author: "author": "step-security".
• package.json repository: URL contains step-security.
• No unused dependencies: All declared dependencies are actively used across the codebase.
• Build script input: Both actions_release.yml and audit_package.yml expose script as a workflow input (required since the package manager is yarn, not npm).

---

Failed Checks

• Workflow file naming: The requirement specifies a file named .github/workflows/audit_fix.yml, but the file in this repo is named audit_package.yml. It calls the reusable audit_fix.yml workflow and meets the functional requirement (script input is present), but the filename does not match the expected convention.

---

Warnings

• exportCommandEnv in windows.js (line 220): The function builds a cmd.exe /s /c string by embedding the command argument directly via template literal. Callers pass paths derived from tool-cache or vswhere output (not direct user input), but if any embedded path contains characters like ", &, |, or > the shell command could misbehave. This is a pre-existing upstream pattern; consider sanitizing path characters before embedding.
• process.chdir on user input (index.js:88): The working-directory input is passed directly to process.chdir() without sanitization, allowing path traversal (e.g., ../../). This is by-design for the action's functionality but is worth acknowledging.

---

Security Findings

Shell command injection risk — windows.js:220: exportCommandEnv constructs a raw cmd.exe command string by embedding the command parameter without escaping special characters. If the rubyPrefix or vcVars path (sourced from vswhere) contains shell meta-characters, the injected string could alter execution flow. Consider sanitizing or validating path characters before embedding in the shell string.

All other code paths examined show no significant security vulnerabilities.

---

Summary

The onboarding PR is well-structured and passes nearly all required checks. The only failing check is the naming of the audit workflow file (audit_package.yml vs. the expected audit_fix.yml). The shell command construction in windows.js:220 is a low-severity pre-existing upstream pattern that should be reviewed for hardening.

[github-actions]

Security: Shell command injection risk

The command parameter is embedded directly into a cmd.exe /s /c "..." string via template literal without any escaping. If either caller's argument (ridk path or vcVars path) contains shell meta-characters such as ", &, |, or >, the constructed command could execute unintended code.

While the callers currently source these paths from tool-cache paths or vswhere output (not direct user input), a path with embedded special characters — e.g., a tool cache under a directory named with & or " — could break out of the intended string boundary.

Recommendation: Validate that embedded paths contain only expected characters (alphanumeric, \, :, ., space), or use child_process.execFileSync with separate argument arrays instead of a single interpolated string.

// Safer pattern: avoid embedding paths in a raw shell string
// If cmd.exe composition is required, validate that the path matches a safe pattern:
if (!/^[a-zA-Z0-9 :\\._-]+$/.test(ridk)) {
  throw new Error(`Unexpected characters in ridk path: ${ridk}`)
}

[github-actions]

Note: Unsanitized path used in process.chdir()

The working-directory input is passed directly without validation. A value like ../../sensitive-dir would cause the process to change to a directory outside the workspace. This is expected behavior for the action but can be surprising; consider documenting that path traversal is the caller's responsibility.