Casino game supplier security should be accepted against the exact release that will enter an operator or aggregation platform, not against a reusable questionnaire. Policies describe how a studio intends to work. Release evidence shows what was built, which components are inside it, how it was produced, what changed and which risks remain.
For an operator, RGS provider, aggregator or procurement leader, the practical delivery artifact is a supplier release assurance schedule. It turns security expectations into contract fields, evidence items, owners, acceptance tests and stop conditions that apply from vendor evaluation through every production update.
Put the exact release inside the assurance boundary
The assurance boundary should name one immutable game artifact, its version, its cryptographic digest, its target environment and the evidence that belongs to it. A supplier policy, penetration-test summary or certification letter can support the review, but none identifies by itself whether the file presented today is the file that was examined.
This boundary matters in regulated gaming because supplier responsibility does not remove operator responsibility. The UK Gambling Commission’s security audit advice says a business using a licensed B2B provider should obtain contractual terms, service levels and assurance statements and should not assume that the supplier relationship absolves it of responsibility. The Commission’s security requirements also cover supplier agreements, ICT supply chains, secure development, application security, testing and change management for relevant gambling systems.
Write the artifact identity into the release record before reviewing supporting documents. Require the same identity in the deployment request, SBOM, provenance statement, test evidence, change record and approval. Reject a package when those records point to different versions, branches or build times, even if every document looks complete in isolation.
Bind an SBOM to every accepted game build
An SBOM should describe the components and dependency relationships inside the exact game release, including transitive dependencies where the tooling can resolve them. CISA’s 2025 Minimum Elements for a Software Bill of Materials says each version or update should have an associated SBOM and treats component coverage, including transitive dependencies, as part of the inventory’s value.
Contract for a machine-readable format, the document creator, creation time, component names and versions, supplier identities, dependency relationships and identifiers that help match components to advisories. Also require the artifact digest or another unambiguous release reference. The supplier should describe known gaps, such as dependencies hidden by a proprietary toolchain, instead of silently presenting partial coverage as complete.
An SBOM is an inventory, not a verdict. It does not show that a dependency is exploitable in the deployed context, that no vulnerability exists or that the build came from reviewed source. Use it to drive triage, supported-version decisions and incident questions. Keep provenance and verification as independent controls.
Use provenance to prove where the artifact came from
Build provenance should connect the delivered artifact to its source inputs and build process in a form the buyer can verify. The SLSA specification defines a build track for increasing confidence that an artifact came from the expected source and build system. Its provenance model can be adopted incrementally without claiming a level the supplier has not reached.
At minimum, ask who or what invoked the build, which source revision and dependencies were used, which isolated builder produced it, when it ran and which digest identifies the result. Prefer signed attestations and an independent verification step. Protect signing keys and build identities separately from ordinary developer access.
NIST’s Secure Software Development Framework gives purchasers a common vocabulary for acquisition and supplier conversations. It includes protecting software components, producing well-secured releases and responding to residual vulnerabilities. These are cross-industry procurement practices, not gambling approvals. Their role is to make a supplier’s software process inspectable while the applicable regulator and test laboratory remain authoritative for gaming obligations.
Contract vulnerability handling before disclosure arrives
Vulnerability handling should be a named operating path with time limits, supported versions, decision owners and evidence requirements before the first report arrives. The release schedule should state how the supplier receives reports, confirms affected components, assesses exploitability, communicates material changes, ships a fix and proves the replacement artifact.
Do not turn a public severity score into an automatic accept or reject decision. Record the affected component, reachable behavior, deployment exposure, compensating controls, available fix, exception owner and review date. A finding can affect a server integration, browser game client, asset pipeline or build tool differently. The buyer still needs one traceable decision for the shipped version.
Require notification when an SBOM component becomes affected after release and when a supported version reaches end of life. Test the disclosure address and escalation route during onboarding. A policy that no one can reach is not an operational control.
Connect supplier changes to certification impact
Supplier change control should route security changes and gaming certification impact through separate checks that meet again at release acceptance. The UK Gambling Commission’s Annex A on major and minor updates treats a change that may affect game fairness as major and gives RNG, scaling, mapping and game-rule changes as examples that may require external retesting.
A dependency patch can be security-relevant without changing game behavior. Another update can touch outcome logic, required information or recovery behavior and need both reviews. Record the change identifier, affected game and components, before-and-after versions, security decision, major-or-minor classification, test scope, approvals and resulting artifact identity. The Commission’s release good practice supports that disciplined change record.
The certified game release guide explains how deployment controls remain subordinate to change classification. Supplier assurance adds the component, provenance and vulnerability evidence around that same immutable build. Neither control replaces the other.
Accept evidence through tests instead of questionnaires
Supplier acceptance should test whether the buyer can verify and operate the evidence, not merely whether files exist. Select a representative release and run the pack through procurement, security, engineering, compliance and release operations before signing the long-term schedule.
Test at least these failure cases:
- the SBOM names a different artifact or omits a known transitive dependency;
- provenance points to an unexpected source revision or unapproved builder;
- the supplier cannot reproduce the artifact digest from the approved pipeline;
- a vulnerability report reaches an unattended address or has no decision owner;
- a change record does not explain certification impact;
- the replacement build arrives without refreshed evidence;
- deployment is requested after an acceptance exception has expired.
Define who can accept an exception, what compensating control is required and when the exception closes. Preserve the evidence needed for audit and incident response under an agreed retention rule. Avoid collecting source code, credentials or personal data when a signed assertion, digest or scoped test result answers the control.
Turn the requirements into a supplier release schedule
A supplier release schedule should make the evidence pack a deliverable with objective acceptance conditions. Attach it to the RFP or agreement, then keep the same fields in the release workflow so procurement promises do not disappear after integration.
The schedule should contain:
- the exact artifact name, version, digest and target environment;
- the SBOM format, coverage rule, creation identity and known-gap declaration;
- the provenance format, required source and builder fields, signature and verifier;
- secure-development and test evidence appropriate to the release risk;
- the vulnerability intake, notification, remediation, exception and end-of-life rules;
- the change record, certification-impact decision and required approvals;
- the acceptance tests, rejection conditions, retention period and named owners.
Make each item versioned and portable enough to survive a personnel or tooling change. A dashboard can help operations, but the buyer should be able to export the evidence associated with an accepted release. The result is not a claim that the game is risk-free. It is a repeatable way to know what entered production, why it was accepted and how the next change will be judged.
For a new title or supplier replacement, our game development team can help define the release boundary, build evidence and acceptance tests alongside the game architecture. Talk to Wizards about the exact game build and supplier handoff you need to commission.
Frequently asked questions
What security evidence should a casino game supplier provide?
A casino game supplier should provide evidence tied to the exact release, including the artifact identity, an SBOM with transitive dependencies, build provenance, test results, unresolved vulnerability decisions, change classification, approvals and a supported disclosure route.
Does a casino game SBOM prove that a release is secure?
No. An SBOM describes software components and relationships, but it does not prove that the source, build process, configuration or artifact is secure. Buyers need provenance, verification, vulnerability handling and acceptance tests as separate controls.
Should every casino game update have a new SBOM?
Every accepted version or update should have an SBOM associated with that exact artifact. A supplier may generate it from a repeatable pipeline, but the buyer should not accept a floating inventory that cannot be matched to the shipped build.
What is software build provenance for a casino game?
Software build provenance is verifiable information about where a release came from, including its source inputs, build process and resulting artifact. It helps a buyer detect a substituted, stale or unexplained build.
How should a supplier vulnerability affect game acceptance?
The contract should define how vulnerabilities are reported, assessed, mitigated and reverified, with severity criteria, supported versions, response owners and exceptions. The buyer then applies those rules to the exact release and its deployment context.
Can supplier security evidence replace game certification?
No. Software supply chain evidence and game certification answer different questions. A change can require both security review and the jurisdiction-specific testing or approval that applies to game fairness, RNG behavior, rules or required player information.
