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.
git clone --depth 1 https://github.com/existential-birds/beagle /tmp/elixir-security-review && cp -r /tmp/elixir-security-review/plugins/beagle-elixir/skills/elixir-security-review ~/.claude/skills/elixir-security-reviewSKILL.md
# Elixir Security Review ## Quick Reference | Issue Type | Reference | |------------|-----------| | Code.eval_string, binary_to_term | [references/code-injection.md](references/code-injection.md) | | String.to_atom dangers | [references/atom-exhaustion.md](references/atom-exhaustion.md) | | Config, environment variables | [references/secrets.md](references/secrets.md) | | ETS visibility, process dictionary | [references/process-exposure.md](references/process-exposure.md) | ## Review Checklist ### Critical (Block Merge) - [ ] No `Code.eval_string/1` on user input - [ ] No `:erlang.binary_to_term/1` without `:safe` on untrusted data - [ ] No `String.to_atom/1` on external input - [ ] 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 | ## Hard gates (before reporting) Complete **in order** for each finding you intend to report. Do not advance until the pass condition is satisfied. 1. **Location artifact** — The finding includes `[FILE:LINE]` (or a line range) that you copied from the current file contents; the path resolves in this repo. 2. **Scope read** — You read the full surrounding function or module section that contains the flagged code, not only a diff hunk or summary. 3. **External-data claim** (only if the finding depends on “user/untrusted input”) — You can name one concrete ingress (for example `conn.params`, `Jason.decode!/1` result, uploaded file path, message from another node) **or** you drop the finding because the value is compile-time, test-only, or internal per Context-Sensitive Rules. 4. **Protocol** — Pre-report steps in [review-verification-protocol](../review-verification-protocol/SKILL.md) are satisfied for this item (no finding if they are not). ## Before Submitting Findings Use the issue format: `[FILE:LINE] ISSUE_TITLE` for each finding. Hard gate 4 requires [review-verification-protocol](../review-verification-protocol/SKILL.md); use it as the full pre-report checklist and issue-type verification (it extends beyond this skill’s summary).
tag and push a release after the release PR is merged
create a release PR (auto-detects previous tag)
Guides architectural decisions for Deep Agents applications. Use when deciding between Deep Agents vs alternatives, choosing backend strategies, designing subagent systems, or selecting middleware approaches.
Reviews Deep Agents code for bugs, anti-patterns, and improvements. Use when reviewing code that uses create_deep_agent, backends, subagents, middleware, or human-in-the-loop patterns. Catches common configuration and usage mistakes.
Implements agents using Deep Agents. Use when building agents with create_deep_agent, configuring backends, defining subagents, adding middleware, or setting up human-in-the-loop workflows.
Guides architectural decisions for LangGraph applications. Use when deciding between LangGraph vs alternatives, choosing state management strategies, designing multi-agent systems, or selecting persistence and streaming approaches.
Reviews LangGraph code for bugs, anti-patterns, and improvements. Use when reviewing code that uses StateGraph, nodes, edges, checkpointing, or other LangGraph features. Catches common mistakes in state management, graph structure, and async patterns.
Implements stateful agent graphs using LangGraph. Use when building graphs, adding nodes/edges, defining state schemas, implementing checkpointing, handling interrupts, or creating multi-agent systems with LangGraph.