Assinatura da plataforma Snyk

Entenda a assinatura da plataforma Snyk

A assinatura da plataforma Snyk é uma licença baseada no consumo dos recursos da plataforma Snyk. O uso desses recursos consome créditos de um saldo pré-comprado, de acordo com a tabela de tarifas e as unidades de medida descritas abaixo. Quando o saldo de créditos pré-comprados se esgotar, qualquer uso adicional será cobrado como consumo sob demanda.

Tabela de tarifas de créditos

Como calculamos "por colaborador ativo por dia"

O consumo de créditos dos recursos da plataforma medidos “por colaborador ativo por dia” é determinado pela contagem diária de colaboradores ativos em todos os repositórios monitorados pelo respectivo recurso. O consumo começa no dia em que o monitoramento é iniciado e termina no dia seguinte à remoção do repositório do monitoramento. Um repositório monitorado por parte de um dia consome os créditos de um dia inteiro.

Um colaborador ativo é qualquer colaborador único que atue por você ou em seu nome e tenha feito um commit em um repositório privado monitorado pela Snyk durante um período móvel de 90 dias. Colaboradores ativos podem ser pessoas ou não. Por exemplo, podem incluir seus funcionários, prestadores de serviço independentes, agentes, bots de terceiros, sistemas automatizados e contas de serviço. Bots automatizados nativos da Snyk, como <snyk-bot@snyk.io>, não entram nessa contagem.

Um repositório é monitorado por um recurso quando é importado para uma organização e pelo menos um de seus projetos está ativo para esse recurso. Quando um projeto é criado para um recurso, seu status é definido como ativo e permanece assim até ser desativado. Um repositório é considerado monitorado mesmo que não seja verificado ativamente em determinado dia.

Para contar os colaboradores ativos de um determinado recurso, a Snyk identifica cada colaborador pelo nome de usuário em todos os repositórios monitorados por esse recurso. Cada nome de usuário único conta como um colaborador ativo, independentemente de aparecer em quantos repositórios monitorados for. 

A Snyk deriva o nome de usuário do endereço de e-mail do colaborador: converte-o para letras minúsculas, remove espaços extras, descarta qualquer subendereço (incluindo o sinal de mais e os caracteres entre o nome de usuário identificado e o domínio) e remove o domínio. A lógica de deduplicação também reconhece variações comuns da mesma identidade — como aliases de e-mail convencionais e endereços privados de não resposta usados pelo GitHub e pelo GitLab — para associá-las a um único nome de usuário. Os exemplos abaixo mostram como diferentes formatos de e-mail são convertidos em um nome de usuário.

A Snyk se reserva o direito de analisar a atividade da conta e os dados de identidade dos colaboradores quando houver motivos razoáveis para acreditar que a manipulação de nomes de usuário ou outros padrões de identidade estejam sendo usados para evitar uma medição precisa de colaboradores ativos.

Dois pontos importantes:

• Endereços de e-mail pessoais: a Snyk não consegue vincular de forma confiável um endereço de e-mail pessoal a um corporativo. Por isso, um nome de usuário derivado de um endereço de e-mail pessoal é contado como colaborador ativo.

• Domínios com endereço IP: um endereço de e-mail cujo domínio seja um endereço IP não é convertido em nome de usuário; o endereço de e-mail completo conta como um colaborador ativo.

Exemplo ilustrativo:

Como calculamos "por imagem monitorada por dia"

O consumo de créditos do Container é baseado no número de imagens monitoradas identificadas em determinado dia. Uma imagem monitorada é qualquer imagem de contêiner única importada para a Snyk, identificada em um registro sincronizado ou testada na CLI ou no IDE durante esse dia, que tenha um projeto Container aberto. As imagens de contêiner únicas são identificadas por seus resumos SHA-256. A Snyk conta cada imagem única uma vez por dia, independentemente de quantos projetos, organizações ou grupos da sua conta façam referência a ela e de quantas vezes ela seja verificada nesse dia.

Uma imagem monitorada consome créditos em qualquer dia em que estiver sendo monitorada com um projeto Container aberto. Um projeto Container permanece aberto, a menos que seja excluído ou arquivado. Qualquer imagem monitorada associada a um projeto Container aberto durante qualquer parte de um dia do calendário consome os créditos de um dia inteiro. O consumo termina no dia seguinte à exclusão ou ao arquivamento do projeto Container. Um projeto é arquivado quando seu status de monitoramento é marcado como inativo, o que pausa imediatamente as verificações diárias automatizadas e os alertas de segurança. Excluir ou arquivar um projeto, ou cancelar a sincronização de um registro, remove essas imagens do monitoramento e interrompe o consumo no dia seguinte. As imagens removidas ainda contam para a medição no dia em que são removidas. Se não houver um projeto Container aberto associado a uma determinada imagem única, ela não será monitorada e não consumirá créditos nesse dia.

Testes pontuais não monitorados na CLI não entram na medição de imagens monitoradas, pois nenhum projeto é criado. As verificações de Dockerfile são contabilizadas separadamente do número de imagens e não contribuem para a medição. Um projeto de verificação de Dockerfile não é uma imagem monitorada e não consome créditos nessa unidade de medida. As verificações de Dockerfile estão incluídas em uma assinatura empresarial da plataforma Snyk.

O resumo SHA-256 de uma imagem de contêiner é a única fonte de verdade para determinar sua exclusividade na deduplicação. Um resumo conta uma vez, independentemente de quantas tags, repositórios, projetos, organizações ou grupos da conta façam referência a ele. Duas imagens com a mesma tag, mas com resumos diferentes, são imagens distintas. Uma tag mutável recriada com um novo resumo gera uma nova imagem monitorada. A deduplicação é feita em toda a conta. Antes da contagem, todos os projetos de todas as organizações e grupos da conta são consolidados em um conjunto de resumos distintos por dia.

Como calculamos "por alvo provisionado por dia"

O consumo de créditos de API e Web é baseado no número de alvos provisionados na sua conta a cada dia. O consumo começa no dia em que um alvo é adicionado e termina no dia seguinte à sua remoção. Qualquer alvo provisionado durante parte de um dia consome os créditos de um dia inteiro.

Cada URL base única definida na plataforma é um alvo provisionado. Os administradores podem consultar e gerenciar os alvos provisionados na seção Targets da plataforma API e Web.

Quando um alvo é excluído, seus registros são descartados e não podem ser recuperados.

Os alvos provisionados incluem acesso a vários tipos de verificação:

Como calculamos "por máquina ativa por dia"

O consumo de créditos da Segurança de agentes de programação é baseado no número de máquinas ativas identificadas pela Snyk em um dia. Uma máquina ativa é um ambiente de desenvolvimento, composto por um dispositivo de usuário final ou um ambiente virtual, que executa agentes de IA. Uma máquina é considerada ativa em determinado dia se ocorrer nela, durante esse dia, qualquer um dos seguintes eventos de telemetria qualificadores:

1. Verificação de agente: verificação concluída do ambiente.

2. Proteção de agente: evento de hook representativo de um agente compatível (hook preToolUse).

Se os dois eventos de telemetria forem identificados na mesma máquina ativa em determinado dia, a Snyk contará essa máquina ativa apenas uma vez na medição. Uma máquina ativa é cobrada uma vez por dia, independentemente do volume de telemetria registrado nos eventos qualificadores associados a ela nesse dia. As máquinas só consomem créditos nos dias em que estão ativas. Se passar um dia inteiro sem que ocorra na máquina nenhum evento de telemetria qualificador, ela não será considerada ativa e não consumirá créditos nesse dia. O status de atividade da máquina é determinado de forma independente dos outros dias em que ela possa ter estado ativa.

A Snyk conta dois tipos diferentes de máquinas ativas:

1. Dispositivo de usuário final — notebook, computador de mesa ou estação de trabalho em que o pacote de hooks da Snyk está instalado por qualquer mecanismo de implantação (incluindo, entre outros, inscrição em MDM, instalação manual ou provisionamento por script); e

2. Ambiente virtual — espaço de trabalho hospedado na nuvem, baseado em contêiner ou máquina virtual (por exemplo, GitHub Codespaces, Gitpod/Ona, Coder, JetBrains), com a Snyk instalada por meio do modelo de contêiner de desenvolvimento, da imagem do espaço de trabalho ou de um artefato de provisionamento equivalente.

A Snyk conta um dispositivo de usuário final com base em seu identificador de hardware exclusivo e estável no nível do sistema operacional. O identificador específico usado pela Snyk varia conforme a plataforma (IOPlatformUUID no macOS, SMBIOS / Win32_ComputerSystemProduct.UUID no Windows, /etc/machine-id no Linux). Já um ambiente virtual é contado com base no identificador exclusivo e estável do login, nome de usuário ou ID do principal do proprietário da plataforma de nuvem (conforme aplicável à plataforma), e não da instância do espaço de trabalho. Assim, um único desenvolvedor pode iniciar vários espaços de trabalho efêmeros em seu ambiente virtual (identificado pelo próprio identificador do proprietário na plataforma de nuvem) em um único dia e ainda contar como uma única máquina ativa. No entanto, se o mesmo desenvolvedor executar a Segurança de agentes de programação localmente no dispositivo de usuário final e também no ambiente virtual, a Snyk contará essa atividade como duas unidades de medição exclusivas e independentes, ou seja, duas máquinas ativas. Além disso, se um único desenvolvedor executar a Segurança de agentes de programação em vários ambientes virtuais diferentes, seja em plataformas diferentes (por exemplo, Coder e JetBrains) ou com vários logins na mesma plataforma, a atividade será medida por identificador de login exclusivo, e cada identificador corresponderá a uma máquina ativa separada. A Snyk mede o total combinado de máquinas ativas em dispositivos de usuário final e ambientes virtuais para determinar o consumo diário total de créditos do cliente com a Segurança de agentes de programação.

Como calculamos "por avaliação"

O consumo de créditos do Pentest com IA é baseado no número de avaliações concluídas. Uma avaliação é uma execução completa dos agentes de pentest com IA da Snyk em um único aplicativo, incluindo os microsserviços relacionados chamados por esse aplicativo e qualquer novo teste após a correção iniciado como parte da avaliação.

Um aplicativo é o alvo avaliado em uma avaliação. Ele é definido por uma URL web principal, URLs adicionais dentro do escopo, uma lista de permissões, uma lista de rejeição e credenciais de usuário. Microsserviços são serviços de back-end ou APIs adicionais chamados pelo aplicativo e exercitados durante os testes, conforme identificados pelo grafo de chamadas observado durante a execução. Todos esses microsserviços estão cobertos pelo preço de uma única avaliação, sem cobrança separada por microsserviço.

O novo teste após a correção é um fluxo de trabalho subsequente no qual uma vulnerabilidade identificada em uma Avaliação é corrigida pelo usuário, que pode então solicitar ao agente que teste novamente essa mesma vulnerabilidade para confirmar a correção. Após o novo teste, confirma-se que a vulnerabilidade foi corrigida ou ela persiste; nesse caso, o fluxo de novo teste pode ser repetido. O novo teste se aplica especificamente a vulnerabilidades de uma Avaliação existente, está incluído no evento de cobrança original pela tarifa “por Avaliação” e não é cobrado como um novo evento.

O ciclo de vida completo de uma Avaliação inclui a iniciação pelo usuário, a validação do alvo, o teste de vulnerabilidades, a análise de riscos e a geração do relatório. Uma Avaliação só é considerada concluída se não for cancelada pela Snyk ou pelo usuário e não resultar em uma Falha na verificação. Somente Avaliações concluídas são contabilizadas como uso cobrável; verificações malsucedidas não entram nessa contagem.

Uma Falha na verificação ocorre quando uma tentativa de Avaliação não é concluída. Entre as causas esperadas estão credenciais ausentes, um alvo inacessível e o bloqueio pelo WAF. Falhas na verificação não são cobradas.

Cada Avaliação testa uma única Aplicação e suas URLs secundárias. Para alvos especialmente complexos, que exigem uma profundidade de teste específica, um relatório concluído pode indicar caminhos de ataque que justifiquem testes mais aprofundados e dedicados. A investigação desses caminhos é uma Avaliação separada, que o cliente escolhe executar. Durante a etapa de teste, a Snyk aplica um limite de raciocínio de tokens equivalente a US$ 2.000. Se uma Avaliação se aproximar desse limite, o agente identifica as áreas que exigem análise adicional, documenta essas áreas no relatório e recomenda uma Avaliação de acompanhamento. A Avaliação original ainda é concluída com um relatório completo. O cliente pode optar por investigar as áreas indicadas em uma Avaliação separada, sujeita a cobrança.

Limites de teste

Os produtos da Snyk podem estar sujeitos a limites de teste, conforme especificado em um Pedido aplicável e detalhado nesta página.

Política de uso de créditos

Os Créditos da Plataforma Snyk (“Créditos”) fazem parte da alocação de assinatura concedida e da licença limitada para uso dos produtos e serviços da Snyk. Quando o Cliente usa Créditos, a Snyk deduz do saldo de Créditos do Cliente a quantidade necessária para os serviços aplicáveis. Os Créditos devem ser usados durante a vigência do Pedido aplicável. Após esse período, quaisquer Créditos não utilizados expiram e não podem ser resgatados, reembolsados nem convertidos em crédito. Os Créditos não podem ser resgatados em dinheiro nem transferidos. Quando os Créditos pré-pagos do Cliente se esgotarem, a Snyk poderá faturar ao Cliente quaisquer Créditos consumidos além da alocação pré-paga, de acordo com as tarifas de consumo de Créditos aplicáveis estabelecidas na Tabela de preços e com o preço por Crédito do Cliente definido no Pedido aplicável.