Zero Trust in Elixir: The SEAL Doctrine

Security as a Compile-Time Guarantee

Most security tools operate at runtime: WAFs inspect HTTP requests, SAST

scanners run in CI pipelines, and penetration testers find vulnerabilities

in deployed applications. The SEAL (Security Enforcement Absolute Lock)

doctrine shifts security enforcement to the earliest possible point:

before code enters the repository.

SEAL operates on a simple principle. If a dangerous pattern can be detected

statically, it should be blocked at commit time. No exceptions, no bypass

flags, no "we will fix it later" escape hatches.

The Four SEAL Prohibitions

SEAL enforces four absolute prohibitions across the entire codebase:

1. SQL Injection Prevention

String interpolation inside Ecto fragment calls is the most common SQL

injection vector in Elixir applications. SEAL detects this pattern

through grep scanning of staged files:

# BLOCKED by SEAL
# Bad: SQL string interpolation
# fragment("column = '...'")


# Good: parameterized query
# fragment("column = ?", ^value)

The grep pattern matches any fragment( call containing #{ interpolation.

This catches both direct interpolation and variable-based construction of

SQL strings.

2. Hardcoded Secret Detection

SEAL scans for patterns that indicate hardcoded credentials: strings

matching API key formats (sk-, pk-, key-, bearer), database connection

strings with embedded passwords, and common secret variable names

assigned string literals.

# BLOCKED by SEAL
key = "sk-..."


# APPROVED alternative
key = System.get_env("API_KEY")

The detection uses a curated set of regex patterns that balance precision

against false positives. Test fixtures and documentation examples are

excluded from scanning through path-based filtering.

3. Code.eval Blocking

Code.eval_string/1 and Code.eval_quoted/1 enable arbitrary code

execution. In almost every case, their use indicates a design flaw

that should be solved with pattern matching, behaviours, or controlled

dispatch tables instead.

# BLOCKED by SEAL
# Bad: arbitrary code execution
# Code.eval_stri​ng(user_code)


# Good: controlled dispatch
case action do
:transform -> Transformer.run(data)
:validate -> Validator.run(data)
end

The SEADF (Self-Evolving Autonomous Development Framework) and MENDEL

genetic algorithm systems hold formal exemptions for Code.eval usage,

documented in the code generation governance policy.

4. Command Injection Prevention

System.cmd and :os.cmd calls with interpolated arguments are blocked.

Arguments must be passed as list elements to prevent shell injection:

# BLOCKED by SEAL
# Bad: interpolated shell argument
# System.cmd("grep", ["-r", interpolated, "/data"])


# Good: explicit argument list
# System.cmd("grep", ["-r", sanitized_input, "/data"])

Pre-Commit Enforcement

SEAL enforcement runs as part of the pre-commit hook pipeline. The hook

extracts staged files using git diff --cached --name-only, filters for

Elixir source files, and runs grep-based pattern detection against each

file's staged content.

The grep-based approach was chosen over AST parsing for speed. Pre-commit

hooks must complete in under 5 seconds to avoid disrupting developer flow.

Grep scanning of staged content achieves this even on large changesets,

while full AST parsing would require compilation.

AST-Based Deep Scanning

For CI pipelines where execution time is less critical, SEAL also provides

AST-based analysis through the mix check.doctrines task. This analysis

parses Elixir source files into their AST representation and walks the

tree looking for dangerous function calls, regardless of how they are

formatted or aliased.

AST scanning catches patterns that grep misses, such as aliased module

calls (alias Code, as: C; C.eval_string(input)) and dynamically

constructed function calls. The combination of fast grep pre-commit

scanning and thorough AST CI scanning provides defense in depth.

Results in Practice

Since enabling SEAL enforcement, zero security-related patterns have

entered the codebase through normal development workflow. The initial

deployment required fixing 3 critical vulnerabilities (unsafe

binary_to_term calls processing user input) and 6 moderate issues

(Code.eval usage in evolution systems that received formal exemptions).