gmh5225 Game Build, Update, and Mod Supply Chains
Use this skill to review release and content trust boundaries. Route runtime object models to game-engine, platform package signing to mobile-security, and privileged driver behavior to windows-kernel.
For repository-backed choices, read the supply-chain resource guide for CI entry points, editor acquisition, hot-patch runtimes, and asset-parser dependencies.
Map Release Authority
Source and dependencies -> build -> artifact and provenance -> signing
-> publication/channel -> delivery -> updater/install -> game or plugin load
Record who can change source, build instructions, signing policy, uploaded artifacts, live channels, and installed files. Distinguish release credentials, signing keys, build identities, and player sessions. A delivery service is one part of this chain. SteamPipe distinguishes builds, depot manifests, and live branches, and recommends dedicated, restricted build accounts. Valve SteamPipe uploads
Threat Objectives and Evidence
| Objective | Boundary requiring review | Useful evidence |
|---|---|---|
| Substitute a release or dependency | Producer/build identity and artifact binding | Source revision, build inputs, provenance, artifact digest |
| Publish an unauthorized channel update | Signing and publication authority | Release approvals, credential scope, channel history |
| Keep a client on stale content or combine inconsistent metadata | Freshness, version, and metadata consistency | Trusted metadata versions, expiry, role and target relationships |
| Abuse build jobs to affect other releases | Build isolation and secret boundaries | Worker lifecycle, cache provenance, signing boundary |
| Obtain code execution through a mod/plugin | Import and execution permissions | Exact content version, format, validation and allowed capability |
| Overwrite protected files or exhaust import resources | Extraction/install path and resource boundaries | Staging location, destination policy, expanded-size and work budgets |
These are review categories, not evidence that a particular publisher or mod platform is compromised.
Update Verification and Recovery
Review trust roots, delegated roles, signature thresholds, target hashes and lengths, metadata versions, expiry, and consistency across metadata files. HTTPS or an executable signature alone does not cover every update decision. Distinguish metadata rollback from an operator-authorized application rollback published through new valid metadata. Record offline clients, clock uncertainty, expired metadata, and the owner of recovery policy.
Expiry alone does not prove a freeze attack. Do not silently bypass freshness checks; use the documented authenticated recovery process for the system.
TUF addresses update metadata trust and freshness; it does not establish safe application behavior, compatible releases, or transactional installation. TUF specification 1.0.36
Build Provenance and Isolation
Bind provenance to the actual artifact digest and verify its trusted builder, canonical source, build type, and expected parameters. Merely finding a signed attestation is insufficient. Record where verification happens and which compromised components that observation could detect. Provenance is not a code security audit. SLSA 1.2 artifact verification
Treat scripts, plugins, compilers, caches, and user-controlled build inputs as distinct influences. Review job isolation, transient environments, cross-build effects, and separation of signing secrets from user-defined build steps. State the assurance level actually achieved; SLSA Build L3 requirements do not eliminate every insider, dependency, or platform risk. SLSA 1.2 build requirements
Released Components and User Content
Associate the SBOM with the shipped artifact and platform. Distinguish build dependencies, bundled runtime libraries, native SDKs, editor plugins, launchers, and services. Record identity, version, digest, source, relationship, and owner where available. Inventory completeness and vulnerability applicability require separate verification; an SBOM alone is not a clean bill of health. CycloneDX SBOM
Separate data assets, scripts, native modules, and editor tools by their import and execution permissions. Workshop has ready-to-use and curated models; not all Workshop content undergoes the same developer approval. Platform delivery does not establish a sandbox or safe execution. Bind review to a content version and reassess material updates. Valve Workshop models
For archives, maps, saves, textures, and manifests, review actual format, destination paths, protected-file boundaries, isolated staging, parser versions, and processing budgets. Include expanded size and file count; extension, MIME, or compressed download size alone is insufficient. These are defensive applications of file-ingestion principles to games. OWASP file upload guidance
Review Output
Report artifact/build/channel/platform, producer and source identity, build and release authorities, expected verification policy, observed checks, affected boundary, compatibility alternatives, recovery owner, and unresolved scope. Keep signature validity, authorized publication, freshness, compatibility, and runtime safety as separate conclusions. Apply research-rigor to evidence and uncertainty.
Primary sources reviewed: 2026-09-09. TUF and SLSA references are explicitly versioned examples; verify the implementation's chosen specification/version.
Data Source
Use the following repository sources directly when applying this skill. Prefer available local files for discovery and scoped historical inspection; use the raw URLs when the collection is not installed locally. These entrypoint details are retained here so source lookup does not depend on loading another skill.
0. Compiled Wiki
Start with wiki/index.md for topical synthesis and cross-project connections. Wiki schema describes its structure. Generated wiki pages are discovery aids; follow their original citations before adopting technical claims.
Raw catalog: wiki/index.md. This skill does not currently have a matching wiki overview. Use its local references and the wiki catalog to find related pages; do not invent a path.
A direct project question can start with its README entry or description below; reading the entire wiki is unnecessary.
1. Project Overview and Resource Index
README.md contains the collection's actual categories, subcategories, project URLs and short descriptions. Find the relevant category and retain the original URL, including any specific file or revision suffix.
Raw index: README.md.
2. Repository Descriptions
For a concise project summary, look for the actual local path:
description/{owner}/{repo}/description_en.txt
https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/description/{owner}/{repo}/description_en.txt
Example: bgfx description. Extract owner/repository from the original GitHub project URL, omitting a .git suffix. Resolve existing path casing before constructing a local/raw path. Descriptions are generated summaries, not independent verification. If absent or inaccessible, use the README entry, relevant archive or original project.
3. Repository Source Archives
For deeper inspection of an available captured source tree, locate:
archive/{owner}/{repo}.txt
https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/archive/{owner}/{repo}.txt
Example: bgfx archive. Prefer inspecting the relevant portion of an existing archive over re-cloning merely to inspect the same captured material. Archives may exclude files, use fallback extraction or contain truncation; they are not guaranteed complete checkouts. Record any upstream revision evidence and included-file limits. If missing or insufficient, follow the README's original upstream URL.
Choose and Verify the Source
For a specific project, locate its README identity, use a description or wiki page for orientation when helpful, then inspect the relevant archive/source artifact for the question. For current compatibility or exact implementation, verify the matching upstream documentation, release or immutable source revision. Keep the collection revision and capture/generation dates separate from the upstream version. Multiple generated layers from one source are not independent corroboration, and missing archive content does not establish upstream absence.
The per-domain resource guide above helps choose useful artifacts. Shared repository navigation adds the optional read-only indexer, case-ambiguity handling and maintenance details; it supplements this Data Source section rather than replacing it.