Snyk Platform Subscription

Understanding the Snyk Platform Subscription

The Snyk Platform Subscription is a consumption-based license for Snyk platform capabilities. Use of these capabilities draws down Credits from a pre-purchased balance, based on the Rate Card and the units of measure described below. Once the pre-purchased Credit balance is exhausted, any further use will be invoiced as on-demand consumption.

Credits Rate Card

How We Calculate "per Active Contributor per Day"

Credit consumption for platform capabilities measured “per Active Contributor per Day” is determined by the daily count of Active Contributors across all repositories monitored by that capability. Consumption begins on the day monitoring begins and ends the day after the repository is removed from monitoring. A repository monitored for part of a day consumes a full day's Credits.

An Active Contributor is any unique contributor acting for or on your behalf who has made a commit to a private, Snyk-monitored repository during a rolling 90-day period. Active Contributors may be human or non-human. They include, for example, your employees, independent contractors, agents, third-party bots, automated systems, and service accounts. Snyk-native automated bots, such as <snyk-bot@snyk.io>, are excluded from this count.

A repository is monitored by a capability when it is imported into an organization and at least one of its projects is active for that capability. When a project is created for a capability, its status is set to active and remains active until it is deactivated. A repository counts as monitored even if it is not actively scanned on a given day.

To count Active Contributors for a given capability, Snyk identifies each contributor by username across all repositories monitored by that capability. Each unique username counts as one Active Contributor, no matter how many monitored repositories it appears in. 

Snyk derives a username from a contributor's email address by lowercasing it, trimming extra spaces, dropping any subaddress (including the plus sign as well as any characters between the parsed username and domain), and removing the domain. The deduplication logic also recognizes common variations of the same identity — such as standard email aliases and the private no-reply addresses used by GitHub and GitLab — to resolve them to a single username. The examples below show how different email formats reduce to a username.

Snyk reserves the right to review account activity and contributor identity data where it reasonably believes username manipulation or other identity patterns are being used to avoid accurate Active Contributor measurement.

Two important callouts:

• Personal email addresses: Snyk cannot reliably link a personal email address to a corporate one, so a username derived from a personal email address is counted as an Active Contributor.

• IP address domains: An email address whose domain is an IP address is not reduced to a username; the full email address counts as one Active Contributor.

Illustrative Example:

How We Calculate "per Monitored Image per Day"

Credit consumption for Container is based on the number of Monitored Images observed on a given day. A Monitored Image is any unique container image imported to Snyk, observed in a synced registry, or tested in the CLI or IDE during that day, that has an open Container project. Unique container images are identified by their SHA-256 digests. Snyk counts each unique image once per day, regardless of how many projects, organizations, or groups in your account reference it, and regardless of how many times it is scanned that day.

A Monitored Image consumes credits on any day it is monitored with an open Container project. A Container project is open unless it has been deleted or archived. Any Monitored Image that has an open Container project for any portion of a calendar day consumes a full day’s credits for that day. Consumption stops the day after a Container project is deleted or archived. A project is archived when its monitoring status is flagged as inactive, which immediately pauses automated daily scans and security alerts. Deleting a Container project, archiving a project or de-syncing a registry removes those images from monitoring and stops their consumption the following day. Removed images still count toward metering on the day they are removed. If there is no open Container project associated with a given unique image, then that image would be unmonitored and no credits would be consumed for it that day.

One-time testing via unmonitored test in CLI does not count toward Monitored Image metering since there is no project created. Dockerfile scans are separate from image count and do not contribute to metering. A dockerfile-scan project is not a Monitored Image and does not consume on this unit of measure. Dockerfile scans are included in an enterprise Snyk platform subscription.

A container image’s SHA-256 digest is the single source of truth for its uniqueness in de-duplication. A digest counts once no matter how many tags, repositories, projects, organizations, or groups reference it within the account. Two images sharing a tag but resolving to different digests are two distinct images. A mutable tag that is rebuilt to a new digest creates a new Monitored Image. De-duplication is account-wide. All projects across all organizations and groups under an account collapse to one distinct set of digests per day before counting.

How We Calculate "per Provisioned Target per Day"

Credit consumption for API and Web is based on the number of provisioned targets in your account each day. Consumption begins on the day a target is added and ends the day after it is removed. Any target provisioned for part of a day will consume a full day’s credits.

Each unique base URL defined in the platform is a provisioned target. Admins can view and manage provisioned targets in the Targets section of the API and Web platform.

When a target is deleted, its records are discarded and cannot be recovered.

Provisioned targets include access to various scan types:

How We Calculate "per Active Machine per Day"

Credit consumption for Coding Agent Security is based on the number of Active Machines observed by Snyk in a day. An Active Machine  is a developer surface, comprising either an end user device or virtual environment, that runs AI agents. A machine is active on a given day if any of the following qualifying telemetry events occur within it during that day:

1. Agent Scan: Completed scan of the environment.

2. Agent Guard: Representative hook event from a supported agent (preToolUse hook).

If both telemetry events are observed on a given day in the same Active Machine, Snyk only counts that Active Machine once in its metering. An Active Machine is billed once for a day regardless of how much telemetry is observed across either qualifying events for that Active Machine on that day. Machines only consume credits on days they are active. If a full day elapses where no qualifying telemetry event occurs on the machine, then it is not counted as active and consumes no credits for that day. A machine’s active status is determined independently of any other days where it may previously have been active.

Snyk counts two different types of Active Machines:

1. End User Device - A laptop, desktop or workstation on which the Snyk hook bundle is installed via any deployment mechanism (including, without limitation, MDM enrollment, manual installation, or scripted provisioning); and

2. Virtual Environment - A container-based or VM-based cloud-hosted workspace (e.g., GitHub Codespaces, Gitpod/Ona, Coder, JetBrains) with Snyk installed via the dev container template, workspace image, or equivalent provisioning artifact.

Snyk counts an end user device based on its stable and unique OS-level hardware identifier. The specific identifier Snyk uses varies by platform (IOPlatformUUID on macOS, SMBIOS / Win32_ComputerSystemProduct.UUID on Windows, /etc/machine-id on Linux). Separately, Snyk counts a virtual environment by the unique and stable identifier of the cloud platform owner login, username,or principal ID (as applicable to the platform), not the workspace instance itself. As a result, a single developer can spin up multiple ephemeral workspaces within their virtual environment (the cloud platform owner identifier itself) in a single day and count as only one Active Machine. However, if the same developer is running Coding Agent Security locally on their end user device as well as on their virtual environment, Snyk would count that activity as two unique and independent units for metering, and thus two Active Machines. Further, if a single developer were to run Coding Agent Security across multiple different virtual environments, either across different platforms (e.g. Coder and JetBrains) or across multiple logins within the same platform, that developer’s activity would be metered per each unique login identifier and each such identifier would constitute a separate Active Machine.. Snyk meters the combined count of active machines across both end user devices and virtual environments to determine a customer’s total daily credit consumption for Coding Agent Security.

How We Calculate "per Assessment"

Credit consumption for AI Pentesting is based on the number of completed Assessments. An Assessment means a complete run of Snyk's AI pentesting agents against a single Application, including related microservices called by that Application and any post-remediation retesting triggered as part of the Assessment.

An Application is the evaluated target of an Assessment. It is defined by a primary web URL, additional in-scope URLs, an allowed list, a reject list, and user credentials. Microservices are additional backend services or APIs that the Application calls and that are exercised during testing, as identified through the call graph observed during the run. All such microservices are covered under the single Assessment price, with no separate charge per microservice.

Post-remediation retesting is a follow-on workflow in which a vulnerability identified in an Assessment is fixed by the user, who may then prompt the agent to retest that same vulnerability to confirm its remediation. Upon retest, that same vulnerability is either confirmed as remediated, or it persists, in which case the retesting workflow can be repeated. Retesting is specific to vulnerabilities of an existing Assessment, is included as part of the original billing event in the ‘per Assessment’ rate and is not billed as a new event.

A complete Assessment lifecycle includes user initiation, target validation, vulnerability testing, risk analysis, and report production. An Assessment is complete only if it is not cancelled by Snyk or the user and does not result in a Scan Failure. Only completed Assessments count as billable usage; failed scans are excluded from that count.

A Scan Failure occurs when an attempted Assessment does not complete. Expected cases of failure include missing credentials, an unreachable target, and WAF blocking. Scan Failures are not charged.

Each Assessment tests a single Application and its secondary URLs. For especially complex targets with unique testing depth, a completed report may flag attack paths that merit deeper, dedicated testing; pursuing these is a separate Assessment that the customer chooses to run. During the testing stage, Snyk applies a token reasoning limit equivalent to $2,000 USD. If an Assessment approaches this limit, the agent identifies areas that require additional analysis, documents those areas in the report, and recommends a follow-up Assessment. The original Assessment still completes with a full Assessment report. The customer may choose to pursue the flagged areas as a separate billable Assessment.

Test Limits

Snyk products may be subject to test limits, as stated in an applicable Order and further detailed on this page.

Credit Usage Policy

Snyk Platform Credits (“Credits”) are a part of the issued subscription allocation and limited license grant to Snyk products and services. When Customer uses Credits, Snyk deducts the number of Credits required for the applicable services from Customer's Credit balance. Credits must be used within the term of the applicable Order, after which any unused Credits will expire and cannot be redeemed, refunded, or credited. Credits are not redeemable for cash and are non-transferable. Upon Customer's exhaustion of its prepaid Credits, Snyk may invoice Customer for any Credits consumed in excess of Customer’s prepaid Credit allocation at the applicable Credit consumption rates set out in the  Rate Card and Customer’s per-Credit price set out in the applicable Order.