Assinatura da plataforma Snyk

Entendendo 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é-adquirido, com base na Tabela de Tarifas e nas unidades de medida descritas abaixo. Quando o saldo de Créditos pré-adquiridos se esgotar, qualquer uso adicional será faturado 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 por esse recurso. O consumo começa no dia em que o monitoramento começa e termina no dia seguinte à remoção do repositório do monitoramento. Um repositório monitorado durante parte de um dia consome os Créditos de um dia inteiro.

Um Colaborador Ativo é qualquer colaborador único que atue para 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 humanos ou não humanos. Eles incluem, por exemplo, seus funcionários, prestadores de serviços independentes, agentes, bots de terceiros, sistemas automatizados e contas de serviço. Bots automatizados nativos da Snyk, como <snyk-bot@snyk.io>, são excluídos dessa 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 ativo até ser desativado. Um repositório é considerado monitorado mesmo que não seja verificado ativamente em um 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 em quantos repositórios monitorados ele apareça. 

A Snyk deriva um nome de usuário do endereço de e-mail de um colaborador convertendo-o para minúsculas, removendo espaços extras, eliminando qualquer subendereço (incluindo o sinal de mais e todos os caracteres entre o nome de usuário analisado e o domínio) e removendo o domínio. A lógica de deduplicação também reconhece variações comuns da mesma identidade — como aliases de e-mail padrão e os endereços privados sem resposta usados pelo GitHub e pelo GitLab — para resolvê-las em um único nome de usuário. Os exemplos abaixo mostram como diferentes formatos de e-mail são reduzidos a 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 acreditar razoavelmente que manipulações 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; portanto, um nome de usuário derivado de um endereço de e-mail pessoal é contado como um Colaborador Ativo.

• Domínios de endereço IP: um endereço de e-mail cujo domínio seja um endereço IP não é reduzido a um 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 Contêiner baseia-se no número de Imagens Monitoradas observadas em um determinado dia. Uma Imagem Monitorada é qualquer imagem de contêiner única importada para a Snyk, observada em um registro sincronizado ou testada na CLI ou IDE durante esse dia, que tenha um projeto de Contêiner 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 em 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 seja monitorada com um projeto de Contêiner aberto. Um projeto de Contêiner permanece aberto a menos que seja excluído ou arquivado. Qualquer Imagem Monitorada que tenha um projeto de Contêiner aberto durante qualquer parte de um dia do calendário consome os Créditos de um dia inteiro nesse dia. O consumo para no dia seguinte à exclusão ou ao arquivamento de um projeto de Contêiner. 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 um projeto de Contêiner, arquivar um projeto ou cancelar a sincronização de um registro remove essas imagens do monitoramento e interrompe seu 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 de Contêiner aberto associado a uma determinada imagem única, essa imagem não será monitorada e nenhum Crédito será consumido por ela nesse dia.

Testes únicos realizados por meio de um teste não monitorado na CLI não contam para a medição de Imagens Monitoradas, pois nenhum projeto é criado. As verificações de Dockerfile são independentes da contagem de imagens e não contribuem para a medição. Um projeto de dockerfile-scan 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 sua exclusividade na deduplicação. Um resumo conta uma vez, independentemente de quantas tags, repositórios, projetos, organizações ou grupos façam referência a ele dentro da conta. Duas imagens que compartilham uma tag, mas são resolvidas em resumos diferentes, são duas imagens distintas. Uma tag mutável reconstruída para um novo resumo cria uma nova Imagem Monitorada. A deduplicação abrange toda a conta. Todos os projetos em todas as organizações e grupos de uma conta são consolidados em um único conjunto distinto de resumos por dia antes da contagem.

Como calculamos "por Alvo Provisionado por Dia"

O consumo de Créditos da API e Web baseia-se no número de alvos provisionados em 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 consumirá os Créditos de um dia inteiro.

Cada URL base única definida na plataforma é um alvo provisionado. Os administradores podem visualizar e gerenciar 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 do Coding Agent baseia-se no número de Máquinas Ativas observadas pela Snyk em um dia. Uma Máquina Ativa é uma superfície de desenvolvedor, composta por um dispositivo de usuário final ou ambiente virtual, que executa agentes de IA. Uma máquina está ativa em um determinado dia se qualquer um dos seguintes eventos de telemetria qualificadores ocorrer nela durante esse dia:

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

2. Agent Guard: evento de hook representativo de um agente compatível (hook preToolUse).

Se ambos os eventos de telemetria forem observados em uma mesma Máquina Ativa em um determinado dia, a Snyk contará essa Máquina Ativa apenas uma vez em sua medição. Uma Máquina Ativa é faturada uma vez por dia, independentemente da quantidade de telemetria observada em qualquer um dos eventos qualificadores para essa Máquina Ativa nesse dia. As máquinas só consomem Créditos nos dias em que estão ativas. Se transcorrer um dia inteiro sem que ocorra nenhum evento de telemetria qualificador na máquina, ela não será contada como ativa e não consumirá Créditos nesse dia. O status ativo de uma máquina é determinado independentemente de quaisquer outros dias em que ela possa ter estado ativa anteriormente.

A Snyk conta dois tipos diferentes de Máquinas Ativas:

1. Dispositivo de usuário final - um laptop, desktop ou estação de trabalho no qual o pacote de hooks da Snyk esteja instalado por qualquer mecanismo de implantação (incluindo, sem limitação, registro em MDM, instalação manual ou provisionamento por script); e

2. Ambiente virtual - um espaço de trabalho hospedado na nuvem baseado em contêiner ou VM (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 estável e exclusivo 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). Separadamente, a Snyk conta um ambiente virtual pelo identificador exclusivo e estável do login, nome de usuário ou ID principal do proprietário da plataforma de nuvem (conforme aplicável à plataforma), e não pela própria instância do espaço de trabalho. Como resultado, um único desenvolvedor pode iniciar vários espaços de trabalho efêmeros em seu ambiente virtual (o próprio identificador do proprietário da plataforma de nuvem) em um único dia e contar como apenas uma Máquina Ativa. No entanto, se o mesmo desenvolvedor executar a Segurança do Coding Agent localmente em seu dispositivo de usuário final e também em seu ambiente virtual, a Snyk contará essa atividade como duas unidades exclusivas e independentes para fins de medição e, portanto, como duas Máquinas Ativas. Além disso, se um único desenvolvedor executar a Segurança do Coding Agent em vários ambientes virtuais diferentes, seja em plataformas diferentes (por exemplo, Coder e JetBrains) ou em vários logins dentro da mesma plataforma, a atividade desse desenvolvedor será medida por cada identificador de login exclusivo, e cada um desses identificadores constituirá uma Máquina Ativa separada. A Snyk mede a contagem combinada de máquinas ativas em dispositivos de usuário final e ambientes virtuais para determinar o consumo diário total de Créditos de um cliente para a Segurança do Coding Agent.

Como calculamos "por Avaliação"

O consumo de Créditos do Pentest com IA baseia-se no número de Avaliações concluídas. Uma Avaliação significa 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 nova verificação pós-correção acionada como parte da Avaliação.

Um Aplicativo é o alvo avaliado de uma Avaliação. Ele é definido por uma URL web principal, URLs adicionais dentro do escopo, uma lista de permissões, uma lista de rejeições e credenciais de usuário. Microsserviços são serviços de backend ou APIs adicionais chamados pelo Aplicativo e exercitados durante o teste, 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 pós-remediaçã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 sua remediação. Após o novo teste, essa mesma vulnerabilidade é confirmada como remediada ou persiste; nesse caso, o fluxo de trabalho de novo teste pode ser repetido. O novo teste é específico para vulnerabilidades de uma Avaliação existente, está incluído como parte do evento de cobrança original na tarifa “por Avaliação” e não é cobrado como um novo evento.

Um 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 produção do relatório. Uma Avaliação só é concluída se não for cancelada pela Snyk ou pelo usuário e não resultar em uma Falha de Verificação. Somente Avaliações concluídas contam como uso faturável; verificações malsucedidas são excluídas dessa contagem.

Uma Falha de Verificação ocorre quando uma Avaliação iniciada não é concluída. Os casos de falha esperados incluem credenciais ausentes, um alvo inacessível e bloqueio pelo WAF. Falhas de Verificação não são cobradas.

Cada Avaliação testa uma única Aplicação e seus URLs secundários. Para alvos especialmente complexos, com uma profundidade de teste diferenciada, um relatório concluído pode sinalizar caminhos de ataque que justifiquem testes mais aprofundados e dedicados; prosseguir com esses testes corresponde a uma Avaliação separada que o cliente opta por 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 identificará as áreas que exigem análise adicional, documentará essas áreas no relatório e recomendará uma Avaliação de acompanhamento. A Avaliação original ainda será concluída com um relatório completo da Avaliação. O cliente poderá optar por investigar as áreas sinalizadas como uma Avaliação faturável separada.

Limites de Teste

Os produtos da Snyk podem estar sujeitos a limites de teste, conforme indicado em um Pedido aplicável e detalhado adicionalmente 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 emitida e da concessão de licença limitada para produtos e serviços da Snyk. Quando o Cliente usa Créditos, a Snyk deduz do saldo de Créditos do Cliente o número de Créditos necessários 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 expirarão e não poderão ser resgatados, reembolsados ou creditados. Os Créditos não podem ser convertidos em dinheiro e não são transferíveis. Quando o Cliente esgotar seus Créditos pré-pagos, a Snyk poderá faturar o Cliente por quaisquer Créditos consumidos além da alocação de Créditos pré-pagos do Cliente, às taxas de consumo de Créditos aplicáveis estabelecidas na Tabela de Preços e ao preço por Crédito do Cliente estabelecido no Pedido aplicável.