About security-review-process
security-review-process is a coding skill for auditing security risks and verifying mitigations during code changes. It covers input handling, injection risks, secrets and logs, and dependency vulnerabilities.
Key features
- 01Audit and allowlist untrusted inputs
- 02Check SQL and shell injection risks
- 03Keep secrets out of code and logs
- 04Scan dependencies with bundle-audit
- 05Present findings and verify mitigations
Use cases
- 01Review API or webhook input handling
- 02Check database and command execution paths
- 03Inspect logging and configuration for secret leaks
- 04Assess dependency vulnerabilities before finalizing changes
Install
Copy the command and run it in a terminal.
$
npx skills add https:/ / github.com/ igmarin/ ruby-core-skills --skill security-review-processAfter installing, type/security-review-processin Claude Code to confirm it loaded.
Details
From the project READMESecurity Review Process
Apply the execution contract before this procedure.
Security Gates & Quick Reference
| Area | Gate |
|---|---|
| Input Validation | Untrusted payloads must pass an allowlist filter before processing |
| Secrets | NO secrets may be committed or logged |
| Injections | Direct SQL interpolation (#{id}) is FORBIDDEN |
| Dependencies | Run bundle-audit before finalizing changes |
Process Steps
Step 1: Input Validation Audit
- Identify all entry points (controllers, API endpoints, webhooks, console runners).
- Verify every parameter is explicitly allowlisted and type-coerced if necessary.
- Ensure instruction-like keys (e.g.
prompt,instructions) in JSON payloads are discarded or neutralized.
Step 2: Injections Check
- Audit all database interactions:
- Verify no raw SQL strings are built via string interpolation (
#{}). - Confirm the database client's query parameterization features are used.
- Verify no raw SQL strings are built via string interpolation (
- Audit file and command executions:
- Avoid dynamic shell commands via backticks,
system(), orexec(). If necessary, pass arguments as separate array items.
- Avoid dynamic shell commands via backticks,
Step 3: Secrets and Logs Check
- Read configuration from environment variables (
ENV['SECRET']) or secure config vaults — never raw literals. - Verify sensitive data (passwords, tokens, personal identifiers) is filtered/redacted from log output.
Step 4: Dependency and CVE Checks
- Scan project dependencies:
bundle exec bundle-audit check --update - If a vulnerability is reported, plan a safe version upgrade.
Checkpoint Pattern
Align with the user:
- Security Vulnerability Assessment: Present concerns categorized by threat vector (e.g. SQL injection, secrets leak).
- Mitigation Verification: Once fixes are made, demonstrate how the parameterized query or filter blocks the exploit vector.
Code Defenses Examples
1. Preventing SQL Injection
Vulnerable:
db.execute("SELECT * FROM users WHERE name = '#{params[:name]}'")
Secure:
db.execute("SELECT * FROM users WHERE name = ?", params[:name])
2. Preventing Shell Injection
Vulnerable:
system("rm -rf #{params[:path]}")
Secure:
system("rm", "-rf", params[:path])
Integration
| Context | Next Skill |
|---|---|
| Standard code reviews | review-process |
| General TDD loops | tdd-process |
Comments
Markdown supported