Snyk-Plattform-Abonnement

Das Snyk-Plattform-Abonnement verstehen

Das Snyk-Plattform-Abonnement ist eine nutzungsbasierte Lizenz für Funktionen der Snyk-Plattform. Bei der Nutzung dieser Funktionen werden Credits von einem im Voraus erworbenen Guthaben abgezogen. Maßgeblich sind dabei die Preisliste und die nachfolgend beschriebenen Maßeinheiten. Sobald das im Voraus erworbene Credit-Guthaben aufgebraucht ist, wird jede weitere Nutzung als bedarfsbasierte Nutzung abgerechnet.

Preisliste für Credits

So berechnen wir „pro aktivem Contributor und Tag“

Der Credit-Verbrauch für Plattformfunktionen, die „pro aktivem Contributor und Tag“ gemessen werden, richtet sich nach der täglichen Anzahl aktiver Contributors in allen Repositories, die von der jeweiligen Funktion überwacht werden. Der Verbrauch beginnt an dem Tag, an dem die Überwachung startet, und endet am Tag nach dem Entfernen des Repositorys aus der Überwachung. Wird ein Repository nur einen Teil des Tages überwacht, wird ein ganzer Tagesverbrauch an Credits berechnet.

Ein aktiver Contributor ist ein eindeutiger Contributor, der für Sie oder in Ihrem Auftrag tätig ist und innerhalb eines rollierenden Zeitraums von 90 Tagen einen Commit zu einem privaten, von Snyk überwachten Repository beigetragen hat. Aktive Contributors können Menschen oder nicht-menschliche Akteure sein. Dazu zählen beispielsweise Ihre Mitarbeitenden, unabhängige Auftragnehmer, Agents, Bots von Drittanbietern, automatisierte Systeme und Servicekonten. Snyk-eigene automatisierte Bots wie <snyk-bot@snyk.io> werden bei dieser Zählung nicht berücksichtigt.

Ein Repository wird von einer Funktion überwacht, wenn es in eine Organisation importiert wurde und mindestens eines seiner Projekte für diese Funktion aktiv ist. Beim Erstellen eines Projekts für eine Funktion wird dessen Status auf „aktiv“ gesetzt und bleibt so, bis es deaktiviert wird. Ein Repository gilt auch dann als überwacht, wenn es an einem bestimmten Tag nicht aktiv gescannt wird.

Um die aktiven Contributors für eine bestimmte Funktion zu zählen, identifiziert Snyk jeden Contributor anhand des Benutzernamens über alle Repositories hinweg, die von dieser Funktion überwacht werden. Jeder eindeutige Benutzername zählt als ein aktiver Contributor, unabhängig davon, in wie vielen überwachten Repositories er vorkommt. 

Snyk leitet den Benutzernamen aus der E-Mail-Adresse eines Contributors ab, indem die Adresse in Kleinbuchstaben umgewandelt, überflüssige Leerzeichen entfernt, jede Subadresse (einschließlich des Pluszeichens und aller Zeichen zwischen dem ermittelten Benutzernamen und der Domain) abgeschnitten und die Domain entfernt wird. Die Deduplizierungslogik erkennt außerdem gängige Varianten derselben Identität – etwa übliche E-Mail-Aliase und die privaten No-Reply-Adressen von GitHub und GitLab – und ordnet sie einem einzigen Benutzernamen zu. Die folgenden Beispiele zeigen, wie unterschiedliche E-Mail-Formate auf einen Benutzernamen zurückgeführt werden.

Snyk behält sich das Recht vor, Kontoaktivitäten und Contributor-Identitätsdaten zu überprüfen, wenn begründeter Anlass zu der Annahme besteht, dass Benutzernamen manipuliert oder andere Identitätsmuster verwendet werden, um eine korrekte Erfassung aktiver Contributors zu umgehen.

Zwei wichtige Hinweise:

• Persönliche E-Mail-Adressen: Snyk kann eine persönliche E-Mail-Adresse nicht zuverlässig einer geschäftlichen Adresse zuordnen. Daher wird ein aus einer persönlichen E-Mail-Adresse abgeleiteter Benutzername als aktiver Contributor gezählt.

• IP-Adress-Domains: Bei einer E-Mail-Adresse, deren Domain eine IP-Adresse ist, wird die Adresse nicht auf einen Benutzernamen verkürzt. Die vollständige E-Mail-Adresse zählt als ein aktiver Contributor.

Veranschaulichendes Beispiel:

So berechnen wir „pro überwachtem Image und Tag“

Der Credit-Verbrauch für Container richtet sich nach der Anzahl der überwachten Images, die an einem bestimmten Tag erfasst werden. Ein überwachtes Image ist jedes eindeutige Container-Image, das an diesem Tag in Snyk importiert, in einer synchronisierten Registry erfasst oder in der CLI oder IDE getestet wird und für das ein offenes Container-Projekt besteht. Eindeutige Container-Images werden anhand ihrer SHA-256-Digests identifiziert. Snyk zählt jedes eindeutige Image einmal pro Tag – unabhängig davon, auf wie viele Projekte, Organisationen oder Gruppen in Ihrem Konto es verweist und wie oft es an diesem Tag gescannt wird.

Ein überwachtes Image verbraucht an jedem Tag Credits, an dem es mit einem offenen Container-Projekt überwacht wird. Ein Container-Projekt ist offen, solange es nicht gelöscht oder archiviert wurde. Jedes überwachte Image, für das auch nur einen Teil eines Kalendertags ein offenes Container-Projekt besteht, verbraucht an diesem Tag die Credits für einen ganzen Tag. Der Verbrauch endet am Tag nach dem Löschen oder Archivieren eines Container-Projekts. Ein Projekt wird archiviert, wenn sein Überwachungsstatus als inaktiv gekennzeichnet wird; dadurch werden automatisierte tägliche Scans und Sicherheitswarnungen sofort pausiert. Das Löschen oder Archivieren eines Projekts oder das Aufheben der Synchronisierung einer Registry entfernt die zugehörigen Images aus der Überwachung und beendet den Verbrauch am Folgetag. Entfernte Images zählen am Tag ihrer Entfernung weiterhin für die Abrechnung. Gibt es für ein eindeutiges Image kein offenes Container-Projekt, wird das Image nicht überwacht und verbraucht an diesem Tag keine Credits.

Ein einmaliger Test über einen nicht überwachten Test in der CLI wird nicht auf die Abrechnung über überwachte Images angerechnet, da dabei kein Projekt erstellt wird. Dockerfile-Scans werden getrennt von der Image-Anzahl erfasst und tragen nicht zum Verbrauch bei. Ein Dockerfile-Scan-Projekt ist kein überwachtes Image und verbraucht in dieser Maßeinheit keine Credits. Dockerfile-Scans sind in einem Snyk-Plattform-Abonnement für Unternehmen enthalten.

Der SHA-256-Digest eines Container-Images ist bei der Deduplizierung die maßgebliche Quelle für dessen Eindeutigkeit. Ein Digest wird unabhängig davon, auf wie viele Tags, Repositories, Projekte, Organisationen oder Gruppen er innerhalb des Kontos verweist, einmal gezählt. Zwei Images mit demselben Tag, aber unterschiedlichen Digests sind zwei verschiedene Images. Wird ein veränderlicher Tag mit einem neuen Digest neu erstellt, entsteht ein neues überwachtes Image. Die Deduplizierung erfolgt kontoweit. Vor der Zählung werden alle Projekte in sämtlichen Organisationen und Gruppen eines Kontos pro Tag zu einer einzigen Menge eindeutiger Digests zusammengefasst.

So berechnen wir „pro bereitgestelltem Ziel und Tag“

Der Credit-Verbrauch für API und Web richtet sich nach der täglichen Anzahl bereitgestellter Ziele in Ihrem Konto. Der Verbrauch beginnt an dem Tag, an dem ein Ziel hinzugefügt wird, und endet am Tag nach seiner Entfernung. Jedes Ziel, das auch nur einen Teil des Tages bereitgestellt ist, verbraucht die Credits für einen ganzen Tag.

Jede eindeutige Basis-URL, die in der Plattform definiert ist, gilt als bereitgestelltes Ziel. Admins können bereitgestellte Ziele im Abschnitt „Targets“ der API- und Web-Plattform anzeigen und verwalten.

Wird ein Ziel gelöscht, werden seine Datensätze verworfen und können nicht wiederhergestellt werden.

Bereitgestellte Ziele umfassen den Zugriff auf verschiedene Scan-Typen:

So berechnen wir „pro aktivem Rechner und Tag“

Der Credit-Verbrauch für Coding Agent Security richtet sich nach der Anzahl der aktiven Rechner, die Snyk an einem Tag erfasst. Ein aktiver Rechner ist eine Entwicklerumgebung, bestehend aus einem Endgerät oder einer virtuellen Umgebung, auf der AI-Agents ausgeführt werden. Ein Rechner gilt an einem bestimmten Tag als aktiv, wenn innerhalb dieses Tages eines der folgenden qualifizierenden Telemetrieereignisse auftritt:

1. Agent Scan: Abgeschlossener Scan der Umgebung.

2. Agent Guard: Repräsentatives Hook-Ereignis eines unterstützten Agents (preToolUse-Hook).

Werden beide Telemetrieereignisse an einem bestimmten Tag auf demselben aktiven Rechner erfasst, zählt Snyk diesen aktiven Rechner bei der Abrechnung nur einmal. Ein aktiver Rechner wird unabhängig davon, wie viele Telemetriedaten zu den qualifizierenden Ereignissen an diesem Tag erfasst werden, einmal pro Tag abgerechnet. Rechner verbrauchen nur an Tagen, an denen sie aktiv sind, Credits. Verstreicht ein ganzer Tag ohne qualifizierendes Telemetrieereignis auf dem Rechner, gilt er nicht als aktiv und verbraucht an diesem Tag keine Credits. Der Aktivitätsstatus eines Rechners wird unabhängig davon bestimmt, ob er an anderen Tagen zuvor aktiv war.

Snyk zählt zwei verschiedene Arten aktiver Rechner:

1. Endgerät – Ein Laptop, Desktop-Computer oder eine Workstation, auf dem bzw. der das Snyk-Hook-Bundle über einen beliebigen Bereitstellungsmechanismus installiert ist (einschließlich, aber nicht beschränkt auf MDM-Registrierung, manuelle Installation oder skriptgesteuerte Bereitstellung); und

2. Virtuelle Umgebung – Ein cloudgehosteter, container- oder VM-basierter Arbeitsbereich (z. B. GitHub Codespaces, Gitpod/Ona, Coder, JetBrains), auf dem Snyk über die Dev-Container-Vorlage, das Workspace-Image oder ein gleichwertiges Bereitstellungsartefakt installiert ist.

Snyk zählt ein Endgerät anhand seiner stabilen, eindeutigen Hardwarekennung auf Betriebssystemebene. Die verwendete Kennung variiert je nach Plattform (IOPlatformUUID unter macOS, SMBIOS / Win32_ComputerSystemProduct.UUID unter Windows, /etc/machine-id unter Linux). Eine virtuelle Umgebung zählt Snyk separat anhand der eindeutigen und stabilen Kennung des Logins, Benutzernamens oder der Principal-ID des Cloud-Plattforminhabers (je nach Plattform) – nicht anhand der Workspace-Instanz selbst. Daher kann ein einzelner Entwickler innerhalb eines Tages mehrere kurzlebige Workspaces in seiner virtuellen Umgebung (definiert durch die Kennung des Cloud-Plattforminhabers) starten und trotzdem nur als ein aktiver Rechner zählen. Wenn derselbe Entwickler Coding Agent Security sowohl lokal auf seinem Endgerät als auch in seiner virtuellen Umgebung ausführt, zählt Snyk diese Aktivitäten jedoch als zwei eindeutige, voneinander unabhängige Einheiten und somit als zwei aktive Rechner. Führt ein einzelner Entwickler Coding Agent Security außerdem in mehreren virtuellen Umgebungen aus – entweder auf verschiedenen Plattformen (z. B. Coder und JetBrains) oder mit mehreren Logins auf derselben Plattform –, wird seine Aktivität für jede eindeutige Login-Kennung separat abgerechnet, und jede dieser Kennungen gilt als eigener aktiver Rechner. Snyk addiert die aktiven Rechner auf Endgeräten und in virtuellen Umgebungen, um den gesamten täglichen Credit-Verbrauch eines Kunden für Coding Agent Security zu bestimmen.

So berechnen wir „pro Assessment“

Der Credit-Verbrauch für AI Pentesting richtet sich nach der Anzahl abgeschlossener Assessments. Ein Assessment bezeichnet einen vollständigen Durchlauf der AI-Pentesting-Agents von Snyk gegen eine einzelne Anwendung, einschließlich zugehöriger Microservices, die von dieser Anwendung aufgerufen werden, sowie aller im Rahmen des Assessments ausgelösten erneuten Tests nach der Behebung.

Eine Anwendung ist das Ziel, das in einem Assessment geprüft wird. Sie wird durch eine primäre Web-URL, zusätzliche URLs im Prüfungsumfang, eine Zulassungsliste, eine Ablehnungsliste und Benutzeranmeldedaten definiert. Microservices sind zusätzliche Backend-Services oder APIs, die von der Anwendung aufgerufen und während des Tests ausgeführt werden, wie anhand des während des Durchlaufs erfassten Aufrufgraphen ermittelt. Alle diese Microservices sind im Preis für das einzelne Assessment enthalten; es fallen keine separaten Gebühren pro Microservice an.

Ein erneuter Test nach der Behebung ist ein nachgelagerter Workflow, bei dem der Nutzer eine in einem Assessment identifizierte Schwachstelle behebt und anschließend den Agenten auffordern kann, dieselbe Schwachstelle erneut zu testen, um die Behebung zu bestätigen. Beim erneuten Test wird entweder bestätigt, dass dieselbe Schwachstelle behoben wurde, oder sie besteht weiterhin. In diesem Fall kann der Workflow für den erneuten Test wiederholt werden. Erneute Tests beziehen sich ausschließlich auf Schwachstellen eines bestehenden Assessments, sind im ursprünglichen Abrechnungsereignis zum Tarif „pro Assessment“ enthalten und werden nicht als neues Ereignis abgerechnet.

Ein vollständiger Assessment-Lebenszyklus umfasst die Initiierung durch den Nutzer, die Validierung des Ziels, Schwachstellentests, die Risikoanalyse und die Erstellung eines Berichts. Ein Assessment gilt nur dann als abgeschlossen, wenn es weder von Snyk noch vom Nutzer abgebrochen wird und nicht zu einem Scan-Fehler führt. Nur abgeschlossene Assessments zählen als abrechenbare Nutzung; fehlgeschlagene Scans werden dabei nicht berücksichtigt.

Ein Scan-Fehler liegt vor, wenn ein begonnenes Assessment nicht abgeschlossen wird. Zu den erwartbaren Fehlerursachen zählen fehlende Zugangsdaten, ein nicht erreichbares Ziel und eine Blockierung durch eine WAF. Scan-Fehler werden nicht berechnet.

Jedes Assessment testet eine einzelne Anwendung und deren sekundäre URLs. Bei besonders komplexen Zielen, die eine einzigartige Testtiefe erfordern, kann ein abgeschlossener Bericht Angriffspfade aufzeigen, die gründlichere, gezielte Tests erfordern. Diese Tests stellen ein separates Assessment dar, für dessen Durchführung sich der Kunde entscheiden kann. Während der Testphase wendet Snyk ein Token-Reasoning-Limit in Höhe von 2.000 USD an. Nähert sich ein Assessment diesem Limit, identifiziert der Agent Bereiche, die eine zusätzliche Analyse erfordern, dokumentiert diese im Bericht und empfiehlt ein Folge-Assessment. Das ursprüngliche Assessment wird dennoch mit einem vollständigen Assessment-Bericht abgeschlossen. Der Kunde kann sich entscheiden, die markierten Bereiche in einem separaten, abrechenbaren Assessment weiterzuverfolgen.

Testlimits

Für Snyk-Produkte können Testlimits gelten, wie in einer entsprechenden Bestellung angegeben und auf dieser Seite näher erläutert.

Richtlinie zur Credit-Nutzung

Snyk Platform Credits („Credits“) sind Teil des gewährten Abonnementkontingents und der eingeschränkten Lizenz für Snyk-Produkte und -Services. Wenn der Kunde Credits nutzt, zieht Snyk die für die jeweiligen Services erforderliche Anzahl an Credits vom Credit-Guthaben des Kunden ab. Credits müssen innerhalb der Laufzeit der entsprechenden Bestellung genutzt werden. Danach verfallen alle ungenutzten Credits und können weder eingelöst noch erstattet oder gutgeschrieben werden. Credits können nicht gegen Bargeld eingelöst werden und sind nicht übertragbar. Sobald der Kunde seine vorausbezahlten Credits aufgebraucht hat, kann Snyk dem Kunden alle Credits in Rechnung stellen, die über das vorausbezahlte Credit-Kontingent des Kunden hinaus verbraucht wurden. Dabei gelten die in der Preisliste festgelegten Credit-Verbrauchssätze sowie der Credit-Preis des Kunden gemäß der entsprechenden Bestellung.