Segurança do fornecedor de jogos de cassino: guia de SBOM e evidências de release

A segurança de um fornecedor de jogos de cassino deve ser aceita contra o release exato que entrará na plataforma de um operador ou agregador, não contra um questionário reutilizável. Políticas descrevem como um estúdio pretende trabalhar. Evidências do release mostram o que foi compilado, quais componentes estão presentes, como foi produzido, o que mudou e quais riscos permanecem.

Para um operador, fornecedor de RGS, agregador ou líder de compras, o artefato prático é um anexo de garantia de releases do fornecedor. Ele transforma expectativas de segurança em campos contratuais, evidências, responsáveis, testes de aceite e condições de parada desde a avaliação do fornecedor até cada atualização de produção.

Coloque o release exato dentro do limite de garantia

O limite de garantia deve nomear um artefato imutável do jogo, sua versão, seu resumo criptográfico, seu ambiente de destino e as evidências correspondentes. Uma política do fornecedor, um resumo de teste de invasão ou uma carta de certificação podem apoiar a análise, mas nenhum deles identifica sozinho se o arquivo apresentado hoje é o arquivo examinado.

Esse limite importa em jogos regulamentados porque a responsabilidade do fornecedor não elimina a do operador. A orientação sobre auditoria de segurança da UK Gambling Commission diz que uma empresa que usa um fornecedor B2B licenciado deve obter termos contratuais, níveis de serviço e declarações de garantia, sem presumir que a relação a isenta de responsabilidade. Os requisitos de segurança da Comissão também cobrem acordos com fornecedores, cadeias de suprimentos de TIC, desenvolvimento seguro, segurança de aplicações, testes e gestão de mudanças para sistemas de jogo relevantes.

Registre a identidade do artefato antes de analisar os documentos de apoio. Exija a mesma identidade na solicitação de implantação, no SBOM, na declaração de proveniência, nas evidências de teste, no registro de mudanças e na aprovação. Rejeite um pacote quando esses registros apontarem para versões, branches ou horários de compilação diferentes, mesmo que cada documento pareça completo isoladamente.

Vincule um SBOM a cada compilação aceita

Um SBOM deve descrever os componentes e as relações de dependência dentro do release exato, incluindo dependências transitivas que as ferramentas consigam resolver. Os Elementos Mínimos de 2025 para um SBOM da CISA dizem que cada versão ou atualização deve ter um SBOM associado e tratam a cobertura de componentes, inclusive dependências transitivas, como parte do valor do inventário.

Contrate um formato legível por máquina, o criador do documento, a hora de criação, nomes e versões de componentes, identidades dos fornecedores, relações de dependência e identificadores que ajudem a associar componentes a alertas. Exija também o resumo do artefato ou outra referência inequívoca. O fornecedor deve declarar lacunas conhecidas, como dependências ocultas por ferramentas proprietárias, em vez de apresentar cobertura parcial como completa.

Um SBOM é um inventário, não um veredicto. Ele não mostra que uma dependência é explorável no contexto implantado, que nenhuma vulnerabilidade existe ou que a compilação veio de código revisado. Use-o para triagem, decisões sobre versões suportadas e perguntas durante incidentes. Mantenha proveniência e verificação como controles independentes.

Use proveniência para provar a origem do artefato

A proveniência de compilação deve conectar o artefato entregue aos insumos de código-fonte e ao processo de compilação de forma verificável. A especificação SLSA define uma trilha de compilação para aumentar a confiança de que um artefato veio do código e do sistema esperados. Seu modelo de proveniência pode ser adotado aos poucos sem alegar um nível que o fornecedor não atingiu.

No mínimo, pergunte quem ou o que iniciou a compilação, qual revisão de código e dependências foram usadas, qual construtor isolado a produziu, quando foi executada e qual resumo identifica o resultado. Prefira atestações assinadas e uma etapa de verificação independente. Proteja chaves de assinatura e identidades de compilação separadamente do acesso comum de desenvolvimento.

O Secure Software Development Framework do NIST fornece aos compradores um vocabulário comum para aquisições e conversas com fornecedores. Ele inclui proteger componentes, produzir releases bem protegidos e responder a vulnerabilidades residuais. Essas são práticas de aquisição de vários setores, não aprovações de jogos. Elas tornam o processo do fornecedor inspecionável enquanto o regulador e o laboratório aplicáveis continuam como autoridades para as obrigações de jogos.

Contrate a gestão de vulnerabilidades antes de uma divulgação

A gestão de vulnerabilidades deve ser um caminho operacional com prazos, versões suportadas, responsáveis e requisitos de evidência antes do primeiro relato. O anexo deve indicar como o fornecedor recebe relatos, confirma componentes afetados, avalia explorabilidade, comunica mudanças materiais, entrega uma correção e comprova o artefato substituto.

Não transforme uma pontuação pública de gravidade em decisão automática. Registre o componente afetado, comportamento alcançável, exposição, controles compensatórios, correção disponível, responsável pela exceção e data de revisão. Uma descoberta pode afetar de forma diferente uma integração de servidor, cliente web, pipeline de recursos ou ferramenta de compilação. O comprador ainda precisa de uma decisão rastreável para a versão entregue.

Exija notificação quando um componente do SBOM for afetado após o release e quando uma versão chegar ao fim do suporte. Teste o endereço de divulgação e a escalada durante a integração. Uma política que ninguém consegue alcançar não é um controle operacional.

Conecte mudanças do fornecedor ao impacto da certificação

O controle de mudanças do fornecedor deve encaminhar mudanças de segurança e impacto de certificação por análises separadas que se reencontram no aceite. O Anexo A sobre atualizações maiores e menores da UK Gambling Commission trata como maior uma mudança que possa afetar a equidade e cita RNG, escala, mapeamento e regras como exemplos que podem exigir novos testes externos.

Uma correção de dependência pode ser relevante para segurança sem alterar o comportamento do jogo. Outra atualização pode tocar a lógica do resultado, informações obrigatórias ou recuperação e precisar das duas análises. Registre identificador da mudança, jogo e componentes afetados, versões anterior e posterior, decisão de segurança, classificação maior ou menor, escopo de testes, aprovações e identidade do artefato. As boas práticas de release da Comissão apoiam esse registro disciplinado.

O guia de releases certificados explica como controles de implantação permanecem subordinados à classificação da mudança. A garantia do fornecedor acrescenta componentes, proveniência e vulnerabilidades ao redor da mesma compilação imutável. Nenhum controle substitui o outro.

Aceite evidências com testes e não questionários

O aceite do fornecedor deve testar se o comprador consegue verificar e operar as evidências, não apenas se os arquivos existem. Escolha um release representativo e passe o pacote por compras, segurança, engenharia, conformidade e operações antes de assinar o anexo de longo prazo.

Teste pelo menos estas falhas:

• o SBOM nomeia outro artefato ou omite uma dependência transitiva conhecida;
• a proveniência aponta para uma revisão inesperada ou construtor não aprovado;
• o fornecedor não consegue reproduzir o resumo pelo pipeline aprovado;
• um relato chega a um endereço sem atendimento ou não tem responsável;
• um registro de mudanças não explica o impacto de certificação;
• a compilação substituta chega sem evidências atualizadas;
• a implantação é solicitada após uma exceção expirar.

Defina quem pode aceitar uma exceção, qual controle compensatório é exigido e quando ela termina. Preserve evidências para auditoria e resposta a incidentes segundo uma regra acordada. Evite coletar código-fonte, credenciais ou dados pessoais quando uma atestação assinada, resumo ou teste delimitado responde ao controle.

Transforme os requisitos em um anexo de release

Um anexo de release do fornecedor deve tornar o pacote de evidências um entregável com condições objetivas de aceite. Anexe-o à RFP ou ao contrato e mantenha os mesmos campos no fluxo de release para que as promessas de aquisição não desapareçam depois da integração.

O anexo deve conter:

1. nome, versão, resumo e ambiente de destino do artefato exato;
2. formato e cobertura do SBOM, identidade de criação e declaração de lacunas;
3. formato de proveniência, campos de código e construtor, assinatura e verificador;
4. evidências de desenvolvimento seguro e testes adequados ao risco;
5. regras de recebimento, notificação, correção, exceção e fim de suporte;
6. registro de mudanças, decisão sobre impacto de certificação e aprovações;
7. testes de aceite, causas de rejeição, retenção e responsáveis.

Torne cada item versionado e portátil o suficiente para sobreviver a mudanças de pessoal ou ferramentas. Um painel pode ajudar, mas o comprador deve conseguir exportar as evidências do release aceito. O resultado não afirma que o jogo é livre de riscos. É uma forma repetível de saber o que entrou em produção, por que foi aceito e como a próxima mudança será julgada.

Para um novo título ou troca de fornecedor, nossa equipe de desenvolvimento de jogos pode ajudar a definir o limite, as evidências de compilação e os testes de aceite junto com a arquitetura. Fale com a Wizards sobre a compilação exata e a entrega do fornecedor que você precisa contratar.

Perguntas frequentes

Quais evidências de segurança um fornecedor de jogos de cassino deve fornecer?

Um fornecedor de jogos de cassino deve fornecer evidências vinculadas ao release exato: identidade do artefato, SBOM com dependências transitivas, proveniência da compilação, resultados de testes, decisões sobre vulnerabilidades não resolvidas, classificação de mudanças, aprovações e um canal de divulgação com suporte.

Um SBOM de jogo de cassino prova que o release é seguro?

Não. Um SBOM descreve componentes e relações do software, mas não prova que o código-fonte, o processo de compilação, a configuração ou o artefato sejam seguros. O comprador precisa de proveniência, verificação, gestão de vulnerabilidades e testes de aceite como controles separados.

Cada atualização de jogo de cassino deve ter um novo SBOM?

Cada versão ou atualização aceita deve ter um SBOM associado ao artefato exato. O fornecedor pode gerá-lo em um pipeline repetível, mas o comprador não deve aceitar um inventário flutuante que não corresponda à compilação entregue.

O que é proveniência de compilação para um jogo de cassino?

Proveniência de compilação é informação verificável sobre a origem de um release, incluindo seus insumos de código-fonte, o processo de compilação e o artefato resultante. Ela ajuda o comprador a detectar uma compilação substituída, antiga ou sem explicação.

Como uma vulnerabilidade do fornecedor deve afetar o aceite do jogo?

O contrato deve definir como vulnerabilidades são relatadas, avaliadas, mitigadas e verificadas novamente, com critérios de gravidade, versões suportadas, responsáveis e exceções. O comprador aplica essas regras ao release exato e ao contexto de implantação.

Evidências de segurança do fornecedor podem substituir a certificação do jogo?

Não. Evidências da cadeia de suprimentos de software e certificação do jogo respondem a perguntas diferentes. Uma mudança pode exigir tanto revisão de segurança quanto os testes ou aprovações da jurisdição para equidade, RNG, regras ou informações obrigatórias ao jogador.