Runtime Protection for a Live-Service Game Backend That Ships Daily

A live-service game backend gets runtime protection from three habits working together: you always know which image digest is running in which environment, every build is scanned and gated before it reaches production, and the clusters and hosts that run game services are watched for the few behaviours that matter most, such as crypto-miners, unexpected shells and container escapes. The release cadence does not change the goal. It changes how much of this has to run without a human starting it.

This guide is for the platform security engineer at a game studio who owns the clusters, the build pipelines and the on-call rota behind matchmaking, player accounts, inventory, the store and the dedicated game servers. The first two thirds work with whatever tools you already run. The Safeguard walkthrough comes later, after an illustrative scenario that is a composite example, not a customer. Nothing here is legal or regulatory advice.

Key takeaways

• Runtime protection starts before runtime. If you cannot say which image digest serves production matchmaking right now, no detection rule will tell you whether an alert matters.
• NIST SP 800-190 splits container risk into image, registry, orchestrator, container and host risks. A game backend needs a control for each, not just a scanner on the build.
• Gate production on the things you can defend in a postmortem: known exploited vulnerabilities (the CISA KEV catalog) and critical severity first, with time-boxed exceptions instead of silent overrides.
• Watch for the handful of behaviours that map to real attacker technique on game infrastructure: resource hijacking for mining (MITRE ATT&CK T1496), command interpreters spawned from services (T1059) and escape to host (T1611).
• In Safeguard, asset discovery (GA), software composition analysis on container images (GA), vulnerability management with EPSS and KEV (GA), continuous scanning (GA), reachability analysis (GA), and policies and gates (GA) carry the workflow today. Autonomous remediation (GA) ships switched off, with every category set to Manual.
• Be clear about the edges. Runtime Protection (GA) watches running workloads, but Safeguard's docs say the Kubernetes admission controller is not published, so this workflow gates at build and in the platform rather than at pod admission.

The situation: the job and who owns it

You are the platform security engineer, or the small platform security team, at a studio running a live-service game. The client ships through console and mobile stores on their certification schedules. The backend waits for nobody: it ships whenever a fix, an event or a balance change is ready, which on a busy week means several production deploys a day.

The backend is the part attackers care about. It holds player accounts and sessions, the inventory and currency ledger, the store and entitlement services, matchmaking, chat, leaderboards, telemetry and the fleet of dedicated game servers that host matches. Most of it runs as containers on Kubernetes, and the dedicated servers usually sit on large node pools with a lot of CPU.

That last detail draws a specific attacker. A fleet sized for a launch weekend has idle CPU on a quiet Tuesday, and a crypto-miner is the cheapest way to turn code execution in one container into money. Account and economy services draw a different attacker who wants currency, items or accounts. Both start the same way: a vulnerable component in a running image, an exposed admin endpoint or a container with more privilege than it needs.

What triggers the work

The trigger is the release cadence itself. The studio moves the backend from monthly releases to continuous delivery, and a security model built on a manual review of the image list stops working. The questions change shape:

• From the live ops lead: can we ship the event hotfix tonight, or is there a security hold?
• From the head of engineering: why did a build fail the security check when nothing in our code changed?
• From the incident commander: is this a capacity problem, or is something running on those nodes that should not be?
• From leadership after a news story about another game: are we exposed, and where?

What a bad week looks like

A new vulnerability lands in a library that half your services pull in through a shared base image, and nobody can say which production images contain it because the image list in the wiki is a quarter old. Meanwhile, off-peak CPU on the game server pool creeps up, and on-call scales the pool, because more players is the usual explanation. None of this is exotic. Each failure is an inventory, a gate or a detection that existed on paper and did not keep up with the release rate.

The standards behind it

No single regulation covers runtime protection for game studios. The guidance you can cite comes from a handful of public documents that auditors and platform holders will recognise.

NIST SP 800-190, Application Container Security Guide

NIST published SP 800-190 in September 2017, and it is still the clearest public statement of what goes wrong with containers. Section 3 sorts the risks into five groups: image risks (3.1), registry risks (3.2), orchestrator risks (3.3), container risks (3.4) and host OS risks (3.5). A scanner on the build covers only part of the first group. Two sub-sections fit game backends closely: 3.3.4, mixing of workload sensitivity levels, which is what happens when game servers and account services share nodes and networks, and 3.4.5, rogue containers, which is what an unplanned test build in production looks like.

SP 800-190 also describes containers as immutable: you fix one by rebuilding the image and redeploying, not by patching inside it. That fits continuous delivery well, as long as the rebuild is cheap and automatic.

NIST SP 800-218, the Secure Software Development Framework

SP 800-218 version 1.1 (February 2022) is the SSDF. Its Respond to Vulnerabilities group starts with RV.1, identify and confirm vulnerabilities on an ongoing basis, followed by RV.2, assess, prioritise and remediate, and RV.3, analyse root causes. The word that matters for a game backend is ongoing. A build-time scan knows only the advisories that existed on build day.

NIST SP 800-61 Revision 3

SP 800-61 Rev. 3 (April 2025) superseded Rev. 2 and frames incident response as a CSF 2.0 community profile, part of everyday risk management rather than a separate emergency procedure. Cite it when you write the runbook for what happens after a runtime alert fires.

Kubernetes Pod Security Standards and hardening guidance

The Kubernetes Pod Security Standards define three cumulative profiles: Privileged (unrestricted, allows known privilege escalations), Baseline (prevents known privilege escalations) and Restricted (current pod hardening practice). Game server pods are where teams quietly run Privileged because a networking tweak needed it once. The Kubernetes multi-tenancy guide adds that many security policies, RBAC among them, are scoped to namespaces, which is why separating game servers from account services by namespace matters. The NSA and CISA Kubernetes Hardening Guide, first released in August 2021 and updated in 2022, covers the operator's side; CISA now lists that alert as archived content, so check for newer guidance before citing it in an audit.

The OWASP Kubernetes Top Ten

The OWASP Kubernetes Top Ten starts with insecure workload configurations (K01) and overly permissive authorisation (K02), and includes missing cluster level policy enforcement (K04), missing network segmentation (K05) and inadequate logging and monitoring (K10). Most are configuration you can check in an afternoon.

MITRE ATT&CK

MITRE ATT&CK gives you a shared vocabulary for runtime behaviour. Three techniques cover most of what a game backend sees:

• T1496, Resource Hijacking: using co-opted compute for the attacker's own work, with cryptocurrency mining the classic case.
• T1059, Command and Scripting Interpreter: running commands through a shell or interpreter, such as a reverse shell from a vulnerable service.
• T1611, Escape to Host: breaking out of a container to the underlying host, often through a privileged container or mounted host path.

Detections written against named techniques are easier to test and explain at 03:00.

CISA KEV and FIRST EPSS

The CISA Known Exploited Vulnerabilities catalog lists vulnerabilities with evidence of exploitation in the wild. FIRST's Exploit Prediction Scoring System (EPSS) estimates how likely a vulnerability is to be exploited soon. Both are free, and together they are the most defensible basis for deciding what blocks a release and what waits for the next sprint.

SBOMs

CISA's 2026 Minimum Elements for a Software Bill of Materials is now the US reference for what an SBOM should contain. Internally, an SBOM per image in CycloneDX or SPDX is simply the fastest way to answer which running services contain a given library. Payment card and children's privacy rules may also apply to your backend depending on the game; check those with your own counsel.

How teams do it today and where it breaks

Most studios have more security tooling than the platform security owner thinks, spread across teams that rarely talk:

• Build scanning nobody reads. A CI scanner fails builds in one repository and only warns in the rest, because a release once got stuck and someone switched the failure off.
• An image list in a spreadsheet. Accurate after the last launch; since then the event team added services and the game server image moved to a new base.
• Cloud alerts to an email list. A high CPU alert on a game server node pool looks exactly like a successful marketing push.
• Kubernetes defaults. The game server namespace runs Privileged because of a networking setting, and nobody revisited it.
• Incident response by chat. Whoever is awake decides whether to kill a pod or wait, and nobody writes it down.

Where it breaks under frequent releases

Each practice works at a monthly cadence and fails at a daily one, because each relies on a person noticing. At a daily cadence:

1. The inventory goes stale in days. Every deploy can change the digest behind a service, so an inventory not built from what the registry and cluster report is wrong by Friday.
2. Gates turn into negotiations. A gate with no exception process blocks an event hotfix at the worst time, the team learns to bypass it, and it stops meaning anything.
3. New advisories land on old builds. An image that passed on Monday can be vulnerable on Thursday.
4. Runtime alerts lack context. A shell spawned in a pod is only actionable if you know the owning service, its image and what that image contains.
5. Response is improvised. Without a runbook, people either act too slowly or take a service down at peak.

The fix is not more tools. It is wiring the ones you have into a loop that runs on every deploy and every new advisory, with a few decisions reserved for people.

Step by step: runtime protection with whatever tools you have

This sequence works with open source tooling, your cloud provider's features or a commercial platform. The order matters more than the brand.

1. Build the inventory from the registry and the cluster, not from memory

Join two lists: every repository, tag and digest your pipelines push to your registries (with the commit and pipeline run behind it), and the digest each running workload actually uses, by cluster, namespace and service. Pin deployments to digests; a tag like latest or event-hotfix tells you nothing about what is running.

Give each workload an owner, an environment and a sensitivity band. For a game backend, three bands usually work: accounts, sessions, payments and personal data; game state and the economy; everything else. Refresh the join on every deploy. The output answers one question: which production services run an image containing this package at this version?

2. Generate an SBOM for every image you build

Produce a CycloneDX or SPDX SBOM for every image at build time, keyed by digest, and check that it covers base image operating system packages as well as the service's language dependencies. The base layer is the one no service team considers theirs.

3. Scan every build, per environment, and record the result

Run software composition analysis on each built image and record the result against the environment it is heading for. The same image can be fine in test and not in production, and one record per environment makes that explicit.

4. Gate production on a short, defensible policy

Write the production gate as a handful of rules you would be happy to explain after an incident. A starting point:

Pair the gate with a written exception process. An exception names the finding, the service, the person who approved it, the business reason and an expiry date. Event hotfixes are where you will use it most, and that is fine, as long as the exception expires and the follow-up fix is tracked.

5. Keep evaluating after release

Subscribe to new advisories and re-evaluate the SBOMs of running images whenever the KEV catalog or a vulnerability feed changes. Route anything new that affects production to the service owner, with the image digest and the environment in the message. This is the SSDF's ongoing identification in practice.

6. Harden the orchestrator and the hosts

Walk the OWASP Kubernetes Top Ten and the Pod Security Standards with the cluster owners:

• Enforce the Baseline profile at minimum on every namespace, and Restricted where the service allows it.
• Document every namespace that needs Privileged, with a reason and a review date. Game server namespaces are the usual candidates. Ask whether the specific capability can be granted instead.
• Remove host path mounts and the container runtime socket from service pods unless there is a written reason.
• Apply network policies so that game servers cannot reach account databases, and so that outbound traffic from service pods goes only where it needs to.
• Keep node images and kernels on a patch schedule that the game ops calendar can live with, and drain and replace nodes rather than patching in place.

7. Watch for a short list of runtime behaviours

You do not need a large rule library to start. Write and test detections for the behaviours that map to the ATT&CK techniques above:

• Miners (T1496): sustained CPU on a pod or node that does not match player load, outbound connections to mining pools, or process names and arguments typical of miners.
• Shells and interpreters (T1059): a shell or interpreter process spawned by a service process that never normally starts one, especially with its input and output connected to a network socket.
• Escape attempts (T1611): containers starting privileged, mounting host paths, or touching host namespaces, plus writes to host paths from a container.
• Unexpected outbound traffic: a service calling hosts it has never called before, which is often the first sign of data leaving.

Allow-list benign cases such as interactive debug containers, or on-call learns to ignore the alert.

8. Write the response runbook before the alert

For each detection, decide in advance what on-call may do alone and what needs a security lead. A template:

Drill it once per season, outside peak hours.

9. Rebuild, do not patch in place

When a fix exists, update the dependency or the base image, rebuild, rescan and redeploy through the same pipeline. Keep the previous digest available for a one-step rollback. A container patched by hand inside a running pod is a container your inventory no longer describes.

Questions platform security teams ask about game backends

What does runtime protection cover for a game backend?

Three things: knowing what is running, keeping known vulnerable components out of production and noticing when a running workload does something it should not. Attacks on the game protocol, distributed denial of service, cheating and economy fraud are related problems with their own tools and owners.

How do you keep up when the backend ships several times a day?

Put the inventory, the scan and the gate in the pipeline so they run on every build without anyone starting them, and reserve human decisions for exceptions and destructive response actions. A step someone has to remember will not survive a launch week.

Should the build gate ever block an event hotfix?

Every build is evaluated, hotfixes included. A KEV-listed vulnerability in an account service should block, and if the business accepts that risk for a day, the hotfix ships under an approved, time-boxed exception. A medium finding in a leaderboard service should not block anything. Write the rules so the common case passes.

Do dedicated game servers need different treatment?

Scan and gate the game server image like any other. Treat its node pool as a high-value target for runtime detection, because it holds a lot of CPU and often runs with extra privileges or host networking. The anti-cheat backend service belongs in the inventory too.

Illustrative scenario: Ridgeline Games ships a season update

This is a composite example, not a customer. The studio, its services and its decisions are invented to show how the steps fit together.

Ridgeline Games runs a live-service shooter on Kubernetes in two regions: account and session services, an inventory and currency service, a store that hands checkout to a payment processor, matchmaking, chat, telemetry and dedicated game server pods on their own node pool. Two platform security engineers share on-call with the platform team. Ahead of a new season, the backend moves to continuous delivery.

Monday. The first joined inventory from the registry and the clusters shows production workloads on a deprecated base image, a debug sidecar in the matchmaking namespace that nobody remembers adding, and the game server namespace running Privileged. Every workload gets an owner and a sensitivity band. The sidecar is removed.

Tuesday. Every pipeline now produces an SBOM and a scan result per environment, and the production gate goes live with two Block rules (KEV-listed and critical) and the rest on Warn. That evening the inventory service fails the gate on a critical vulnerability in a base image library with a fix upstream. The owner rebuilds on the updated base and the next build passes.

Wednesday. An advisory lands for a library in the chat service, whose image passed its gate on Monday. Re-evaluation flags it and notifies the chat owner with the digest and environment. The vulnerable function is not on a path the service calls, so the upgrade goes into the next planned release.

Thursday. Off-peak CPU rises on two game server nodes. Instead of scaling the pool, on-call sees the miner detection fire on a pod calling an address the service has never contacted, cordons both nodes, stops new matches on them and pages the security lead, who approves deleting the pod and replacing the nodes. The cause is a test build deployed to production by a misconfigured pipeline, a rogue container in SP 800-190 terms. The follow-ups: block images without an SBOM from production, and review who can deploy to the game server namespace.

Friday. The live ops lead asks whether the season update can ship. Every service in the release passes its gate or carries a named Warning, and the one open exception expires on Monday with a linked ticket. The update ships.

Nothing in that week needed a new product: an inventory built from reality, a short gate with exceptions, re-evaluation after release, a few detections and a runbook. The rest of this post shows which of those parts Safeguard runs.

How Safeguard does this

Safeguard covers the inventory, the scanning, the re-evaluation and the gate in this workflow. The steps below use only what Safeguard's documentation describes today, with the docs page linked for each step. Where the docs show a command, it is copied exactly; it was not run for this post.

1. Connect registries and Git providers for asset discovery

Asset discovery (GA) catalogues repositories, container images, packages, SBOMs, AI models and vendor dependencies, and binds each to an owner, a business context and a risk profile. Per the Asset Discovery docs, agentless integrations connect to your Git providers, container registries and cloud accounts and then continuously enumerate new repositories and images and watch for pushes, tags, releases and deletions.

Owners are inferred from Git CODEOWNERS, container labels or manual assignment, and assets carry an environment and a sensitivity label that drive routing. Shadow asset detection flags things that exist but are not governed, such as an image in a registry with no SBOM, and shows them as UNGOVERNED on the Asset Discovery dashboard.

Three notes from the same page. Its /v1 REST endpoints are not available yet, so use the app. There is no CLI command for querying the asset graph; queries run from the Search page in ESSCM. And the lightweight agents it describes for clusters and hosts are the runtime collector from the Runtime Protection page, so deploy it on your clusters to fill in the running-workload half of your inventory.

2. Scan every image your pipeline builds, per environment

Software composition analysis (GA) and SBOM generation (GA) run on container images as well as repositories. The container image CI docs show one step added after the image is built:

safeguard ci scan --image "ghcr.io/acme/api:$TAG" --environment prod --wait --fail-on critical

The scan runs on the CI runner and only the results leave it. Each --environment becomes its own version under the image's repository, so the record shows what runs where, and the docs suggest failing only where it matters: --fail-on critical in production, none in development. Setup needs a key with scans:trigger and scans:read, stored as SAFEGUARD_API_KEY; each registry card under Integrations has a Set up CI/CD button that generates the steps. The page's GitHub Actions example:

- name: Build
  run: docker build -t "ghcr.io/acme/api:${{ github.sha }}" .
- name: Safeguard image scan (prod)
  env:
    SAFEGUARD_API_KEY: ${{ secrets.SAFEGUARD_API_KEY }}
    SAFEGUARD_INSTALL_DIR: ${{ runner.temp }}/safeguard-bin
    IMAGE: ghcr.io/acme/api:${{ github.sha }}
  run: |
    set -eu
    curl -fsSL https://cli.safeguard.sh/install | bash
    "$SAFEGUARD_INSTALL_DIR/safeguard" ci scan --image "$IMAGE" --environment prod --wait --fail-on critical

Add it to every service pipeline, game server image included.

3. Prioritise with KEV, EPSS and reachability

Vulnerability management (GA) enriches findings with EPSS and CISA KEV status, and reachability analysis (GA) ranks findings by whether your code actually calls the vulnerable path. Per the reachability analysis docs, static reachability builds a call graph from your source, lockfile and bytecode, and a finding the analyser cannot decide is marked conservatively as potentially reachable. The dynamic variant, which records what actually loads in production, depends on the runtime collector, so it covers the clusters where you deploy the collector. Reachability changes the order of work; it does not decide on its own that a finding can be ignored.

4. Keep re-evaluating images after they ship

Continuous scanning, part of vulnerability management (GA), re-evaluates assets when vulnerability feeds change, including new CVE, GHSA and OSV entries, CISA KEV additions and EPSS changes, and when an asset changes, such as a new image tag in a registry. Per the Continuous Scanning docs, new advisories are matched to stored components, and only affected assets are rescored.

New or escalated findings are routed by owner, severity, exploitation status and environment; configure routes in Settings → Notifications (chat channels, tickets, email digests, on-call paging, webhooks). Send KEV-listed findings in production straight to the owning team's on-call channel and the rest to a daily digest.

5. Turn your production rules into policies and gates

Policies, gates and guardrails (GA) hold the production rules. Per the Policies and Gates docs, policies evaluate your SBOMs and generate findings, and gates are the checkpoints that enforce them. Create a policy under Settings → Policies with the visual builder or YAML, or start from a template such as No Critical Vulnerabilities or No Abandoned Packages.

Each policy has one Action, and the policy outcomes docs spell out what each does when the policy fails:

Approval runs through exceptions. A developer requests an exception against a policy and finding, gives a business justification and an expiry date, and an approver grants or denies it, with the decision recorded in the audit trail.

Gates are evaluated by the platform on the scans it runs, not by a separate gate command in your pipeline. With policy outcomes turned on for your workspace, the docs show this command failing a CI job when a gate fails:

safeguard ci scan --wait --fail-on-gate <gate name or id | all>

It exits zero when the gate is Passed or Warning, and non-zero when the gate is Failed, Error or Not evaluated. Policy outcomes are turned on per workspace by Safeguard; if your Gates and Policies tables do not show an Outcome column yet, ask your Safeguard contact to turn it on.

A starting production gate for a game backend, using condition types the Policies and Gates page lists:

KEV status is part of every finding's enrichment, so filter on it when you triage even if your first gate keys on severity and EPSS.

6. Open fix pull requests when a fixed version exists

Autonomous remediation (GA) opens tested, policy gated pull requests that move a dependency to a safe version, on one repository or in bulk. It ships switched off, with every category set to Manual. Per the AI Remediate docs, the manual path is: open the vulnerability, click AI Remediate, review the proposed changes and click Create Pull Request. For several findings, select them and click AI Remediate Selected, which batches compatible fixes into one pull request per repository. Keep account and store services on manual review, and consider more automation later for low-risk services.

7. Know what the runtime side covers today

Runtime Protection (GA) is documented in the Runtime Protection docs as a rule engine that maps detections to MITRE ATT&CK techniques, including reverse shells (T1059), crypto-miners (T1496) and container escape (T1611), with per-workload allow-lists and a default policy of detect and alert only until a tenant opts in. The Linux eBPF runtime collector feeds the engine live workload events, and an administrator switches runtime protection on with a feature flag.

So, plainly: deploy the collector on the game server and service node pools, start in detect and alert mode, and tune the allow-lists before you opt in to anything more. Keep your existing runtime tooling running alongside it until the detections are tuned. The Guardrails and Enforcement docs say the Kubernetes admission controller is not published, so Safeguard does not block a non-compliant image at pod admission. Enforcement happens at the CI step and in the platform's gate outcomes.

8. Work from the terminal or an assistant

The Safeguard CLI (GA) scans code, container images and SBOMs on your own machine and sends only the results to the platform. Running safeguard opens an interactive terminal with an assistant that can fix what it finds, asking before any command that changes something. The local runner (GA) executes the platform's scan jobs on your machine, so a team can scan without granting repository access. Per the CLI docs, policies and gates are evaluated in the platform, not by the CLI. For teams that live in an AI assistant, the Safeguard MCP server (GA) exposes read-only tools for gate outcomes, policy outcomes and evaluation history when policy outcomes are on for the workspace.

Mapping the job to Safeguard

What to measure

Use this as a checklist for your own programme. None of these are claimed outcomes; they are the numbers worth tracking so you can tell whether the loop is working.

• Share of production workloads whose image digest is known and maps to an SBOM.
• Share of production workloads with a named owner and sensitivity label.
• Share of service pipelines, including the game server image, that scan every build per environment.
• Number of production gate failures per week, split by rule, and how many were resolved by a rebuild versus an exception.
• Open exceptions, and how many are past their expiry date (the target is none).
• Time from a new KEV listing to knowing which production services are affected.
• Time from a new KEV listing affecting production to a fixed image deployed.
• Namespaces running the Privileged profile, each with a documented reason and review date.
• Runtime detections tested in the last season, and the result of the last response drill.
• Alerts closed as benign that led to an allow-list change, so the same false positive does not page twice.

What Safeguard does not do

• It does not enforce at Kubernetes admission today. The docs state the admission controller is not available. A pod with a non-compliant image will not be stopped by Safeguard at deploy time; the gate acts at the CI step and in the platform.
• It does not tune itself. Runtime detections start in detect and alert mode with per-workload allow-lists. Your team tunes them, and keeps its existing response tooling, before relying on them for paging.
• It does not harden your cluster or hosts. Pod Security profiles, network policies, node image patching and kernel updates remain the platform team's work.
• It does not handle game-specific threats. Cheating, account takeover through credential stuffing, fraud in the in-game economy and distributed denial of service need their own tools and owners.
• It does not decide or act for you on incidents. Cordoning nodes, terminating matches, rotating credentials and notifying players or regulators are decisions for your people and your incident process.
• It does not replace review of its fix pull requests. Autonomous remediation ships switched off, and even when enabled, the team owns merging and deploying.
• It cannot fix what you do not build. A managed database, a vendor appliance or a hosted service gets its fix from that vendor.

Common mistakes

1. Gating on everything at once. A production gate that blocks on every high and critical finding on day one will be bypassed within a week. Start with KEV and critical, and add rules as the backlog shrinks.
2. Exceptions with no expiry. An exception without an end date is a permanent policy change nobody approved.
3. Trusting the build-time scan forever. An image that passed on Monday can be vulnerable on Thursday. Re-evaluate running images when advisories change.
4. Forgetting the game server image. It is often built by a different team, on a different pipeline, with a different base. It needs the same scan and gate.
5. Scaling first, asking later. Rising off-peak CPU on game server nodes is worth one look at process and network activity before the pool scales up.
6. Leaving Privileged in place after the launch. Exceptions made for a launch weekend become the default for the next year unless someone owns the review.
7. No drill. The first time on-call cordons a node should be in a drill, not during a season launch.

FAQ

How do I scan container images on every release without slowing deploys?

Add one scan step after the image build in each pipeline and fail only in production, and only on a short list of rules. Everything else warns or notifies. In Safeguard, the documented step is safeguard ci scan --image with --environment and --fail-on.

Which vulnerabilities should block a game backend release?

Start with any vulnerability on the CISA KEV catalog and any critical severity finding, in production only. Use EPSS and reachability to rank the rest. Allow time-boxed exceptions with a named approver for event hotfixes.

How do I detect crypto-mining on game server nodes?

Look for sustained CPU that does not match player load, outbound connections to mining pools and miner-like process names and arguments, and map the detection to MITRE ATT&CK T1496 so the runbook is clear. Review it before scaling the node pool.

Does Safeguard block deployments at the Kubernetes admission stage?

No. Safeguard's docs say the admission controller is not available yet. Gates act at the CI step and in the platform's gate outcomes.

Does Safeguard watch running containers today?

Yes. Runtime Protection (GA) runs a rule engine mapped to MITRE ATT&CK, fed by the Linux eBPF collector, covering reverse shells, crypto-miners and container escape. It detects and alerts by default until your tenant opts in to more.

What is the difference between a policy and a gate in Safeguard?

A policy evaluates your SBOMs and produces findings. A gate is a checkpoint that links policies and enforces them. Each policy's Action (Block, Warn or Notify) decides what a failure does to the gate.

How do approvals work if a gate blocks a hotfix?

Through exceptions. A developer requests one against the policy and finding with a business justification and an expiry date, an approver decides, and the decision is recorded in the audit trail.

Does autonomous remediation change our code without review?

It ships switched off, with every category set to Manual. When you turn it on, it opens pull requests that your team reviews and merges.

The gate catches vulnerable components before they reach your game servers, and the fastest way to stop failing it is to have the fixed version already in the build. The section below explains how Safeguard closes that gap when a fix exists and when it does not yet.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal with safeguard, and asks it to fix the lodash CVE in a repository. The assistant reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing, then shows /permissions, /model and /scan. The same loop applies when a gate blocks a backend service build on a vulnerable dependency.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code and then scans from the terminal. Studios that keep server code on internal machines can scan there and send only results.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session. It sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. For an on-call platform engineer away from a desk during a launch, that keeps a human decision on every change.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• NIST SP 800-190, Application Container Security Guide
• NIST SP 800-218, Secure Software Development Framework 1.1
• NIST SP 800-61 Rev. 3, Incident Response Recommendations
• Kubernetes Pod Security Standards
• Kubernetes multi-tenancy
• CISA, Updated Kubernetes Hardening Guide
• OWASP Kubernetes Top Ten
• MITRE ATT&CK T1496, Resource Hijacking
• MITRE ATT&CK T1059, Command and Scripting Interpreter
• MITRE ATT&CK T1611, Escape to Host
• CISA Known Exploited Vulnerabilities Catalog
• FIRST Exploit Prediction Scoring System
• CISA, 2026 Minimum Elements for a Software Bill of Materials
• CycloneDX SBOM capabilities
• Safeguard docs: Asset Discovery
• Safeguard docs: Container images in CI/CD
• Safeguard docs: Continuous Scanning
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: Guardrails and Enforcement
• Safeguard docs: Runtime Protection
• Safeguard docs: Software Composition Analysis
• Safeguard docs: Reachability Analysis
• Safeguard docs: AI Remediate
• Safeguard docs: CLI
• Safeguard use case: Runtime protection

Download Safeguard at safeguard.sh/download and read the documentation at docs.safeguard.sh/docs.

Related reading: runtime versus static container analysis, Kubernetes supply chain security best practices, generating an SBOM from container images, container image supply chain incidents in 2026, guardrails and policy gates for a fintech CI pipeline and self-healing containers for a telecom platform. Safeguard's own summary of this job is on the runtime protection use case page.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.