equilibrium-engine

Inspiration

Security spending is decided by guesswork. Companies patch "everything, eventually." Bug bounty programs pick payout numbers by gut feel. Nobody can say why an attack happened — only that it did. There's no calculable, falsifiable theory of when an attack becomes rational, only intuition dressed up as best practice.

We wanted to know: what if attacks aren't random? What if there's a single mathematical line that separates "this system will get attacked" from "this system won't" — and what if you could move that line on purpose?

What it does

Equilibrium is a game-theoretic model of cybersecurity economics built around one core claim, which we call the Threshold Law:

An attack is rational if and only if the attacker's effective cost falls below their expected gain.

Every feature in this project is either an application of that law or an extension of it:

• Three real-world scenarios (patch timing, bug bounty pricing, multi-asset resource allocation) — each one is a different lever for moving a system relative to the same threshold. Patching lowers expected gain. Bounty pricing raises effective attacker cost. Allocation spreads a fixed budget to push as many systems across the threshold as possible.
• A live Nash equilibrium solver — for any of the three scenarios, computes the mathematically optimal probability of investing in defense, not just "defend everything."
• A repeated-game extension — real attackers learn. We model an attacker updating its belief about your defenses after every probe, using a Bayesian-flavored update rule, and show whether the resulting threat escalates or fades over 12 rounds.
• A falsifiability test against real data — the Threshold Law predicts that real exploit rates should jump sharply at some cutoff, not rise smoothly. validate.js tests this directly against two live, free, public datasets: FIRST.org's EPSS exploitation-probability scores and CISA's Known Exploited Vulnerabilities catalog (the ground truth of which CVEs were actually exploited in the wild).
• A real policy extension: should ransomware victims pay? We extended the same threshold framework to a live, contested policy debate — several governments and insurers have proposed banning ransomware payments outright. We added a financing feedback loop (ransom paid this round funds attacker capability next round) and found a genuinely non-obvious result: under realistic parameters, banning payments makes total victim harm worse for roughly the first 17 rounds, then crosses over and becomes net-beneficial from round 18 onward. The ban only "wins" once enough rounds pass for starved attacker capability to outweigh the harm of victims losing data outright.

How i built it

The entire engine is built with zero external dependencies — pure JavaScript math, a Node API using only the built-in http module, and a single self-contained HTML file for the web app (so it runs on any phone browser with no setup, no build step, no API key).

• engine.js — the core math: a 2x2 Bayesian game solver for Nash equilibria, the Threshold Law calculator, the repeated-game belief-drift simulator, and the ransomware policy comparison model.
• server.js — a REST API exposing every model as an endpoint (/simulate, /threshold, /repeated-game, /ransomware-policy).
• index.html — the interactive demo: live sliders, an "equilibrium needle" that swings between "defend" and "don't defend" in real time, threshold visualizations, and the ransomware policy comparison chart.
• validate.js / selftest.js — the validation pipeline. selftest.js proves the analysis logic is correct against synthetic data with known ground-truth shapes (run first, no internet needed). validate.js then tests the real falsifiable claim against live EPSS and CISA KEV data.

We tested every piece of math by hand before it touched the UI — writing small scripts to sanity-check edge cases (e.g., "if attack cost vastly exceeds gain, the model should say attack is irrational") before trusting the numbers in a slider.

Challenges i ran into

We caught and fixed three real bugs during development, and we think being honest about them matters more than pretending the first version was correct:

1. A broken efficiency metric. Our first version of the equilibrium solver compared a strategy's cost against itself by construction, always returning ~0. We fixed it by comparing the equilibrium against genuinely naive fixed policies facing the attacker's best response to those policies — the real exploitability gap.
2. A silent normalization bug in the ransomware financing model. Revenue collected was being normalized against the entire population's hypothetical revenue instead of the revenue actually achievable from victims attacked that round, which diluted the financing signal into irrelevance. Attacker capability incorrectly shrank even when every victim paid. Fixing the normalization revealed the real dynamic: capability climbs when payments fund the attacker, exactly as the real-world mechanism predicts.
3. A noisy step-function detector. Our first statistic for detecting a "sharp threshold" in real data flagged smooth, linear trends as false positives. We caught this with an offline self-test using synthetic data with known shapes (a true step function vs. a smooth one) before ever pointing the script at real data, and rebuilt the statistic to require both a dominant single jump and a statistical outlier z-score before calling it a step.

We also don't have a working PC — this entire project, including all the code, was built and tested on an Android phone.

Accomplishments that I'm proud of

• A single unifying mathematical law (the Threshold Law) that explains three seemingly different security decisions as the same underlying inequality.
• A falsifiability pipeline that doesn't just claim to be scientific — it's built to be checked against real, live, public data, with its own analysis logic independently verified first.
• A genuinely non-obvious finding (the 18-round crossover in the ransomware policy model) that we didn't design in — it emerged from testing, including a bug fix that flipped the direction of the result.
• A complete, working system (math engine, API, interactive web app, validation pipeline) built entirely on a phone with no PC.

What i learned

That a "moonshot" doesn't have to mean a flashier UI or a bigger feature list — it means finding the one abstraction that makes three separate problems turn out to be the same problem. We also learned, repeatedly, that the math has to be tested before it's trusted: every major insight in this project (the financing feedback loop, the crossover point, the step-function detector) only became correct after we found and fixed a bug that was hiding it.

What's next for equilibrium-engine

• Calibrate the ransomware policy model's "rounds" against real incident-timeline data, rather than leaving them as an abstract unit.
• Run validate.js against the full EPSS/CISA KEV datasets (rather than a single sample) and publish the actual step-function result.
• Extend the repeated-game belief update from a heuristic approximation toward a full partially-observable model of attacker learning.

Built With

• css
• game-theory
• github
• html
• javascript
• node.js