Skills elixir-security-review
Reviews Elixir code for security vulnerabilities including code injection, atom exhaustion, and secret handling. Use when reviewing code handling user input, external data, or sensitive configuration.
install
source · Clone the upstream repo
git clone https://github.com/openclaw/skills
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/openclaw/skills "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/anderskev/elixir-security-review" ~/.claude/skills/clawdbot-skills-elixir-security-review && rm -rf "$T"
manifest:
skills/anderskev/elixir-security-review/SKILL.mdsource content
Elixir Security Review
Quick Reference
| Issue Type | Reference |
|---|---|
| Code.eval_string, binary_to_term | references/code-injection.md |
| String.to_atom dangers | references/atom-exhaustion.md |
| Config, environment variables | references/secrets.md |
| ETS visibility, process dictionary | references/process-exposure.md |
Review Checklist
Critical (Block Merge)
- No
on user inputCode.eval_string/1 - No
without:erlang.binary_to_term/1
on untrusted data:safe - No
on external inputString.to_atom/1 - No hardcoded secrets in source code
Major
- ETS tables use appropriate access controls
- No sensitive data in process dictionary
- No dynamic module creation from user input
- Path traversal prevented in file operations
Configuration
- Secrets loaded from environment
- No secrets in config/*.exs committed to git
- Runtime config used for deployment secrets
Valid Patterns (Do NOT Flag)
- String.to_atom on compile-time constants - Atoms created at compile time are safe
- Code.eval_string in dev/test - May be needed for tooling
- ETS :public tables - Valid when intentionally shared
- binary_to_term with :safe - Explicitly safe option used
Context-Sensitive Rules
| Issue | Flag ONLY IF |
|---|---|
| String.to_atom | Input comes from external source (user, API, file) |
| binary_to_term | Data comes from untrusted source |
| ETS :public | Contains sensitive data |
Before Submitting Findings
Use the issue format:
[FILE:LINE] ISSUE_TITLE for each finding.
Load and follow review-verification-protocol before reporting any issue.