1. Phish Or Legit
Fast email judgment
Players review short email scenarios and classify them by sender, link, tone, attachment, and authentication clues.
Mini-Game Arcade
Use this page to review the proposed mini-games before we build them. Each idea is defensive, browser-safe, and designed to teach evidence, prioritization, communication, or workflow judgment without scanning real systems.
Build First
These are the strongest first releases because they match existing Vuln Signal content and can be implemented with local data, no risky live testing, and clear replay value. The expanded catalog below adds board, timeline, chain, card, budget, map, and mobile-style mechanics.
1. Phish Or Legit
Players review short email scenarios and classify them by sender, link, tone, attachment, and authentication clues.
2. Patch Panic
Players drag limited patch capacity across CVEs while balancing KEV, EPSS, exposure, business impact, rollback risk, and fixed-version availability.
3. CVE Courtroom
Players decide whether a claim is proven, not proven, or needs validation, then rewrite risky language into safe operational wording.
4. Scanner Finding Trial
Players inspect scanner output, vendor notes, version clues, backports, feature state, and exposure before accepting or closing a finding.
5. Executive Brief Boss Fight
Players convert messy vulnerability details into a concise leader update with owners, blockers, caveats, and next-review timing.
Shared Backend Catalog
Loading game API status.
Category
Difficulty
Catalog
Awareness
Goal: classify suspicious emails. Mechanic: reveal clues one at a time, then decide. Score: accuracy, clue discipline, and safe explanation.
Awareness
Goal: spot brand impersonation. Mechanic: compare display name, sender domain, reply-to, link target, and pressure language. Score: false-positive control and escalation choice.
Awareness
Goal: choose safe QR-code behavior. Mechanic: inspect context, requested action, destination clue, and alternative verification path. Score: verification before trust.
Awareness
Goal: respond to repeated login prompts. Mechanic: choose actions across push spam, password reset, account lock, and reporting. Score: containment speed and communication.
Operations
Goal: allocate limited patch windows. Mechanic: rank work by exploitation, exposure, asset value, rollback risk, and fix confidence. Score: priority quality and unused-risk reduction.
Operations
Goal: pick temporary controls when patching is blocked. Mechanic: match WAF, segmentation, disablement, monitoring, or access restriction to scenario constraints. Score: control fit and review timing.
Operations
Goal: choose response deadlines. Mechanic: inspect exploit maturity, exposure, confidence, safety, and business impact. Score: deadline realism and caveat quality.
Operations
Goal: handle unavailable or risky fixes. Mechanic: choose monitor, mitigate, vendor escalation, exception, or owner validation. Score: keeping risk owned and time-bounded.
Evidence
Goal: separate proven claims from assumptions. Mechanic: review exhibits and rule on exposure, exploitation, affected scope, or remediation claims. Score: proof discipline.
Evidence
Goal: validate or reject scanner output. Mechanic: inspect plugin text, product version, package lineage, backport notes, and owner evidence. Score: false-positive handling.
Evidence
Goal: classify fast-moving vulnerability clues. Mechanic: drop cards into exploitation, exposure, remediation, trust, and business-context lanes. Score: speed plus category accuracy.
Evidence
Goal: avoid bad affected-version conclusions. Mechanic: compare upstream versions, distro advisories, package changelogs, and scanner assumptions. Score: correct closure evidence.
Threat Intel
Goal: interpret exploitation signals correctly. Mechanic: compare KEV, EPSS, PoC, vendor language, and public chatter. Score: urgency without overclaiming local exposure.
Threat Intel
Goal: understand prerequisite chains. Mechanic: assemble initial access, auth state, vulnerable component, execution, and impact cards. Score: realistic chain logic.
Threat Intel
Goal: decide what belongs in detection. Mechanic: classify domains, hashes, paths, URLs, and behaviors as useful, noisy, or unsafe to trust. Score: detection value and caveats.
Threat Intel
Goal: extract the actionable path from advisory text. Mechanic: unlock fixed version, prerequisites, affected platforms, mitigations, and escalation questions. Score: complete advisory read.
Communication
Goal: write a safe update under pressure. Mechanic: pick facts, caveats, owners, blockers, and asks while avoiding unsupported claims. Score: clarity and claim safety.
Communication
Goal: repair vague vulnerability tickets. Mechanic: add affected proof, owner ask, action lane, due date, rollback note, and validation evidence. Score: ticket executability.
Communication
Goal: choose the right owner. Mechanic: route cases to SOC, IR, patch, vendor, risk, legal, or leadership with a reason. Score: routing precision and next step.
Communication
Goal: close work without pretending more than the evidence supports. Mechanic: choose patched, mitigated, not affected, accepted risk, false positive, or pending evidence. Score: closure quality.
Design Rules
Use seeded scenarios, public concepts, local scoring, and clear defensive framing.
Rotate short cases, constraints, fake companies, score modifiers, and feedback prompts.
Each round should produce a decision, handoff, ticket, brief, detection note, or evidence checklist.
Prefer cards, segmented choices, drag alternatives, and short feedback that works in the Android WebView.
Recommended build order: start with Phish Or Legit, Patch Panic, CVE Courtroom, Scanner Finding Trial, and Executive Brief Boss Fight. Then add mitigation, ticket, escalation, and advisory games once the scoring pattern is proven.