4 de agosto de 2026
Suscripción a la plataforma de Snyk
Cómo entender la suscripción de Snyk Platform
La suscripción de Snyk Platform es una licencia basada en el consumo para las capacidades de la plataforma Snyk. El uso de estas capacidades consume Créditos de un saldo precomprado, según la Tarjeta de tarifas y las unidades de medida descritas a continuación. Una vez agotado el saldo de Créditos precomprado, cualquier uso posterior se facturará como consumo bajo demanda.
Tarjeta de tarifas de Créditos
Capacidad | Tasa de consumo de Créditos | Unidad de medida |
Código | 1.0 créditos | por Colaborador activo por día |
Código abierto | 1.0 créditos | por Colaborador activo por día |
IaC | 0.33 créditos | por Colaborador activo por día |
Secretos | 0.66 créditos | por Colaborador activo por día |
AI-SPM | 0.66 créditos | por Colaborador activo por día |
Contenedor | 0.33 créditos | por Imagen supervisada por día |
API y Web | 3.0 créditos | por Destino aprovisionado por día |
Seguridad del agente de programación | 1.0 créditos | por Máquina activa por día |
Pentesting con IA | 4,000 créditos | por Evaluación |
Cómo calculamos «por Colaborador activo por día»
El consumo de Créditos de las capacidades de la plataforma medido «por Colaborador activo por día» se determina mediante el recuento diario de Colaboradores activos en todos los repositorios supervisados por esa capacidad. El consumo comienza el día en que empieza la supervisión y termina el día posterior a la eliminación del repositorio de la supervisión. Un repositorio supervisado durante parte de un día consume los Créditos de un día completo.
Un Colaborador activo es cualquier colaborador único que actúe para usted o en su nombre y haya realizado un commit en un repositorio privado supervisado por Snyk durante un período móvil de 90 días. Los Colaboradores activos pueden ser humanos o no humanos. Incluyen, por ejemplo, a sus empleados, contratistas independientes, agentes, bots de terceros, sistemas automatizados y cuentas de servicio. Los bots automatizados propios de Snyk, como <snyk-bot@snyk.io>, no se incluyen en este recuento.
Un repositorio está supervisado por una capacidad cuando se importa a una organización y al menos uno de sus proyectos está activo para esa capacidad. Cuando se crea un proyecto para una capacidad, su estado se establece como activo y permanece activo hasta que se desactiva. Un repositorio cuenta como supervisado aunque no se analice activamente en un día determinado.
Para contar los Colaboradores activos de una capacidad determinada, Snyk identifica a cada colaborador por su nombre de usuario en todos los repositorios supervisados por esa capacidad. Cada nombre de usuario único cuenta como un Colaborador activo, independientemente de en cuántos repositorios supervisados aparezca.
Snyk obtiene un nombre de usuario a partir de la dirección de correo electrónico de un colaborador convirtiéndola a minúsculas, eliminando los espacios adicionales, quitando cualquier subdirección (incluido el signo más y todos los caracteres entre el nombre de usuario analizado y el dominio) y eliminando el dominio. La lógica de deduplicación también reconoce variaciones comunes de una misma identidad, como alias de correo electrónico estándar y las direcciones privadas sin respuesta utilizadas por GitHub y GitLab, para resolverlas en un único nombre de usuario. Los ejemplos siguientes muestran cómo distintos formatos de correo electrónico se reducen a un nombre de usuario.
Snyk se reserva el derecho de revisar la actividad de la cuenta y los datos de identidad de los colaboradores cuando crea razonablemente que se está manipulando el nombre de usuario o utilizando otros patrones de identidad para evitar una medición precisa de los Colaboradores activos.
Dos aspectos importantes:
Direcciones de correo electrónico personales: Snyk no puede vincular de forma fiable una dirección de correo electrónico personal con una corporativa, por lo que un nombre de usuario obtenido de una dirección personal se cuenta como un Colaborador activo.
Dominios de direcciones IP: Una dirección de correo electrónico cuyo dominio es una dirección IP no se reduce a un nombre de usuario; la dirección de correo electrónico completa cuenta como un Colaborador activo.
Situación | Dirección de correo electrónico de ejemplo | Nombre de usuario del Colaborador activo |
|---|---|---|
Dirección de correo electrónico con dominio estándar | john.doe@snyk.io | john.doe |
Dirección de correo electrónico privada de GitHub | 12345678+jane.doe@users.noreply.github.com | 12345678 |
Dirección de correo electrónico privada de GitLab | 12345678+john.doe@users.noreply.gitlab.com | 12345678 |
Alias de correo electrónico (direccionamiento con signo más) | jane.doe+qatest@gmail.com | jane.doe |
Dominio de dirección IP | root@192.0.2.5 | root@192.0.2.5 |
Usuario con dos direcciones de correo electrónico | mike.smith@snyk.io | mike.smith |
Ejemplo ilustrativo:

Cómo calculamos «por Imagen supervisada por día»
El consumo de Créditos de Contenedor se basa en el número de Imágenes supervisadas observadas en un día determinado. Una Imagen supervisada es cualquier imagen de contenedor única importada a Snyk, observada en un registro sincronizado o probada en la CLI o el IDE durante ese día, que tenga un proyecto de Contenedor abierto. Las imágenes de contenedor únicas se identifican mediante sus resúmenes SHA-256. Snyk cuenta cada imagen única una vez al día, independientemente de cuántos proyectos, organizaciones o grupos de su cuenta hagan referencia a ella y de cuántas veces se analice ese día.
Una Imagen supervisada consume créditos cualquier día en que se supervise con un proyecto de Contenedor abierto. Un proyecto de Contenedor está abierto a menos que se haya eliminado o archivado. Cualquier Imagen supervisada que tenga un proyecto de Contenedor abierto durante cualquier parte de un día natural consume los Créditos de un día completo. El consumo se detiene el día posterior a la eliminación o el archivado de un proyecto de Contenedor. Un proyecto se archiva cuando su estado de supervisión se marca como inactivo, lo que pausa inmediatamente los análisis diarios automatizados y las alertas de seguridad. Eliminar o archivar un proyecto de Contenedor, o desincronizar un registro, elimina esas imágenes de la supervisión y detiene su consumo al día siguiente. Las imágenes eliminadas siguen contando para la medición el día en que se eliminan. Si no hay un proyecto de Contenedor abierto asociado con una imagen única determinada, esa imagen no estará supervisada y no consumirá créditos ese día.
Las pruebas puntuales mediante una prueba no supervisada en la CLI no cuentan para la medición de Imágenes supervisadas, ya que no se crea ningún proyecto. Los análisis de Dockerfile son independientes del recuento de imágenes y no contribuyen a la medición. Un proyecto de dockerfile-scan no es una Imagen supervisada y no consume según esta unidad de medida. Los análisis de Dockerfile están incluidos en una suscripción empresarial de Snyk Platform.
El resumen SHA-256 de una imagen de contenedor es la única fuente de verdad para determinar su unicidad en la deduplicación. Un resumen cuenta una vez, independientemente de cuántas etiquetas, repositorios, proyectos, organizaciones o grupos hagan referencia a él dentro de la cuenta. Dos imágenes que comparten una etiqueta pero se resuelven en resúmenes diferentes son dos imágenes distintas. Una etiqueta mutable que se reconstruye con un resumen nuevo crea una nueva Imagen supervisada. La deduplicación se realiza en toda la cuenta. Todos los proyectos de todas las organizaciones y grupos de una cuenta se consolidan en un único conjunto distinto de resúmenes por día antes del recuento.
Cómo calculamos «por Destino aprovisionado por día»
El consumo de Créditos de API y Web se basa en el número de destinos aprovisionados de su cuenta cada día. El consumo comienza el día en que se añade un destino y termina el día posterior a su eliminación. Cualquier destino aprovisionado durante parte de un día consumirá los Créditos de un día completo.
Cada URL base única definida en la plataforma es un destino aprovisionado. Los administradores pueden ver y gestionar los destinos aprovisionados en la sección Targets de la plataforma API y Web.

Cuando se elimina un destino, sus registros se descartan y no se pueden recuperar.
Los destinos aprovisionados incluyen acceso a varios tipos de análisis:
Tipo de análisis | Definición |
Análisis estándar | Una prueba de seguridad integral que intenta cubrir toda la superficie de ataque de la aplicación de destino. Un análisis estándar asigna las páginas accesibles disponibles mediante la URL de destino. |
Análisis de alcance reducido | Una prueba de seguridad específica que se centra en un subconjunto definido de la superficie de ataque de la aplicación. Un análisis de alcance reducido se limita a determinadas URL, rutas o áreas definidas por la configuración del análisis. |
Análisis incremental | Un análisis parcial que analiza únicamente las URL nuevas o actualizadas. Los análisis incrementales requieren un análisis estándar completado como línea base. |
Reanálisis | Un microanálisis que vuelve a analizar una vulnerabilidad para confirmar que se aplicó correctamente una corrección. Los reanálisis analizan un endpoint específico para detectar una vulnerabilidad específica, lo que permite comprobar rápidamente si las correcciones fueron eficaces. |
Cómo calculamos «por Máquina activa por día»
El consumo de Créditos de Seguridad del agente de programación se basa en el número de Máquinas activas observadas por Snyk en un día. Una Máquina activa es una superficie de desarrollo, compuesta por un dispositivo de usuario final o un entorno virtual, que ejecuta agentes de IA. Una máquina está activa en un día determinado si en ella ocurre durante ese día cualquiera de los siguientes eventos de telemetría válidos:
Agent Scan: análisis completado del entorno.
Agent Guard: evento de hook representativo de un agente compatible (hook preToolUse).
Si ambos eventos de telemetría se observan en una misma Máquina activa en un día determinado, Snyk solo cuenta esa Máquina activa una vez en su medición. Una Máquina activa se factura una vez por día, independientemente del volumen de telemetría observado en cualquiera de los eventos válidos de esa Máquina activa durante ese día. Las máquinas solo consumen créditos los días en que están activas. Si transcurre un día completo sin que ocurra ningún evento de telemetría válido en la máquina, esta no se cuenta como activa ni consume créditos ese día. El estado activo de una máquina se determina de forma independiente de cualquier otro día en que haya estado activa anteriormente.
Snyk cuenta dos tipos distintos de Máquinas activas:
Dispositivo de usuario final: un portátil, ordenador de sobremesa o estación de trabajo en el que el paquete de hooks de Snyk está instalado mediante cualquier mecanismo de implementación (incluidos, entre otros, la inscripción en MDM, la instalación manual o el aprovisionamiento mediante scripts); y
Entorno virtual: un espacio de trabajo alojado en la nube basado en contenedores o máquinas virtuales (por ejemplo, GitHub Codespaces, Gitpod/Ona, Coder o JetBrains) con Snyk instalado mediante la plantilla del contenedor de desarrollo, la imagen del espacio de trabajo o un artefacto de aprovisionamiento equivalente.
Snyk cuenta un dispositivo de usuario final basándose en su identificador de hardware único y estable a nivel del sistema operativo. El identificador específico que utiliza Snyk varía según la plataforma (IOPlatformUUID en macOS, SMBIOS / Win32_ComputerSystemProduct.UUID en Windows, /etc/machine-id en Linux). Por separado, Snyk cuenta un entorno virtual mediante el identificador único y estable del inicio de sesión, nombre de usuario o ID de principal del propietario de la plataforma en la nube (según corresponda a la plataforma), no mediante la instancia del espacio de trabajo. Como resultado, un solo desarrollador puede iniciar varios espacios de trabajo efímeros dentro de su entorno virtual (el propio identificador del propietario de la plataforma en la nube) en un solo día y contar como una sola Máquina activa. Sin embargo, si el mismo desarrollador ejecuta Seguridad del agente de programación localmente en su dispositivo de usuario final y también en su entorno virtual, Snyk contará esa actividad como dos unidades únicas e independientes para la medición y, por tanto, como dos Máquinas activas. Además, si un solo desarrollador ejecuta Seguridad del agente de programación en varios entornos virtuales distintos, ya sea en plataformas diferentes (por ejemplo, Coder y JetBrains) o con varios inicios de sesión dentro de la misma plataforma, la actividad de ese desarrollador se medirá por cada identificador de inicio de sesión único, y cada identificador constituirá una Máquina activa independiente. Snyk mide el recuento combinado de máquinas activas de dispositivos de usuario final y entornos virtuales para determinar el consumo total diario de Créditos del cliente para Seguridad del agente de programación.
Cómo calculamos «por Evaluación»
El consumo de Créditos de Pentesting con IA se basa en el número de Evaluaciones completadas. Una Evaluación es una ejecución completa de los agentes de pentesting con IA de Snyk contra una sola Aplicación, incluidos los microservicios relacionados a los que llama esa Aplicación y cualquier reanálisis posterior a la corrección iniciado como parte de la Evaluación.
Una Aplicación es el destino evaluado de una Evaluación. Se define mediante una URL web principal, URL adicionales dentro del alcance, una lista de permitidos, una lista de rechazados y credenciales de usuario. Los microservicios son servicios backend o API adicionales a los que llama la Aplicación y que se utilizan durante las pruebas, según se identifican mediante el grafo de llamadas observado durante la ejecución. Todos estos microservicios están cubiertos por el precio de una sola Evaluación, sin cargos separados por microservicio.
Las nuevas pruebas posteriores a la remediación son un flujo de trabajo de seguimiento en el que el usuario corrige una vulnerabilidad identificada en una Evaluación y, posteriormente, puede pedir al agente que vuelva a probar esa misma vulnerabilidad para confirmar su remediación. Tras la nueva prueba, esa misma vulnerabilidad se confirma como remediada o persiste, en cuyo caso el flujo de trabajo de nuevas pruebas puede repetirse. Las nuevas pruebas son específicas de las vulnerabilidades de una Evaluación existente, se incluyen como parte del evento de facturación original en la tarifa «por Evaluación» y no se facturan como un evento nuevo.
El ciclo de vida completo de una Evaluación incluye el inicio por parte del usuario, la validación del objetivo, las pruebas de vulnerabilidades, el análisis de riesgos y la elaboración del informe. Una Evaluación se considera completa únicamente si Snyk o el usuario no la cancela y no da lugar a un Fallo de escaneo. Solo las Evaluaciones completadas cuentan como uso facturable; los escaneos fallidos se excluyen de ese recuento.
Se produce un Fallo de escaneo cuando una Evaluación iniciada no se completa. Entre los casos de fallo previstos se incluyen la falta de credenciales, un objetivo inaccesible y el bloqueo por parte de un WAF. Los Fallos de escaneo no se cobran.
Cada Evaluación prueba una sola Aplicación y sus URL secundarias. En el caso de objetivos especialmente complejos con una profundidad de prueba única, un informe completado puede señalar rutas de ataque que justifiquen pruebas más exhaustivas y específicas; abordarlas constituye una Evaluación independiente que el cliente decide ejecutar. Durante la fase de pruebas, Snyk aplica un límite de razonamiento de tokens equivalente a 2.000 USD. Si una Evaluación se acerca a este límite, el agente identifica las áreas que requieren análisis adicional, documenta dichas áreas en el informe y recomienda una Evaluación de seguimiento. La Evaluación original se completa igualmente con un informe de Evaluación completo. El cliente puede optar por abordar las áreas señaladas como una Evaluación independiente facturable.
Límites de las pruebas
Los productos de Snyk pueden estar sujetos a límites de pruebas, según se indique en un Pedido aplicable y se detalle más adelante en esta página.
Política de uso de créditos
Los créditos de Snyk Platform («Créditos») forman parte de la asignación de suscripción emitida y de la concesión de licencia limitada para los productos y servicios de Snyk. Cuando el Cliente utiliza Créditos, Snyk deduce del saldo de Créditos del Cliente el número de Créditos requeridos para los servicios aplicables. Los Créditos deben utilizarse durante el plazo del Pedido aplicable; después, los Créditos no utilizados caducarán y no podrán canjearse, reembolsarse ni acreditarse. Los Créditos no son canjeables por dinero en efectivo y no son transferibles. Una vez que el Cliente agote sus Créditos prepagados, Snyk podrá facturar al Cliente los Créditos consumidos por encima de su asignación de Créditos prepagados, aplicando las tarifas de consumo de Créditos correspondientes establecidas en la Tarifa y el precio por Crédito del Cliente establecido en el Pedido aplicable.