mcpField
E
elixir-security-review

elixir-security-review

github.com/existential-birdsSecurity85104 installsUpdated 11w ago
Repository

About elixir-security-review

A security-review skill for Elixir code, organized around critical, major, and configuration checks. It emphasizes context-sensitive findings and requires source locations and verification before reporting issues.

Key features

  1. 01Code injection and unsafe term checks
  2. 02Atom exhaustion checks
  3. 03Secret and configuration checks
  4. 04ETS and process data checks
  5. 05Context-sensitive review gates

Use cases

  1. 01Reviewing Elixir changes before merge
  2. 02Checking external input handling
  3. 03Auditing secrets and runtime configuration
  4. 04Verifying findings against source context

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/existential-birds/beagle --skill elixir-security-review

After installing, type/elixir-security-reviewin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

references/
atom-exhaustion.md
code-injection.md
process-exposure.md

Details

From the project README

Elixir Security Review

Quick Reference

Issue TypeReference
Code.eval_string, binary_to_termreferences/code-injection.md
String.to_atom dangersreferences/atom-exhaustion.md
Config, environment variablesreferences/secrets.md
ETS visibility, process dictionaryreferences/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

IssueFlag ONLY IF
String.to_atomInput comes from external source (user, API, file)
binary_to_termData comes from untrusted source
ETS :publicContains 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 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; use it as the full pre-report checklist and issue-type verification (it extends beyond this skill’s summary).

Comments

Markdown supported