Abonnement à la plateforme Snyk

Comprendre l’abonnement à la plateforme Snyk

L’abonnement à la plateforme Snyk est une licence à la consommation pour les fonctionnalités de la plateforme Snyk. L’utilisation de ces fonctionnalités déduit des crédits d’un solde prépayé, selon la grille tarifaire et les unités de mesure décrites ci-dessous. Une fois le solde de crédits prépayés épuisé, toute utilisation supplémentaire est facturée à la consommation.

Grille tarifaire des crédits

Comment nous calculons le tarif « par contributeur actif et par jour »

La consommation de crédits des fonctionnalités de la plateforme mesurées « par contributeur actif et par jour » est déterminée par le nombre quotidien de contributeurs actifs dans l’ensemble des dépôts surveillés par la fonctionnalité concernée. La consommation commence le jour où la surveillance débute et prend fin le lendemain du retrait du dépôt de la surveillance. Un dépôt surveillé pendant une partie de la journée consomme les crédits d’une journée complète.

Un contributeur actif est tout contributeur unique agissant pour vous ou en votre nom qui a effectué un commit dans un dépôt privé surveillé par Snyk au cours d’une période glissante de 90 jours. Les contributeurs actifs peuvent être des personnes ou des entités non humaines. Il peut s’agir, par exemple, de vos employés, sous-traitants indépendants, agents, bots tiers, systèmes automatisés et comptes de service. Les bots automatisés natifs de Snyk, tels que <snyk-bot@snyk.io>, sont exclus de ce décompte.

Un dépôt est surveillé par une fonctionnalité lorsqu’il est importé dans une organisation et qu’au moins l’un de ses projets est actif pour cette fonctionnalité. Lorsqu’un projet est créé pour une fonctionnalité, son statut est défini comme actif et le reste jusqu’à sa désactivation. Un dépôt est considéré comme surveillé même s’il n’est pas activement analysé un jour donné.

Pour compter les contributeurs actifs d’une fonctionnalité donnée, Snyk identifie chaque contributeur par son nom d’utilisateur dans l’ensemble des dépôts surveillés par cette fonctionnalité. Chaque nom d’utilisateur unique compte comme un contributeur actif, quel que soit le nombre de dépôts surveillés où il apparaît. 

Snyk déduit un nom d’utilisateur de l’adresse e-mail d’un contributeur en la convertissant en minuscules, en supprimant les espaces superflus, en supprimant toute sous-adresse (y compris le signe plus et les caractères entre le nom d’utilisateur analysé et le domaine), puis en supprimant le domaine. La logique de déduplication reconnaît également les variantes courantes d’une même identité — comme les alias d’adresse e-mail standard et les adresses privées sans réponse utilisées par GitHub et GitLab — pour les associer à un seul nom d’utilisateur. Les exemples ci-dessous montrent comment différents formats d’adresse e-mail sont ramenés à un nom d’utilisateur.

Snyk se réserve le droit d’examiner l’activité des comptes et les données d’identité des contributeurs lorsqu’il estime raisonnablement que la manipulation des noms d’utilisateur ou d’autres pratiques liées à l’identité servent à fausser le décompte des contributeurs actifs.

Deux points importants :

• Adresses e-mail personnelles : Snyk ne peut pas établir de manière fiable le lien entre une adresse e-mail personnelle et une adresse professionnelle. Un nom d’utilisateur dérivé d’une adresse e-mail personnelle est donc comptabilisé comme contributeur actif.

• Domaines constitués d’adresses IP : une adresse e-mail dont le domaine est une adresse IP n’est pas réduite à un nom d’utilisateur ; l’adresse e-mail complète compte comme un contributeur actif.

Exemple illustratif :

Comment nous calculons le nombre d’images surveillées par jour

La consommation de crédits pour Container est basée sur le nombre d’images surveillées observées un jour donné. Une image surveillée est toute image de conteneur unique importée dans Snyk, observée dans un registre synchronisé ou testée dans l’interface de ligne de commande (CLI) ou l’IDE au cours de cette journée, et associée à un projet Container ouvert. Les images de conteneur uniques sont identifiées par leur condensat SHA-256. Snyk compte chaque image unique une fois par jour, quels que soient le nombre de projets, d’organisations ou de groupes de votre compte qui y font référence, et le nombre d’analyses effectuées ce jour-là.

Une image surveillée consomme des crédits chaque jour où elle est surveillée dans le cadre d’un projet Container ouvert. Un projet Container reste ouvert tant qu’il n’a pas été supprimé ou archivé. Toute image surveillée associée à un projet Container ouvert pendant une partie d’une journée civile consomme les crédits d’une journée complète. La consommation prend fin le lendemain de la suppression ou de l’archivage d’un projet Container. Un projet est archivé lorsque son statut de surveillance est défini comme inactif, ce qui suspend immédiatement les analyses quotidiennes automatisées et les alertes de sécurité. La suppression d’un projet Container, l’archivage d’un projet ou la désynchronisation d’un registre retire les images de la surveillance et met fin à leur consommation le lendemain. Les images retirées restent prises en compte dans le calcul de la consommation le jour de leur retrait. Si aucune image unique n’est associée à un projet Container ouvert, elle n’est pas surveillée et ne consomme aucun crédit ce jour-là.

Les tests ponctuels non surveillés dans la CLI ne sont pas pris en compte dans le calcul des images surveillées, car aucun projet n’est créé. Les analyses de Dockerfile sont distinctes du décompte des images et ne contribuent pas à la consommation. Un projet d’analyse de Dockerfile n’est pas une image surveillée et ne consomme pas de crédits selon cette unité de mesure. Les analyses de Dockerfile sont incluses dans un abonnement à la plateforme Snyk Enterprise.

Le condensat SHA-256 d’une image de conteneur est la référence unique utilisée pour déterminer son caractère distinct lors de la déduplication. Un condensat n’est compté qu’une fois, quels que soient les tags, dépôts, projets, organisations ou groupes du compte qui y font référence. Deux images portant le même tag, mais correspondant à des condensats différents, sont deux images distinctes. Un tag modifiable qui est reconstruit avec un nouveau condensat crée une nouvelle image surveillée. La déduplication s’effectue à l’échelle du compte. Tous les projets de toutes les organisations et de tous les groupes d’un compte sont regroupés en un ensemble unique de condensats distincts par jour avant le décompte.

Comment nous calculons le nombre de cibles provisionnées par jour

La consommation de crédits pour API et Web est basée sur le nombre de cibles provisionnées dans votre compte chaque jour. La consommation commence le jour où une cible est ajoutée et prend fin le lendemain de son retrait. Toute cible provisionnée pendant une partie de la journée consomme les crédits d’une journée complète.

Chaque URL de base unique définie sur la plateforme constitue une cible provisionnée. Les administrateurs peuvent consulter et gérer les cibles provisionnées dans la section Targets de la plateforme API et Web.

Lorsqu’une cible est supprimée, ses enregistrements sont supprimés et ne peuvent pas être récupérés.

Les cibles provisionnées donnent accès à différents types d’analyses :

Comment nous calculons le nombre de machines actives par jour

La consommation de crédits pour Coding Agent Security est basée sur le nombre de machines actives observées par Snyk au cours d’une journée. Une machine active est un environnement de développement, comprenant un appareil d’utilisateur final ou un environnement virtuel, qui exécute des agents d’IA. Une machine est active un jour donné si l’un des événements de télémétrie admissibles suivants s’y produit au cours de cette journée :

1. Agent Scan : analyse de l’environnement terminée.

2. Agent Guard : événement de hook représentatif provenant d’un agent pris en charge (hook preToolUse).

Si les deux événements de télémétrie sont observés le même jour sur une même machine active, Snyk ne compte cette machine active qu’une seule fois. Une machine active est facturée une fois par jour, quelle que soit la quantité de données de télémétrie observées pour l’un ou l’autre de ces événements admissibles sur cette machine ce jour-là. Les machines ne consomment des crédits que les jours où elles sont actives. Si une journée entière s’écoule sans qu’aucun événement de télémétrie admissible ne se produise sur la machine, celle-ci n’est pas considérée comme active et ne consomme aucun crédit ce jour-là. Le statut actif d’une machine est déterminé indépendamment des autres jours où elle a pu être active.

Snyk compte deux types de machines actives :

1. Appareil d’utilisateur final : ordinateur portable, ordinateur de bureau ou poste de travail sur lequel le bundle de hooks Snyk est installé par n’importe quel moyen de déploiement (notamment via une inscription MDM, une installation manuelle ou un provisionnement par script) ; et

2. Environnement virtuel : espace de travail hébergé dans le cloud, basé sur un conteneur ou une machine virtuelle (par exemple, GitHub Codespaces, Gitpod/Ona, Coder, JetBrains), sur lequel Snyk est installé via le modèle de conteneur de développement, l’image de l’espace de travail ou un artefact de provisionnement équivalent.

Snyk compte un appareil d’utilisateur final en fonction de son identifiant matériel unique et stable au niveau du système d’exploitation. L’identifiant utilisé par Snyk varie selon la plateforme (IOPlatformUUID sur macOS, SMBIOS / Win32_ComputerSystemProduct.UUID sur Windows, /etc/machine-id sur Linux). En revanche, Snyk compte un environnement virtuel à partir de l’identifiant unique et stable du compte de connexion, du nom d’utilisateur ou de l’identifiant du principal du propriétaire de la plateforme cloud (selon la plateforme), et non de l’instance de l’espace de travail elle-même. Ainsi, un développeur peut lancer plusieurs espaces de travail éphémères dans son environnement virtuel (identifié par l’identifiant du propriétaire de la plateforme cloud) au cours d’une même journée et ne compter que comme une seule machine active. Cependant, si le même développeur utilise Coding Agent Security localement sur son appareil d’utilisateur final et dans son environnement virtuel, Snyk comptabilise cette activité comme deux unités distinctes et indépendantes, soit deux machines actives. De plus, si un développeur utilise Coding Agent Security dans plusieurs environnements virtuels différents, que ce soit sur différentes plateformes (par exemple, Coder et JetBrains) ou avec plusieurs comptes de connexion sur une même plateforme, son activité est comptabilisée pour chaque identifiant de connexion unique, chacun constituant une machine active distincte. Snyk additionne le nombre de machines actives sur les appareils d’utilisateur final et dans les environnements virtuels pour déterminer la consommation quotidienne totale de crédits d’un client pour Coding Agent Security.

Comment nous calculons le nombre d’évaluations

La consommation de crédits pour AI Pentesting est basée sur le nombre d’évaluations terminées. Une évaluation correspond à une exécution complète des agents de pentest IA de Snyk sur une seule application, y compris les microservices associés appelés par cette application ainsi que toute nouvelle analyse après correction déclenchée dans le cadre de l’évaluation.

Une application est la cible évaluée dans le cadre d’une évaluation. Elle est définie par une URL Web principale, des URL supplémentaires incluses dans le périmètre, une liste d’autorisations, une liste de refus et des identifiants utilisateur. Les microservices sont des services backend ou des API supplémentaires appelés par l’application et exécutés pendant les tests, comme l’indique le graphe d’appels observé lors de l’exécution. Tous ces microservices sont couverts par le prix d’une seule évaluation ; aucun frais distinct n’est appliqué par microservice.

Le nouveau test après correction est une étape de suivi au cours de laquelle l’utilisateur corrige une vulnérabilité détectée lors d’une évaluation, puis peut demander à l’agent de tester à nouveau cette même vulnérabilité afin de confirmer qu’elle a bien été corrigée. À l’issue du nouveau test, la correction de la vulnérabilité est confirmée ou celle-ci persiste. Dans ce dernier cas, le processus de nouveau test peut être répété. Le nouveau test porte uniquement sur les vulnérabilités d’une évaluation existante. Il est inclus dans la facturation initiale au tarif « par évaluation » et n’est pas facturé comme un nouvel événement.

Le cycle de vie complet d’une évaluation comprend son lancement par l’utilisateur, la validation de la cible, le test des vulnérabilités, l’analyse des risques et la production d’un rapport. Une évaluation est considérée comme terminée uniquement si elle n’est annulée ni par Snyk ni par l’utilisateur et ne donne pas lieu à un échec d’analyse. Seules les évaluations terminées sont prises en compte dans l’utilisation facturable ; les analyses ayant échoué en sont exclues.

Une analyse échoue lorsqu’une évaluation lancée n’aboutit pas. Les causes d’échec prévisibles comprennent l’absence d’identifiants, une cible inaccessible et le blocage par un WAF. Les analyses ayant échoué ne sont pas facturées.

Chaque évaluation teste une seule application et ses URL secondaires. Pour les cibles particulièrement complexes nécessitant une profondeur de test spécifique, un rapport final peut signaler des chemins d’attaque justifiant des tests plus approfondis et dédiés. Leur analyse constitue une évaluation distincte, que le client choisit de lancer. Pendant la phase de test, Snyk applique une limite de raisonnement par jetons équivalente à 2 000 USD. Si une évaluation approche de cette limite, l’agent repère les points nécessitant une analyse supplémentaire, les consigne dans le rapport et recommande une évaluation de suivi. L’évaluation initiale est néanmoins menée à terme et donne lieu à un rapport complet. Le client peut choisir d’examiner les points signalés dans le cadre d’une évaluation distincte et facturable.

Limites de test

Les produits Snyk peuvent être soumis à des limites de test, comme indiqué dans le bon de commande applicable et précisé plus en détail sur cette page.

Politique d’utilisation des crédits

Les crédits de la plateforme Snyk (« Crédits ») font partie du quota d’abonnement accordé et de la licence limitée d’utilisation des produits et services Snyk. Lorsque le client utilise des Crédits, Snyk déduit de son solde le nombre de Crédits requis pour les services concernés. Les Crédits doivent être utilisés pendant la durée du bon de commande applicable. À l’issue de cette période, les Crédits non utilisés expirent et ne peuvent être échangés, remboursés ni portés au crédit du client. Les Crédits ne sont pas échangeables contre des espèces et ne sont pas transférables. Lorsque le client a épuisé ses Crédits prépayés, Snyk peut lui facturer les Crédits consommés au-delà de son quota prépayé, aux tarifs de consommation des Crédits indiqués dans la grille tarifaire et au prix par Crédit du client indiqué dans le bon de commande applicable.