La seguridad de un proveedor de juegos de casino debe aceptarse contra el lanzamiento exacto que entrará en la plataforma de un operador o agregador, no contra un cuestionario reutilizable. Las políticas describen cómo pretende trabajar un estudio. La evidencia del lanzamiento muestra qué se compiló, qué componentes contiene, cómo se produjo, qué cambió y qué riesgos siguen abiertos.
Para un operador, proveedor de RGS, agregador o responsable de compras, el artefacto práctico es un anexo de aseguramiento de lanzamientos del proveedor. Convierte expectativas de seguridad en campos contractuales, evidencias, responsables, pruebas de aceptación y condiciones de parada desde la evaluación del proveedor hasta cada actualización de producción.
Incluya el lanzamiento exacto dentro del límite de aseguramiento
El límite de aseguramiento debe nombrar un artefacto inmutable del juego, su versión, su resumen criptográfico, su entorno objetivo y la evidencia que le pertenece. Una política del proveedor, un resumen de pruebas de penetración o una carta de certificación pueden apoyar la revisión, pero ninguno identifica por sí solo si el archivo entregado hoy es el que se examinó.
Este límite importa en el juego regulado porque la responsabilidad del proveedor no elimina la del operador. La guía de auditoría de seguridad de la UK Gambling Commission indica que una empresa que usa un proveedor B2B con licencia debe obtener términos contractuales, niveles de servicio y declaraciones de aseguramiento, y no debe asumir que la relación la exime de responsabilidad. Los requisitos de seguridad de la Comisión también cubren acuerdos con proveedores, cadenas de suministro TIC, desarrollo seguro, seguridad de aplicaciones, pruebas y gestión de cambios para sistemas de juego relevantes.
Escriba la identidad del artefacto en el registro antes de revisar documentos de apoyo. Exija la misma identidad en la solicitud de despliegue, el SBOM, la declaración de procedencia, la evidencia de pruebas, el registro de cambios y la aprobación. Rechace un paquete cuando esos registros apunten a versiones, ramas u horas de compilación distintas, aunque cada documento parezca completo por separado.
Vincule un SBOM a cada compilación aceptada
Un SBOM debe describir los componentes y las relaciones de dependencia dentro del lanzamiento exacto, incluidas las dependencias transitivas que las herramientas puedan resolver. Los Elementos mínimos de 2025 para un SBOM de CISA señalan que cada versión o actualización debe tener un SBOM asociado y consideran la cobertura de componentes, incluidas dependencias transitivas, parte del valor del inventario.
Contrate un formato legible por máquina, el creador del documento, la hora de creación, nombres y versiones de componentes, identidades de proveedores, relaciones de dependencia e identificadores que ayuden a relacionar componentes con avisos. Exija también el resumen del artefacto u otra referencia inequívoca. El proveedor debe declarar carencias conocidas, como dependencias ocultas por herramientas propietarias, en lugar de presentar cobertura parcial como completa.
Un SBOM es un inventario, no un veredicto. No muestra que una dependencia sea explotable en el contexto desplegado, que no exista ninguna vulnerabilidad ni que la compilación provenga de código revisado. Úselo para el triaje, las decisiones sobre versiones compatibles y las preguntas de incidentes. Mantenga la procedencia y la verificación como controles independientes.
Use la procedencia para demostrar el origen del artefacto
La procedencia de compilación debe conectar el artefacto entregado con sus insumos de código fuente y su proceso de compilación de forma verificable. La especificación SLSA define una vía de compilación para aumentar la confianza en que un artefacto proviene del código y del sistema esperados. Su modelo de procedencia puede adoptarse de forma gradual sin declarar un nivel que el proveedor no haya alcanzado.
Como mínimo, pregunte quién o qué inició la compilación, qué revisión de código y dependencias se usaron, qué constructor aislado la produjo, cuándo se ejecutó y qué resumen identifica el resultado. Prefiera atestaciones firmadas y una verificación independiente. Proteja las claves de firma y las identidades de compilación por separado del acceso ordinario de desarrollo.
El Secure Software Development Framework de NIST ofrece a los compradores un vocabulario común para adquisiciones y conversaciones con proveedores. Incluye proteger componentes, producir lanzamientos bien protegidos y responder a vulnerabilidades residuales. Son prácticas de compra intersectoriales, no aprobaciones de juego. Sirven para hacer inspeccionable el proceso mientras el regulador y el laboratorio aplicables conservan la autoridad sobre las obligaciones del juego.
Contrate la gestión de vulnerabilidades antes de una divulgación
La gestión de vulnerabilidades debe ser una vía operativa con plazos, versiones compatibles, responsables y evidencia definidos antes del primer informe. El anexo debe indicar cómo recibe el proveedor los avisos, confirma componentes afectados, evalúa explotabilidad, comunica cambios materiales, entrega una corrección y demuestra el artefacto sustituto.
No convierta una puntuación pública de gravedad en una decisión automática. Registre componente afectado, comportamiento alcanzable, exposición, controles compensatorios, corrección disponible, responsable de la excepción y fecha de revisión. Un hallazgo puede afectar de forma distinta a una integración de servidor, un cliente web, una canalización de recursos o una herramienta de compilación. El comprador aún necesita una decisión trazable para la versión enviada.
Exija notificación cuando un componente del SBOM quede afectado después del lanzamiento y cuando termine el soporte de una versión. Pruebe la dirección de divulgación y la escalada durante la incorporación. Una política a la que nadie puede llegar no es un control operativo.
Conecte los cambios del proveedor con el impacto de certificación
El control de cambios del proveedor debe llevar los cambios de seguridad y el impacto de certificación por revisiones separadas que vuelven a unirse en la aceptación. El Anexo A sobre actualizaciones mayores y menores de la UK Gambling Commission considera mayor un cambio que pueda afectar la equidad y cita cambios en RNG, escalado, mapeo y reglas como ejemplos que pueden necesitar nuevas pruebas externas.
Un parche de dependencia puede ser relevante para la seguridad sin cambiar el comportamiento del juego. Otra actualización puede tocar la lógica del resultado, la información obligatoria o la recuperación y necesitar ambas revisiones. Registre identificador del cambio, juego y componentes afectados, versiones anterior y posterior, decisión de seguridad, clasificación mayor o menor, alcance de pruebas, aprobaciones e identidad del artefacto. La buena práctica de lanzamiento de la Comisión respalda ese registro disciplinado.
La guía de lanzamientos certificados explica cómo los controles de despliegue siguen subordinados a la clasificación del cambio. El aseguramiento del proveedor añade componentes, procedencia y vulnerabilidades alrededor de la misma compilación inmutable. Ningún control sustituye al otro.
Acepte la evidencia mediante pruebas y no cuestionarios
La aceptación del proveedor debe comprobar que el comprador puede verificar y operar la evidencia, no solo que los archivos existen. Elija un lanzamiento representativo y pase el paquete por compras, seguridad, ingeniería, cumplimiento y operaciones antes de firmar el anexo a largo plazo.
Pruebe al menos estos fallos:
- el SBOM nombra otro artefacto u omite una dependencia transitiva conocida;
- la procedencia apunta a una revisión inesperada o a un constructor no aprobado;
- el proveedor no puede reproducir el resumen desde el proceso aprobado;
- un aviso llega a una dirección desatendida o no tiene responsable;
- un registro de cambios no explica el impacto de certificación;
- la compilación sustituta llega sin evidencia actualizada;
- se solicita el despliegue tras vencer una excepción.
Defina quién acepta una excepción, qué control compensatorio se exige y cuándo se cierra. Conserve la evidencia necesaria para auditoría y respuesta a incidentes según una regla acordada. Evite recoger código fuente, credenciales o datos personales cuando una atestación firmada, un resumen o una prueba acotada responda al control.
Convierta los requisitos en un anexo de lanzamiento
Un anexo de lanzamiento del proveedor debe convertir el paquete de evidencia en un entregable con condiciones objetivas. Adjúntelo a la RFP o al acuerdo y mantenga los mismos campos en el flujo de lanzamiento para que las promesas de compra no desaparezcan tras la integración.
El anexo debe contener:
- nombre, versión, resumen y entorno objetivo del artefacto exacto;
- formato y cobertura del SBOM, identidad de creación y declaración de carencias;
- formato de procedencia, campos de código y constructor, firma y verificador;
- evidencia de desarrollo seguro y pruebas acorde con el riesgo;
- reglas de entrada, notificación, corrección, excepción y fin de soporte;
- registro de cambios, decisión de impacto de certificación y aprobaciones;
- pruebas de aceptación, causas de rechazo, retención y responsables.
Haga que cada elemento tenga versión y sea lo bastante portable para sobrevivir a cambios de personal o herramientas. Un panel puede ayudar, pero el comprador debe poder exportar la evidencia del lanzamiento aceptado. El resultado no afirma que el juego esté libre de riesgo. Es una forma repetible de saber qué entró en producción, por qué se aceptó y cómo se juzgará el siguiente cambio.
Para un título nuevo o un cambio de proveedor, nuestro equipo de desarrollo de juegos puede ayudar a definir el límite, la evidencia de compilación y las pruebas de aceptación junto con la arquitectura. Hable con Wizards sobre la compilación exacta y la entrega de proveedor que necesita encargar.
Preguntas frecuentes
¿Qué evidencia de seguridad debe aportar un proveedor de juegos de casino?
Un proveedor de juegos de casino debe aportar evidencia vinculada al lanzamiento exacto: identidad del artefacto, SBOM con dependencias transitivas, procedencia de la compilación, resultados de pruebas, decisiones sobre vulnerabilidades sin resolver, clasificación de cambios, aprobaciones y una vía de divulgación con soporte.
¿Un SBOM de un juego de casino demuestra que el lanzamiento es seguro?
No. Un SBOM describe componentes y relaciones del software, pero no demuestra que el código fuente, el proceso de compilación, la configuración o el artefacto sean seguros. El comprador necesita procedencia, verificación, gestión de vulnerabilidades y pruebas de aceptación como controles separados.
¿Cada actualización de un juego de casino debe tener un SBOM nuevo?
Cada versión o actualización aceptada debe tener un SBOM asociado a ese artefacto exacto. El proveedor puede generarlo con un proceso repetible, pero el comprador no debe aceptar un inventario flotante que no coincida con la compilación entregada.
¿Qué es la procedencia de compilación de un juego de casino?
La procedencia de compilación es información verificable sobre el origen de un lanzamiento, incluidos sus insumos de código fuente, el proceso de compilación y el artefacto resultante. Ayuda a detectar una compilación sustituida, antigua o sin explicación.
¿Cómo debe afectar una vulnerabilidad del proveedor a la aceptación del juego?
El contrato debe definir cómo se informan, evalúan, mitigan y vuelven a verificar las vulnerabilidades, con criterios de gravedad, versiones compatibles, responsables y excepciones. El comprador aplica esas reglas al lanzamiento exacto y a su contexto de despliegue.
¿La evidencia de seguridad del proveedor puede sustituir la certificación del juego?
No. La evidencia de la cadena de suministro de software y la certificación del juego responden preguntas diferentes. Un cambio puede requerir tanto una revisión de seguridad como las pruebas o aprobaciones de la jurisdicción para la equidad, el RNG, las reglas o la información obligatoria al jugador.
