Abonnement à la plateforme Snyk

Comprendre l’abonnement Snyk Platform

L’abonnement Snyk Platform est une licence basée sur 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éacheté, selon la grille tarifaire et les unités de mesure décrites ci-dessous. Une fois le solde de crédits préacheté épuisé, toute utilisation supplémentaire sera facturée comme consommation à la demande.

Grille tarifaire des crédits

Comment nous calculons « 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 sur l’ensemble des dépôts surveillés par cette fonctionnalité. La consommation commence le jour où la surveillance commence et se termine le lendemain du jour où le dépôt est retiré de la surveillance. Un dépôt surveillé pendant une partie de la journée consomme les crédits d’une journée entière.

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 humains ou non humains. Ils comprennent, par exemple, vos employés, prestataires 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 sur actif et le reste jusqu’à sa désactivation. Un dépôt est comptabilisé 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 sur 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 dans lesquels il apparaît. 

Snyk dérive 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 tous les caractères situés 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é — telles que les alias e-mail standard et les adresses privées sans réponse utilisées par GitHub et GitLab — afin de les regrouper sous un seul nom d’utilisateur. Les exemples ci-dessous montrent comment différents formats d’adresse e-mail sont réduits à un nom d’utilisateur.

Snyk se réserve le droit d’examiner l’activité du compte et les données d’identité des contributeurs lorsqu’elle estime raisonnablement que des manipulations de noms d’utilisateur ou d’autres schémas d’identité sont utilisés pour éviter une mesure exacte des contributeurs actifs.

Deux points importants à retenir :

• Adresses e-mail personnelles : Snyk ne peut pas établir de manière fiable un 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 compté comme un contributeur actif.

• Domaines correspondant à des 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 « par image surveillée et par jour »

La consommation de crédits pour Container est fondé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 la CLI ou l’IDE au cours de cette journée, et qui possède 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, quel que soit le nombre de projets, d’organisations ou de groupes de votre compte qui la référencent, et quel que soit le nombre de fois où elle est analysée ce jour-là.

Une image surveillée consomme des crédits chaque jour où elle est surveillée avec un projet Container ouvert. Un projet Container est ouvert tant qu’il n’a pas été supprimé ou archivé. Toute image surveillée associée à un projet Container ouvert pendant une partie quelconque d’un jour calendaire consomme les crédits d’une journée entière pour ce jour. La consommation s’arrête le lendemain de la suppression ou de l’archivage d’un projet Container. Un projet est archivé lorsque son statut de surveillance est marqué 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 ces images de la surveillance et arrête leur consommation le jour suivant. Les images supprimées restent comptabilisées pour la mesure le jour de leur suppression. Si aucune image unique donnée n’est associée à un projet Container ouvert, elle n’est pas surveillée et aucun crédit n’est consommé pour cette image ce jour-là.

Un test ponctuel effectué via un test non surveillé dans la CLI ne compte pas dans la mesure des images surveillées, puisqu’aucun projet n’est créé. Les analyses de Dockerfile sont distinctes du nombre d’images et ne contribuent pas à la mesure. Un projet dockerfile-scan n’est pas une image surveillée et ne consomme rien selon cette unité de mesure. Les analyses de Dockerfile sont incluses dans un abonnement Snyk Platform Enterprise.

Le condensat SHA-256 d’une image de conteneur constitue la source unique de vérité pour déterminer son unicité lors de la déduplication. Un condensat n’est compté qu’une fois, quel que soit le nombre de balises, dépôts, projets, organisations ou groupes qui le référencent dans le compte. Deux images partageant une balise mais correspondant à des condensats différents sont deux images distinctes. Une balise mutable reconstruite 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 seul ensemble distinct de condensats par jour avant le décompte.

Comment nous calculons « par cible provisionnée et par jour »

La consommation de crédits pour API and Web est fondé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 se termine le lendemain de sa suppression. Toute cible provisionnée pendant une partie de la journée consomme les crédits d’une journée entière.

Chaque URL de base unique définie dans 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 and 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 incluent l’accès à différents types d’analyse :

Comment nous calculons « par machine active et par jour »

La consommation de crédits pour Coding Agent Security est fondée sur le nombre de machines actives observées par Snyk au cours d’une journée. Une machine active est une surface de développement, constituée soit d’un appareil utilisateur final, soit d’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 se produit en son sein 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 un jour donné sur la même machine active, Snyk ne compte cette machine active qu’une seule fois dans sa mesure. Une machine active est facturée une fois par jour, quelle que soit la quantité de télémétrie observée pour l’un ou l’autre des événements admissibles concernant cette machine active 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 comptée comme active et ne consomme aucun crédit pour ce jour. Le statut actif d’une machine est déterminé indépendamment de tout autre jour où elle aurait pu être active auparavant.

Snyk compte deux types différents de machines actives :

1. Appareil utilisateur final - ordinateur portable, ordinateur de bureau ou poste de travail sur lequel le bundle de hooks Snyk est installé par n’importe quel mécanisme de déploiement (y compris, sans s’y limiter, l’inscription MDM, l’installation manuelle ou le 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 utilisateur final en fonction de son identifiant matériel stable et unique au niveau du système d’exploitation. L’identifiant spécifique utilisé par Snyk varie selon la plateforme (IOPlatformUUID sur macOS, SMBIOS / Win32_ComputerSystemProduct.UUID sur Windows, /etc/machine-id sur Linux). Séparément, Snyk compte un environnement virtuel en fonction de l’identifiant unique et stable de la connexion, du nom d’utilisateur ou de l’identifiant principal du propriétaire de la plateforme cloud (selon le cas pour la plateforme), et non de l’instance de l’espace de travail elle-même. Ainsi, un même développeur peut créer plusieurs espaces de travail éphémères au sein de son environnement virtuel (l’identifiant du propriétaire de la plateforme cloud lui-même) au cours d’une même journée et n’être compté que comme une seule machine active. Toutefois, si le même développeur exécute Coding Agent Security localement sur son appareil utilisateur final ainsi que dans son environnement virtuel, Snyk comptabilisera cette activité comme deux unités uniques et indépendantes aux fins de la mesure, soit deux machines actives. En outre, si un même développeur exécutait Coding Agent Security dans plusieurs environnements virtuels différents, soit sur différentes plateformes (par exemple Coder et JetBrains), soit avec plusieurs connexions au sein de la même plateforme, l’activité de ce développeur serait mesurée pour chaque identifiant de connexion unique, et chacun de ces identifiants constituerait une machine active distincte. Snyk mesure le nombre combiné de machines actives sur les appareils utilisateurs finaux et les environnements virtuels afin de déterminer la consommation quotidienne totale de crédits d’un client pour Coding Agent Security.

Comment nous calculons « par évaluation »

La consommation de crédits pour AI Pentesting est fondée sur le nombre d’évaluations terminées. Une évaluation désigne 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 et toute nouvelle analyse post-correction déclenchée dans le cadre de l’évaluation.

Une application est la cible évaluée 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’autorisation, une liste de rejet 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 le test, tels qu’identifiés grâce au graphe d’appels observé au cours de l’exécution. Tous ces microservices sont couverts par le tarif d’une seule évaluation, sans frais distincts par microservice.

Le nouveau test après remédiation est un workflow de suivi dans lequel une vulnérabilité identifiée lors d’une Assessment est corrigée par l’utilisateur, qui peut ensuite demander à l’agent de retester cette même vulnérabilité afin de confirmer sa remédiation. Lors du nouveau test, cette même vulnérabilité est soit confirmée comme étant corrigée, soit considérée comme persistante, auquel cas le workflow de nouveau test peut être répété. Le nouveau test est spécifique aux vulnérabilités d’une Assessment existante, est inclus dans l’événement de facturation initial au tarif « par Assessment » et n’est pas facturé comme un nouvel événement.

Le cycle de vie complet d’une Assessment comprend son lancement par l’utilisateur, la validation de la cible, le test des vulnérabilités, l’analyse des risques et la production du rapport. Une Assessment est terminée uniquement si elle n’est pas annulée par Snyk ou l’utilisateur et n’aboutit pas à un Scan Failure. Seules les Assessments terminées sont comptabilisées dans l’utilisation facturable ; les scans ayant échoué sont exclus de ce décompte.

Un Scan Failure se produit lorsqu’une Assessment lancée n’aboutit pas. Les cas d’échec prévus incluent l’absence d’informations d’identification, une cible inaccessible et le blocage par un WAF. Les Scan Failures ne sont pas facturés.

Chaque Assessment teste une seule Application et ses URL secondaires. Pour les cibles particulièrement complexes nécessitant une profondeur de test spécifique, un rapport terminé peut signaler des chemins d’attaque justifiant des tests plus approfondis et dédiés ; leur analyse constitue une Assessment distincte que le client choisit d’exécuter. Pendant l’étape de test, Snyk applique une limite de raisonnement par jeton équivalente à 2 000 USD. Si une Assessment s’approche de cette limite, l’agent identifie les domaines nécessitant une analyse supplémentaire, les documente dans le rapport et recommande une Assessment de suivi. L’Assessment initiale est néanmoins terminée avec un rapport d’Assessment complet. Le client peut choisir d’analyser les domaines signalés dans le cadre d’une Assessment distincte et facturable.

Limites de test

Les produits Snyk peuvent être soumis à des limites de test, comme indiqué dans une Commande applicable et détaillé sur cette page.

Politique d’utilisation des crédits

Les crédits de la plateforme Snyk (« Crédits ») font partie de l’allocation d’abonnement accordée et de la licence limitée concédée pour les produits et services Snyk. Lorsque le Client utilise des Crédits, Snyk déduit de son solde de Crédits le nombre de Crédits requis pour les services concernés. Les Crédits doivent être utilisés pendant la durée de la Commande applicable ; à l’issue de celle-ci, les Crédits non utilisés expirent et ne peuvent pas être échangés, remboursés ou crédités. 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 tout Crédit consommé au-delà de son allocation de Crédits prépayés, aux taux de consommation des Crédits applicables indiqués dans la Rate Card et au prix par Crédit du Client indiqué dans la Commande applicable.