1 of 37

Navigating a Security Disaster

From Freakout to Fix

Ægis Initiative

2 of 37

Meet tabulex

A Phoenix table component driven entirely by URL parameters

Completely fictional, any similarities to existing libraries are incidental!

Ægis Initiative

3 of 37

You built something wonderful.

😍

⭐

Ægis Initiative

4 of 37

OOPS

Timing: 02:55–04:20

“This is what the worst case looks like. Big coverage, systems everywhere feeling it, people waking up in the middle of the night.

Imagine waking up to headlines like this—users panicking, customers calling, Slack and email blowing up. Suddenly, your wonderful growth story has turned into a firestorm. This is the moment every maintainer dreads.

[PAUSE]

You’ll probably never have something this massive. That’s the comforting part. But even a small issue—something that affects just a handful of deployments—can be critical to the people depending on you.

And here’s the truth: even if it’s small in scope, to you it will feel huge. It will feel like everything is on fire, because in that moment your users are facing real consequences and they’re looking at you. That’s why how you respond matters.”

5 of 37

What now?

Ægis Initiative

Timing: 04:20–05:20

“And then this is what it feels like. Everything you built is under a microscope—alerts, messages, issue pings, users asking if you’ve seen it. Your brain is trying to split attention across twenty things at once.

What now?

Congratulations—you’re officially the maintainer of a zero-day. That’s not a title you applied for, but here we are. And in that moment, it can feel crushing: your heart rate spikes, every GitHub star suddenly feels like a liability, and you start thinking, ‘Did I miss something obvious? Is everyone going to think I’m incompetent?’

That reaction is normal. Every maintainer who’s been here has felt that same stomach-drop moment. The question isn’t whether you panic—it’s whether you freeze, hide the fix, or start moving with clarity.”

6 of 37

Jonatan Männchen�CISO @ Erlang Ecosystem Foundation

Assess
Shed Shame
Coordinate Disclosure
Patch & Release
Communicate
Prepare for the next Time

Ægis Initiative

7 of 37

Assess

What is going on? How bad is it? Who knows?

Ægis Initiative

8 of 37

Is it a vulnerability?

What’s the behavior? Unexpected / unsafe?
Can it be abused? Who’s the attacker and what’s the impact? (Confidentiality / Integrity / Availability)
Scope: single user vs. all deployments.
Not sure? The EEF CNA can help you triage.

Ægis Initiative

Timing: 06:50–08:50

“First: is this even a vulnerability? That’s the foundation. Start by looking at what’s actually happening—what’s the behavior? Is it unexpected or unsafe?

Then ask: can someone abuse it? Who would the attacker be, and what would they gain? A useful way to think about that is through the CIA triad—does this affect confidentiality, integrity, or availability? That gives you language to describe impact instead of hand-waving.

For example: confidentiality might mean a Phoenix app that accidentally leaks secrets through an API. Or even something more subtle, like debug logs printing JWTs or API keys to your logs — technically not a crash, but it exposes secrets to anyone with log access.

Integrity could be a bad access check in an API that lets one user tamper with another user’s data.

And availability? In Erlang and Elixir we even have a classic—atom exhaustion. If an attacker can force your system to create new atoms unchecked, they can take your node down in seconds. Or it could be as mundane as an unbounded search query — a clever attacker can send a pathological input that ties up your database for seconds or minutes, starving everything else that relies on it.

Also consider scope: is it something that could affect a single user, or could it ripple out to every deployment?

If you’re unsure where this falls, you don’t have to guess alone. Reach out early—EEF’s CNA can help you triage and figure out whether what you’ve found truly qualifies as a vulnerability and how serious it is.”

9 of 37

Is it public?

Has the issue been exposed anywhere? (issues, forums, social, PoC)
Is someone already talking about it or exploiting it?
if it’s public, you may need to disclose before the patch is ready

Ægis Initiative

10 of 37

Confirmed RCE in tabulex

Ægis Initiative

Timing: 09:45–10:55

“Time to verify. I crafted a payload tuple pointing at :os.cmd, wrapped it in a Base64 URL param, and dropped it into Tabulex’s state. On the server side, Tabulex decodes it with binary_to_term, then naïvely calls apply/3—and boom, remote code execution.

In plain terms: if an attacker sends ?state=<evil string>, your server will run whatever system command they embed. We’ve just confirmed Tabulex versions up to 1.3.7 are fully compromised.

This isn’t unique—similar flaws have popped up before.

In this moment, we make three decisions: Yes, this is a real vulnerability; No, it’s not public yet—it came to us via a private report; and our plan is to patch first and only publish the advisory once the fixed release is available.

This approach gives us a little breathing room to craft a robust fix before anything goes public.”

11 of 37

2. Shed Shame

Mistakes happen. Hiding them makes things worse.

Ægis Initiative

12 of 37

63%�https://arxiv.org/pdf/2503.22134

Everyone Ships Bugs

Ægis Initiative

Timing: 11:20–12:25

“Here’s a universal truth: no one ships perfect code. Mistakes slip in your own code—maybe you pushed a filter you didn’t fully test—or they hitch a ride in your dependencies, often in ways upstream authors never intended.

In a March 2025 study of 14 million Maven releases, about 31 percent of projects pulled in a known vulnerability through direct dependencies—and nearly 63 percent when you include transitive ones.

So if you feel that knot of shame thinking ‘I shouldn’t have introduced that bug,’ know you’re far from alone. The stronger lesson is: process beats perfection. And part of that process is simply knowing what’s actually in your software—that’s where things like SBOMs come in, and we’ll come back to that later.

For now, the point is: you don’t need perfection. You need a process.”

13 of 37

Shame → Trust

Owning up builds confidence; hiding erodes it.

Ægis Initiative

Timing: 12:25–14:00

“When you find a vulnerability, your first instinct might be to hide it—to push a silent patch and hope no one notices. But silent patches leave users unaware, scanners untriggered, and trust quietly erodes.

And attackers do notice—reverse-engineering patches is trivial, so silence can actually hand them a head start. In fact, there are people and bots that do nothing but watch commit feeds, diff releases, and look for suspicious changes. If they spot the fix before your users do, the exploit window actually gets longer, not shorter.

Worse, your community may feel betrayed if they find out later—sometimes that even leads to forks as people backport their own fixes. And without a proper advisory, automated tools like Dependabot, MixAudit, Renovate, or OSV scanners will never alert users to update—they’ll stay vulnerable long after the fix exists.

Instead, owning the issue—publishing a clear advisory, explaining the impact, and crediting contributors—builds confidence. For example, when a major framework in our ecosystem recently transparently disclosed a security flaw, the community response was overwhelmingly positive and the fix was adopted within days. That’s how you turn a mistake into an opportunity for trust.”

14 of 37

3. Coordinate Disclosure

Ægis Initiative

15 of 37

What is a CVE?

“Common Vulnerabilities and Exposures”
Global ID for a security issue
Managed through a network of CNAs
Standardized record in a global database

Ægis Initiative

Timing: 14:25–16:30

“Let’s pause and talk about CVEs themselves, because they’re at the center of how vulnerability disclosure works.

CVE stands for Common Vulnerabilities and Exposures. At its simplest, a CVE is a unique identifier—like CVE-2025-12345—that says ‘this security issue is the same one everyone else is talking about.’

You can think of it like an index card in a giant global library of vulnerabilities. It doesn’t tell the whole story, but it makes sure everyone is pointing to the same place in the catalog. That way developers, vendors, and scanners aren’t talking past each other—they’re all referencing the same card.

Each CVE entry is a short, standardized record: it has the ID, a brief description of the vulnerability, affected products or versions, and often a severity score like CVSS. The point is consistency: every database and vendor can refer to the same issue in the same way.

The CVE system itself is decentralized. It’s run by MITRE, but managed day-to-day by a global network of organizations called CNAs—CVE Numbering Authorities. CNAs are trusted partners that can validate a vulnerability report and assign a CVE ID. There are CNAs for big vendors, like Microsoft or Red Hat, and there are ecosystem CNAs for specific languages and communities.

The structure matters because it means you don’t have to wait on a single central authority. Instead, CNAs close to your ecosystem can handle reports, assign IDs, and ensure vulnerabilities are captured quickly and consistently.

So in short: a CVE is the common reference point. It doesn’t tell the whole story of a vulnerability, but it ensures we’re all speaking the same language when we describe one.”

16 of 37

EEF CNA Can Guide You

Triage Help
Advisory Support
CVE Coordination
Ongoing Partnership

cna@erlef.org�cna.erlef.org/contact

Ægis Initiative

17 of 37

18 of 37

CVE Assignment

Ægis Initiative

Timing: 17:55–19:10

“Once your advisory draft is ready, the CNA steps in to validate the information and suggest improvements—like refining the CVSS score, a simple 0-to-10 measure that blends exploitability and impact.

After that review, we obtain the CVE ID. Very shortly you’ll get an email with something like CVE-2025-12345. Think of that CVE as a license plate number—it doesn’t say how dangerous the bug is, but it gives everyone in the world a common handle to track the same issue.

That matters because once it’s in the system, Dependabot, OSV.dev, NVD, and every other major database can all connect the dots automatically. Without a CVE, you’d have scattered advisories with no glue between them.

Important: having the CVE doesn’t force you to publish today. It simply means that when your patch is ready, all the metadata and the severity rating are waiting—so your advisory can go live instantly without extra paperwork.”

19 of 37

How to read a CVE?

How to read a CVE?
Look it up on cve.org or cna.erlef.org/cves
Contains vendor / 3rd party advisory link
Standard structure:

CWE, CVSS, Description, Affected, Workarounds, Mitigations, References, Credits

Published as standardized JSON (raw view often shows more)

Ægis Initiative

Timing: 19:10–21:05

“Now that we know what a CVE is and how it is assigned, let’s talk about how to actually read one.

Every CVE entry contains a reference link—usually to a vendor advisory or a third-party advisory. That linked advisory is where you’ll typically find the most detail: patch instructions, context, and sometimes a full write-up.

You can look up any CVE on cve.org, which is MITRE’s official site. And if it’s an Erlang or Elixir vulnerability, you can also browse them directly at cna.erlef.org/cves, where the ones we assign are listed.

Each CVE has a standardized structure with a few common building blocks:

CWE — the type of weakness, like ‘Improper Input Validation.’
CVSS — the severity score.
Description — a human-readable summary.
Affected — which products and versions are impacted.
Workarounds / Mitigations — short-term and long-term fixes.
References — links to advisories or discussions.
Credits — the researchers or reporters who found it.

Behind the scenes, all of this is published as standardized JSON. That raw JSON often contains more information than user interfaces show, so if you’re analyzing a vulnerability, it can be worth looking directly at the raw CVE data.

The key point: a CVE isn’t just an ID. It’s a structured record that gives you the who, what, and how of a vulnerability, and always points you to the most authoritative advisory.”

20 of 37

Common Vulnerability Scoring System�(CVSS)

Attack Vector
Complexity
Privileges Required
Impact (C / I / A)

Ægis Initiative

Timing: 21:05–22:30

“CVSS—the Common Vulnerability Scoring System—is the tool we use to boil a vulnerability down into a single number between 0 and 10.

It works by scoring a few key dimensions: how the attack happens—network or local. How complex it is—does it need special conditions. What privileges the attacker needs. And what impact it has on confidentiality, integrity, and availability. Add those together, and you get that one simple number.

But here’s the catch: sometimes that number feels misleading. You’ll see a bug with a score of 9.8 that, in practice, doesn’t feel catastrophic for your specific context. That’s not a mistake—that’s how the system works. The number is a shorthand, but if you really want to gauge severity, you have to look at the breakdown behind it.��For instance, imagine a denial-of-service that crashes your node reliably — it might score an 8.6, which sounds catastrophic, but if you’re behind a load balancer and it just means restarting a worker, the practical risk might be quite different. CVSS captures technical severity, not business impact.”

21 of 37

22 of 37

Narrative: PoC leaks

23 of 37

24 of 37

Should you disclose now?

	Patch Ready	Patch Not Ready
Vulnerability Public	Publish Advisory & Patch	Disclose Immediately & Offer Mitigations
Vulnerability Not Public	Plan Disclosure & Merge	Prepare in Private

Ægis Initiative

Timing: 23:50–25:00��“When it comes to disclosure timing, the key factor is whether details of the vulnerability are already out there. You don’t need a proof-of-concept—you just need public knowledge that people can exploit it, especially with today’s automated tooling.��If the vulnerability is public and you already have the patch, go ahead and publish both the advisory and the fix immediately. If it’s public but your patch isn’t ready, you must disclose now and provide interim mitigations so users aren’t caught off guard.��If the vulnerability isn’t public and your patch is ready, use that private window to plan your disclosure: finalize wording, coordinate with the CNA, then merge and publish on your terms. And if it’s private and the patch isn’t ready, use the time to prepare in private—test thoroughly and draft your advisory before anyone sees it.��This framework helps you avoid two extremes: rushing without plan or delaying when users need answers.”��

25 of 37

4. Patch & Release

Ægis Initiative

26 of 37

Writing the Fix

Develop in Private
Tabulex Use�Plug.Crypto.non_executable_binary_to_term(..., [:safe])
Write Tests

Ægis Initiative

27 of 37

Release Fix & Publish Vulnerability

Publish the Fix Release
Notify the CNA
Publish GitHub Security Advisory
Retire Affected Hex Versions

Ægis Initiative

Timing: 26:10–27:10

“With the patch coded and tested, step one is to publish your fixed release—bump the version, tag it, and push to Hex so users can upgrade immediately.��Consider which versions your users are currently using. It might be useful to backport a patch and also release a patch for earlier versions like 1.0.x, 1.1.x and so forth. It might even make sense to backport it to earlier major releases to ensure users still on the last major version are able to remediate the issue quickly.

Next, tell the CNA it’s time to publish the CVE now that your patch is available—this officially injects the identifier into global vulnerability feeds.

Then flip your GitHub Security Advisory from draft to public so the world sees your advisory alongside the code.

Finally, retire the affected Hex versions to prevent any new installs of the vulnerable releases”

28 of 37

Hex Version Retirement

Ægis Initiative

29 of 37

5. Communicate

Ægis Initiative

30 of 37

Inform Your Users

Document Vulnerability, Impact and Remediation
Amplify on Social Media / Forums
Note in README / CHANGELOG

Ægis Initiative

31 of 37

Spread of Vulnerability Info

MITRE
NVD
OSV.dev
GitHub Advisory Database
EUVD
…

Dependabot
Renovate Bot
MixAudit
OSV Scanner
Paraxial.io
…

Ægis Initiative

32 of 37

6. Prepare for the next Time

Ægis Initiative

33 of 37

SECURITY.md

Contact Methods
Supported Versions
Set Expectations
PGP Key

Ægis Initiative

Timing: 30:00–31:05

“A SECURITY.md is your playbook when trouble strikes. First, list an email and link directly to your GitHub Security Advisory so reporters have a private channel.

Next, specify Supported Versions—which releases you’ll provide patches for—so users know whether they’re in scope.

List your Contacts & Roles, including the CNA and your core maintainers, so reports land in the right inbox.

Help set clear Expectations around response and resolution: you don’t need exact SLAs, but indicate what reporters can generally expect in terms of acknowledgments and follow-up.

Finally, include a PGP Key or fingerprint so sensitive details can be submitted securely.

With these sections in place, you’ll be ready next time—no scrambling to figure out who does what.”

34 of 37

Dependency Scanning / Updates

Automatic Updates: Dependabot / Renovate / …
See Mix Dependency Submission GH Action
OSV Scanner
MixAudit

Ægis Initiative

Timing: 31:05–32:15

“Automation is your watchdog. First, Dependabot Security Updates will open PRs whenever any of your dependencies ship a new security patch. And if you’re not on GitHub, Renovate Bot offers the same kind of automated upgrade support across other platforms.

Next, the Mix Dependency Submission Action extracts your Elixir project’s dependencies and submits them to GitHub’s Dependency Submission API. That unlocks advanced features: a complete dependency graph, Dependabot alerts for direct and transitive deps, automated PRs, GitHub’s Dependency Review in pull requests, and overall better visibility for compliance.

OSV Scanner then cross-checks your lockfile against the OSV.dev database, flagging any known issues.

And Mix Audit provides Elixir-specific scanning, surfacing CVEs right in your CI.

Together, these tools form a safety net—alerting you early so you can fix before the next incident.”

35 of 37

Tips for Corporations

Generate SBoM
Monitor with Tool like DependencyTrack
Build Relationship with Dependency Maintainers
Sponsor the CNA & OSS in general
Embed in SDLC

Ægis Initiative

Timing: 32:15–33:20

“In a corporate setting, you can augment community practices with organizational muscle. First, maintain an accurate Software Bill of Materials using standards like CycloneDX and tools like DependencyTrack, and hook it into vulnerability feeds so you’re alerted the moment a flaw appears.

Next, don’t treat open source as a black box—build relationships with the teams behind the libraries you use. Sponsor their work, help triage issues, or simply share how you’re using their projects. Those connections pay dividends when a vulnerability crops up.

Consider sponsoring the Erlang Ecosystem Foundation and your critical dependencies to keep the CNA and other security efforts funded and the libraries you depend on maintained.

Finally, bake these checks into your software development lifecycle: automated scans, security gates, and sign-offs in CI/CD ensure no release slips through unchecked.”

36 of 37

Key Takeaways

Prepare Now
Ground your Response
Own the Narrative
Retire & Publish

Ægis Initiative

Timing: 33:20–34:30

“Let’s wrap up with four key takeaways.

First: prepare by setting up a Security Policy for all your open source projects. If you only take one thing from this talk, let it be this—because when an incident comes, having a clear process already in place will make everything else survivable.

Second: ground your response—methodically assess severity, scope, and visibility before every move to avoid over- or underreacting.

Third: own the narrative—shed the shame, coordinate open disclosure, and leverage the CNA partnership to build user trust.

Fourth: retire and publish—use Hex retirement to block old versions, publish your advisories, and ship patched releases��And remember: even if you do nothing else, having a Security Policy today means you’re already better prepared than most projects out there..”

37 of 37

Q&A

Thanks to the sponsors of the EEF Ægis Initiative

Slides

EEF Vulnerability Guide

Ægis Initiative