Importante
Esta página se ha traducido mediante inteligencia artificial. El contenido puede contener imprecisiones o interpretaciones erróneas. Para un uso crítico u oficial, consulte la versión EN.
4 de agosto de 2026
Esta página se ha traducido mediante inteligencia artificial. El contenido puede contener imprecisiones o interpretaciones erróneas. Para un uso crítico u oficial, consulte la versión EN.
La suscripción a la plataforma Snyk es una licencia basada en el consumo de las capacidades de la plataforma Snyk. El uso de estas capacidades descuenta créditos de un saldo prepagado, según la tarifa y las unidades de medida que se describen a continuación. Una vez agotado el saldo de créditos prepagado, todo uso adicional se facturará como consumo a pedido.
Capacidad | Tarifa de consumo de créditos | Unidad de medida |
Code | 1.0 créditos | por colaborador activo al día |
Open Source | 1.0 créditos | por colaborador activo al día |
IaC | 0.33 créditos | por colaborador activo al día |
Secrets | 0.66 créditos | por colaborador activo al día |
AI-SPM | 0.66 créditos | por colaborador activo al día |
Container | 0.33 créditos | por imagen monitoreada al día |
API y Web | 3.0 créditos | por objetivo aprovisionado al día |
Seguridad de agentes de programación | 1.0 créditos | por máquina activa al día |
Pruebas de penetración con IA | 4,000 créditos | por evaluación |
El consumo de créditos de las capacidades de la plataforma cuya unidad de medida es «por colaborador activo al día» se determina según el recuento diario de colaboradores activos en todos los repositorios monitoreados por esa capacidad. El consumo comienza el día en que se inicia el monitoreo y termina el día después de que el repositorio deja de monitorearse. Un repositorio monitoreado durante una parte del día consume los créditos de un día completo.
Un colaborador activo es cualquier colaborador único que actúe por ti o en tu nombre y haya realizado un commit en un repositorio privado monitoreado por Snyk durante un período móvil de 90 días. Los colaboradores activos pueden ser humanos o no humanos. Por ejemplo, pueden incluir a tus 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.
Una capacidad monitorea un repositorio cuando este 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 así hasta que se desactiva. Un repositorio cuenta como monitoreado incluso si no se analiza activamente en un día determinado.
Para contar los colaboradores activos de una capacidad, Snyk identifica a cada colaborador por su nombre de usuario en todos los repositorios monitoreados por esa capacidad. Cada nombre de usuario único cuenta como un colaborador activo, sin importar en cuántos repositorios monitoreados aparezca.
Snyk obtiene el nombre de usuario 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 los caracteres que haya 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 los alias de correo electrónico habituales y las direcciones privadas de no responder que usan GitHub y GitLab— para unificarlas en un solo nombre de usuario. Los ejemplos a continuación muestran cómo distintos formatos de correo electrónico se convierten en 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 tenga motivos razonables para creer que se manipulan los nombres de usuario u otros patrones de identidad para evitar una medición precisa de los colaboradores activos.
Dos puntos importantes:
Direcciones de correo electrónico personales: Snyk no puede vincular de manera confiable una dirección de correo electrónico personal con una corporativa, por lo que un nombre de usuario obtenido de una dirección personal cuenta como colaborador activo.
Dominios con dirección IP: Una dirección de correo electrónico cuyo dominio sea una dirección IP no se convierte en un nombre de usuario; la dirección de correo electrónico completa cuenta como un colaborador activo.
Escenario | Ejemplo de dirección de correo electrónico | 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 (direcciones con el signo más) | jane.doe+qatest@gmail.com | jane.doe |
Dominio con 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 |

El consumo de créditos de Container se basa en la cantidad de imágenes monitoreadas que se observan en un día determinado. Una imagen monitoreada es cualquier imagen de contenedor única que se haya importado a Snyk, observado en un registro sincronizado o probado en la CLI o el IDE durante ese día, y que tenga un proyecto de Container 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, sin importar cuántos proyectos, organizaciones o grupos de tu cuenta hagan referencia a ella ni cuántas veces se analice ese día.
Una imagen monitoreada consume créditos cualquier día que se monitoree con un proyecto de Container abierto. Un proyecto de Container permanece abierto a menos que se elimine o archive. Toda imagen monitoreada que tenga un proyecto de Container abierto durante cualquier parte de un día calendario consume créditos por un día completo. El consumo se detiene el día después de que se elimina o archiva un proyecto de Container. Un proyecto se archiva cuando su estado de monitoreo se marca como inactivo, lo que pausa de inmediato los análisis diarios automatizados y las alertas de seguridad. Al eliminar un proyecto de Container, archivar un proyecto o desincronizar un registro, esas imágenes dejan de monitorearse y su consumo se detiene al día siguiente. Las imágenes eliminadas siguen contando para la medición del día en que se eliminan. Si no hay ningún proyecto de Container abierto asociado a una imagen única determinada, esa imagen no se monitoreará y no consumirá créditos ese día.
Las pruebas únicas mediante CLI no monitoreada no cuentan para la medición de imágenes monitoreadas, ya que no se crea ningún proyecto. Los análisis de Dockerfile se contabilizan por separado del recuento de imágenes y no contribuyen a la medición. Un proyecto de análisis de Dockerfile no es una imagen monitoreada y no consume créditos según esta unidad de medida. Los análisis de Dockerfile están incluidos en una suscripción empresarial a la plataforma Snyk.
El resumen SHA-256 de una imagen de contenedor es la única fuente de verdad para determinar si es única durante la deduplicación. Un resumen cuenta una vez, sin importar cuántas etiquetas, repositorios, proyectos, organizaciones o grupos hagan referencia a él dentro de la cuenta. Dos imágenes que comparten una etiqueta, pero corresponden a resúmenes diferentes, son imágenes distintas. Una etiqueta mutable que se reconstruye con un resumen nuevo crea una nueva imagen monitoreada. La deduplicación se aplica a toda la cuenta. Antes del recuento, todos los proyectos de todas las organizaciones y grupos de una cuenta se consolidan en un único conjunto de resúmenes distintos por día.
El consumo de créditos de API y Web se basa en la cantidad de objetivos aprovisionados en tu cuenta cada día. El consumo comienza el día en que se agrega un objetivo y termina el día después de que se elimina. Todo objetivo aprovisionado durante una parte del día consume los créditos de un día completo.
Cada URL base única definida en la plataforma es un objetivo aprovisionado. Los administradores pueden ver y administrar los objetivos aprovisionados en la sección Targets de la plataforma API y Web.

Cuando se elimina un objetivo, sus registros se descartan y no se pueden recuperar.
Los objetivos aprovisionados incluyen acceso a varios tipos de análisis:
Tipo de análisis | Definición |
Análisis estándar | Una prueba de seguridad exhaustiva que intenta cubrir toda la superficie de ataque de la aplicación objetivo. Un análisis estándar mapea las páginas accesibles a través de la URL objetivo. |
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 en 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 referencia. |
Reanálisis | Un microanálisis que vuelve a probar una vulnerabilidad para confirmar que se aplicó correctamente una solución. Los reanálisis examinan un endpoint específico en busca de una vulnerabilidad concreta, para que puedas comprobar rápidamente si las correcciones fueron efectivas. |
El consumo de créditos de Coding Agent Security se basa en la cantidad de máquinas activas que Snyk observa en un día. Una máquina activa es un entorno de desarrollo —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 ocurre en ella alguno de los siguientes eventos de telemetría válidos durante ese día:
Análisis de agente: análisis completado del entorno.
Agent Guard: evento de hook representativo de un agente compatible (hook preToolUse).
Si se observan ambos eventos de telemetría en una misma máquina activa durante un día determinado, Snyk solo cuenta esa máquina activa una vez para la medición. Una máquina activa se factura una vez al día, sin importar cuántos datos de telemetría se observen en los eventos válidos correspondientes a esa máquina activa durante ese día. Las máquinas solo consumen créditos los días 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 considera activa y no consume créditos ese día. El estado activo de una máquina se determina de manera independiente de otros días en los que haya podido estar activa anteriormente.
Snyk cuenta dos tipos distintos de máquinas activas:
Dispositivo de usuario final: una laptop, computadora de escritorio o estación de trabajo en la que se instala el paquete de hooks de Snyk 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, JetBrains), con Snyk instalado mediante la plantilla del contenedor de desarrollo, la imagen del espacio de trabajo u otro artefacto de aprovisionamiento equivalente.
Snyk cuenta un dispositivo de usuario final según su identificador de hardware único y estable a nivel de sistema operativo. El identificador específico que usa 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 según el identificador único y estable de 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), y no según la instancia del espacio de trabajo. Como resultado, un mismo desarrollador puede crear varios espacios de trabajo efímeros dentro de su entorno virtual (identificado por el 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 usa Coding Agent Security tanto de forma local en su dispositivo de usuario final como en su entorno virtual, Snyk contabilizará esa actividad como dos unidades de medición únicas e independientes y, por lo tanto, como dos máquinas activas. Además, si un desarrollador usa Coding Agent Security en varios entornos virtuales distintos, ya sea en plataformas diferentes (por ejemplo, Coder y JetBrains) o con varios inicios de sesión en una misma plataforma, la actividad se medirá según cada identificador de inicio de sesión único y cada uno de esos identificadores contará como una máquina activa independiente. Snyk mide el total combinado de máquinas activas en dispositivos de usuario final y entornos virtuales para determinar el consumo total diario de créditos de un cliente para Coding Agent Security.
El consumo de créditos de las pruebas de penetración con IA se basa en la cantidad de evaluaciones completadas. Una evaluación es una ejecución completa de los agentes de pruebas de penetración con IA de Snyk en una sola aplicación, incluidos los microservicios relacionados a los que llama esa aplicación y cualquier reanálisis posterior a la corrección que se inicie como parte de la evaluación.
Una aplicación es el objetivo que se evalúa. Se define mediante una URL web principal, URL adicionales incluidas en el alcance, una lista de permitidos, una lista de rechazados y credenciales de usuario. Los microservicios son servicios de backend o API adicionales a los que llama la aplicación y que se ejercitan durante las pruebas, según el grafo de llamadas observado durante la ejecución. Todos esos microservicios están cubiertos por el precio de una sola evaluación, sin cargos adicionales por microservicio.
La repetición de pruebas posterior a la remediación es un flujo de trabajo de seguimiento en el que el usuario corrige una vulnerabilidad identificada en una Evaluación y luego puede pedirle al agente que vuelva a probar esa misma vulnerabilidad para confirmar que se haya corregido. Al repetir la prueba, se confirma que la vulnerabilidad se corrigió o bien esta persiste; en ese caso, el flujo de trabajo de repetición de pruebas puede volver a ejecutarse. La repetición de pruebas se aplica específicamente a vulnerabilidades de una Evaluación existente, está incluida como parte del evento de facturación original a la tarifa «por Evaluación» y no se factura como un evento nuevo.
El ciclo de vida completo de una Evaluación incluye su 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 solo se considera completa si Snyk o el usuario no la cancelan y no se produce un Fallo de escaneo. Solo las Evaluaciones completadas se contabilizan como uso facturable; los escaneos fallidos no se incluyen en ese cómputo.
Se produce un Fallo de escaneo cuando una Evaluación intentada no se completa. Algunos casos previstos de fallo incluyen credenciales faltantes, 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 que requieren una profundidad de prueba particular, un informe completado puede señalar rutas de ataque que ameriten pruebas más exhaustivas y específicas; explorarlas implica una Evaluación independiente que el cliente decide ejecutar. Durante la etapa de pruebas, Snyk aplica un límite de razonamiento de tokens equivalente a USD 2,000. Si una Evaluación se acerca a este límite, el agente identifica las áreas que requieren análisis adicional, las documenta en el informe y recomienda una Evaluación de seguimiento. La Evaluación original se completa de todas formas con un informe completo. El cliente puede decidir explorar las áreas señaladas mediante una Evaluación independiente facturable.
Los productos de Snyk pueden estar sujetos a límites de pruebas, según lo establecido en la Orden correspondiente y descrito con más detalle en esta página.
Los Créditos de la plataforma Snyk («Créditos») forman parte de la asignación de suscripción emitida y de la licencia limitada para usar los productos y servicios de Snyk. Cuando el Cliente usa Créditos, Snyk deduce del saldo de Créditos del Cliente la cantidad necesaria para los servicios correspondientes. Los Créditos deben usarse durante la vigencia de la Orden correspondiente. Una vez finalizada, los Créditos no utilizados vencerán y no podrán canjearse, reembolsarse ni acreditarse. Los Créditos no se pueden canjear por efectivo ni transferir. Cuando el Cliente agote sus Créditos prepagados, Snyk podrá facturarle los Créditos que haya consumido por encima de su asignación de Créditos prepagados, según las tarifas de consumo de Créditos establecidas en la Lista de precios y el precio por Crédito del Cliente establecido en la Orden correspondiente.