Beyond Anti-Cheat: Exploring the Security Behind Modern Games

When people talk about security in video games, one of the first things that comes to mind is cheating. Aimbots, wallhacks, modified game clients and other tools that give players an unfair advantage.

But there is another side of game security that we do not always think about.

Modern online games are much more than the game running on a player's computer. Behind the experience, there can be player accounts, payment systems, matchmaking services, game APIs, chat systems, telemetry, cloud infrastructure and many other connected components.

Think about a game that receives regular updates, introduces new characters, adds an in-game marketplace or changes its multiplayer features. Every update also introduces changes to the software behind the game.

What happens if a developer accidentally exposes an API key? What if a vulnerable dependency enters the backend? What if an insecure configuration reaches the production environment?

These are not just development problems. They can become security problems that affect the game and its players.

This is what made me interested in exploring DevSecOps from a gaming industry perspective.

Why I Started Game Security Lab

I wanted to understand how security could become part of the entire game development process instead of being something checked only before a release.

That idea became Game Security Lab: DevSecOps Masterclass, a hands-on project based on 100 practical labs across 10 modules.

The scenario was a fictional gaming studio with a development and release engineering environment. I worked with a Node.js game-service API, a placeholder C# client following a Unity-style structure, Docker containers, infrastructure configurations and Kubernetes manifests.

The goal was to create a security-focused development and release workflow using GitHub, GitHub Actions and different open-source security tools.

Rather than focusing on one security product, I wanted to understand how different controls could work together.

For example, a developer should not be able to push an unreviewed change directly into the main branch. Code should be checked for common vulnerabilities. Secrets should not accidentally enter the repository. Dependencies and container images should be inspected. Infrastructure configurations should follow defined security policies.

These controls should be part of the development workflow.

Starting With the Development Environment

The first thing I worked on was the development foundation.

I created the repository structure and introduced Git-based version control, pull requests, branch protection, code ownership and commit-signing awareness.

Why does this matter?

Imagine a development team working on a competitive multiplayer game. One developer changes the authentication service, another works on the matchmaking API, and someone else modifies the anti-cheat integration.

Without proper review requirements, a sensitive change could reach the main branch without the right people checking it.

Branch protection and code ownership help establish a review process for important parts of the project.

I also worked on GitHub Actions to automate checks when changes were submitted through pull requests.

This was one of the first important lessons for me: security needs to be part of the normal developer workflow.

It should not depend entirely on someone remembering to check everything manually.

What Happens When Code Enters the Pipeline?

After establishing the repository and workflow, I moved towards automated security testing.

I explored tools such as CodeQL and Semgrep for Static Application Security Testing (SAST).

In simple terms, these tools analyse source code and look for patterns that could introduce security weaknesses.

I also created custom Semgrep rules for situations such as unsafe debug endpoints and client-side authority mistakes.

Consider a multiplayer game where the client sends information about a player's score, inventory or in-game currency.

Should the server simply trust everything the game client sends?

That is a dangerous assumption. A modified client could attempt to send values that should never be accepted.

A secure design should validate important decisions on the server side rather than trusting the player's local game client.

This is one reason I included a Unity-style C# client placeholder in the project. It gave me a way to explore security concerns involving both game clients and backend services.

The project also included workflow security checks. I worked on restricting GitHub Actions permissions, checking workflow syntax, controlling third-party actions and improving shell-script safety.

A CI/CD pipeline is itself an important part of the security boundary. Protecting application code is not enough if the automation responsible for building and releasing that code can be misused.

The Software Supply Chain Behind a Game

Another area I explored was software supply chain security.

Most modern applications depend on packages, libraries and external components. A game service is no different.

Imagine a studio using several npm packages for authentication, payment processing, matchmaking or other backend functions.

A vulnerability in one of those dependencies could introduce risk even if the studio's own code looks correct.

For this reason, I worked with:

• OSV-Scanner and npm Audit for dependency vulnerability checks.
• Dependabot for dependency update management.
• CycloneDX and Syft for generating Software Bills of Materials (SBOMs).
• Grype for scanning software components.
• Trivy for container image security checks.

An SBOM is essentially an inventory of software components used in an application or build. It helps developers understand what is included in the software they are preparing to release.

One interesting moment came when I scanned the initial Debian-based API container image with Trivy. The first scan reported 57 high or critical findings.

That made the container security work much more interesting. I then explored Dockerfile hardening, non-root execution and multi-stage image builds.

It also showed me why testing application code alone is not enough. The environment used to package and run the application matters too.

How Does This Connect to the Gaming Industry Today?

While working on this project, I also looked at how gaming companies approach security in real-world environments.

One interesting example is Riot Games and its anti-cheat system, Vanguard.

Riot publicly describes Vanguard as a game security solution that includes a client component and a kernel-mode driver. The company also discusses internal testing, external security audits and privacy considerations.

In December 2025, Riot published a security update explaining how it identified a motherboard firmware issue that could allow certain hardware cheats to inject code before the operating system fully started. Riot worked with hardware manufacturers on firmware updates to address the problem.

This is an interesting example because it shows that game security does not always stop at the game application itself. Hardware, operating systems, firmware and the environment in which a game runs can also become part of the security discussion.

Another related example comes from Microsoft's Xbox and Windows security teams. Their article, Building a Trusted Gaming Future: How Security Powers Fair Play, discusses technologies such as TPM 2.0, Secure Boot, Virtualization-Based Security and Remote Attestation.

These technologies help establish a more trusted system environment for modern gaming and anti-cheat solutions.

There is also a development-side perspective.

AWS's Games Industry Lens recommends securing the entire CI/CD pipeline through access controls, separation of duties, audit trails and least-privilege permissions.

It even provides an illustrative gaming studio scenario in which sensitive changes to anti-cheat and payment-related code require appropriate reviews. It also describes threat-model checks for marketplace features, including risks such as item duplication and fraudulent transactions.

I found that example particularly relevant to this project.

A game marketplace is not simply another screen in a game. It can involve valuable virtual items, player accounts and real financial transactions. A security mistake can affect much more than gameplay.

These examples cover different layers of security, but they connect to the same idea: protecting a modern game requires more than one security mechanism.

Containers, Infrastructure and Kubernetes

Once the application and its dependencies were covered, I moved further into the environment where a game service could run.

I worked with Docker to containerize the API and explored container scanning, Dockerfile configuration checks and image hardening.

I also introduced infrastructure and policy checks using OpenTofu, Checkov, Open Policy Agent (OPA) and Conftest.

The basic idea behind Policy as Code is simple.

Instead of relying only on documentation that tells developers what they should do, security requirements can be written as policies and tested automatically.

For example, a Kubernetes workload might be required to run as a non-root user. A service might need an environment tag. A deployment configuration might need to follow certain resource limits.

I created policy tests using both passing and intentionally failing examples. This helped me check whether the policies could recognise configurations that did not meet the expected requirements.

I also deployed the game API into a local Kubernetes environment using kind and explored security contexts, resource requests and limits.

These exercises helped me understand how application security and infrastructure security connect.

Player Data, Telemetry and AI-Assisted Development

One part of the project that I found particularly interesting was the final module.

I wanted to explore security topics beyond traditional code scanning.

Games can collect different types of information, including account details, gameplay events and telemetry. Not every piece of collected information should be treated in the same way.

I introduced player data classification and privacy-by-design telemetry policies.

I then tested the telemetry rules using Conftest. The retained test output showed 15 out of 15 policy tests passing.

Another topic was AI-assisted development.

Developers increasingly have access to AI tools that can analyse repositories, suggest code changes and assist with development workflows. But what happens when an AI agent has access to automation that can publish or release software?

I explored policy rules that prevent an AI-assisted workflow from publishing a release without human approval.

I also tested an intentionally unsafe configuration. The policy tests produced 10 failures, as expected.

This was not a live AI agent deployment. The work focused on testing security rules for workflow configurations.

Still, it raised an important question for me: as AI becomes part of software development, how do we make sure automated systems follow the same security boundaries as human developers?

Bringing Everything Together

The final stage of the project was the Secure Gaming Studio Release Control Plane.

The idea was to connect repository governance, CI/CD security, code scanning, secrets detection, dependency management, container security, infrastructure policies and security evidence into a structured release process.

I worked on the capstone architecture document, release-decision record, audit script and GitHub Actions workflow.

The project also included security evidence collection, vulnerability severity rules, remediation guidance and compliance mapping.

I wanted to move beyond simply displaying scanner results.

A security finding should have a process. It needs to be reviewed, prioritised and either fixed or handled through an approved exception. The release team should also be able to understand what checks were performed and what evidence supports a release decision.

That is the main purpose of bringing the controls together.

What I Actually Completed

The project followed a roadmap of 100 practical labs.

I also wanted to keep the technical report honest about what the available evidence demonstrated.

Based on the terminal histories and screenshots, 85 labs had evidence supporting their main implementation results. Nine were partially evidenced, and six were attempted but did not have verified successful completion.

The work was performed on a Windows workstation with Git, GitHub, Docker Desktop and a local Kubernetes environment.

It is important to understand that this was an educational and practical learning project, not a production gaming platform. It did not involve deploying a real commercial game, using a real cloud environment or operating a multi-region gaming infrastructure.

Some areas, including Cosign image signing, Argo CD reconciliation, OpenID Connect-based cloud identity and sovereign multi-region deployment, remained design exercises or were not demonstrated as working deployments.

I included these limitations because there is a difference between writing a security design, implementing a control and proving that it works.

That difference became one of the most valuable lessons from this project.

Final Thoughts

Before starting Game Security Lab, I mainly associated game security with anti-cheat systems and protecting players during gameplay.

After working through these labs, I started looking at the bigger picture.

A game is supported by code, APIs, dependencies, build systems, containers, infrastructure, deployment processes and player data. Each part introduces its own security considerations.

A single scanner cannot protect all of these components. Security needs to be built into the development process, tested through automation and supported by evidence.

For me, this project was an opportunity to explore how cybersecurity, software engineering and DevOps can work together in the gaming industry.

I am continuing to learn about secure software development, DevSecOps and the technologies that support modern gaming platforms.

The project and its practical implementations are available on GitHub.

Project: Game Security Lab: DevSecOps Masterclass Repository: https://github.com/shanukabherath-solutions/game-security-lab

For me, the most important lesson is simple: building a game is one challenge. Making sure the systems behind it can be trusted is another.