Shift-Left Security and Anti-Cheat Design
Model abuse during design instead of bolting defenses onto finished systems
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 96%
Shift-left security moves threat analysis from the end of development to the earliest design conversations. While teams are still whiteboarding a game or system, they identify valuable assets, likely attackers, abuse cases, and ways the proposed design could fail. Preventive controls are then built into architecture and implementation rather than attached after release. In game development, the same workshop can examine conventional security threats and cheating because both involve adversarial use of system mechanics. The output is a design with fewer exploitable assumptions and clearer detection points. Later prevention and monitoring tools become more effective because they reinforce an inherently resistant system instead of compensating for structural weaknesses that are expensive or impossible to remove.
Origin
Adam Murray presented shift-left design as a way for game companies to improve resilience on Security Bookmarked.
Core principles
- 01Security begins while the system is still being designed
- 02Threat modeling exposes abuse paths before implementation hardens them
- 03Security and anti-cheat can share early design work
- 04Secure foundations make later detection and prevention more effective
How to run it
- 1
Identify critical assets
List the code, data, game mechanics, services, and workflows that must remain confidential, available, or trustworthy.
Pro tip Include unreleased assets, build systems, backups, and competitive game integrity.
Watch out Do not limit the inventory to customer-facing systems.
- 2
Model adversaries and abuse
Ask how attackers, cheaters, insiders, or compromised accounts could take advantage of each proposed component.
Pro tip Use concrete questions such as how the feature could go wrong or be manipulated.
Watch out Avoid assuming users will interact with the system only as intended.
- 3
Design resistance
Choose architectural constraints and controls that prevent or limit the identified abuse paths.
Pro tip Prefer controls inherent to the design over optional checks added later.
Watch out Late-stage controls may not repair a fundamentally unsafe trust model.
- 4
Build observable signals
Define the events and anomalies that detection systems should monitor when prevention fails.
Pro tip Connect each high-priority threat to at least one measurable signal.
Watch out Detection without a planned response leaves teams aware but unprepared.
- 5
Validate throughout delivery
Revisit the threat model during implementation and test whether controls resist the anticipated attacks and cheating methods.
Pro tip Update the model whenever architecture or trust boundaries change.
Watch out A threat model becomes stale if treated as a one-time design document.
In the wild
Before implementing item trading, a game team maps duplication, account takeover, fraudulent transfers, and backend abuse. It designs server-authoritative validation, transaction logs, rate limits, and recovery controls before building the user interface.
→ Security and anti-cheat protections reinforce the core transaction architecture rather than depending on post-launch patches.
Common mistakes
Threat modeling after implementation
Late analysis often reveals weaknesses that require expensive architectural changes or cannot be fully mitigated.
Separating cheating from security
Both are adversarial problems, and considering them together can expose shared trust assumptions and controls.
Is it for you?
Best for
Software and game teams designing new systems, major features, or architectural revisions.
Not ideal for
Emergency incident response where an active compromise must be contained immediately.
From the transcript
“you want to make sure you're baking security in from the very beginning”
“add a threat model to that process from the very beginning, thinking about how could somebody take advantage of this, how could it go wrong?”
From the episode
Security, Bookmarked: Gaming (Sponsored Content)