Security of the BEAM
summary
BEAM systems lack safe defaults for TLS and crypto and expose high‑risk operations like os:cmd and runtime eval plus limits that enable DoS via atoms and ETS table exhaustion. The concrete method is threat modelling with trust zones and entry points (exported functions and receive clauses), treat incoming values as tainted, validate or sanitize before reaching risky APIs, prefer safe replacements (file:make_dir over os:cmd), run refactor‑based static analysis in CI to find flows where tainted data reaches listed vulnerabilities.
AI-written summary · about
chapters (14)
- 0:00Intro
- 1:51High risk vulnerabilities
- 4:56Do we need to avoid functions
- 5:22What use cases are risky
- 8:10Planning phase
- 11:32Units
- 14:16Entry Points
- 16:28What to Avoid
- 17:09Example
- 21:20Development
- 23:10Validation
- 27:18Other tools
- 30:33Summary
- 31:00Questions
related talks
41mFireside chat on security for practitioners & academics
43mKeynote: Security Under the BEAM
43mSecuring Elixir Applications
32mDon’t let it crash: How we applied our security checks on Elixir code
25mFIPS 140-2 in BEAM Apps
48mGetting to Know the Erlang Virtual Machine, the BEAM
26mBeyond the Basics: Securing JS Applications
26mseL4 and BEAM: A match made in Erlang