Snyk-Plattform-Abonnement

Das Snyk-Plattform-Abonnement verstehen

Das Snyk-Plattform-Abonnement ist eine verbrauchsbasierte Lizenz für Funktionen der Snyk-Plattform. Die Nutzung dieser Funktionen verbraucht Credits aus einem im Voraus erworbenen Guthaben, basierend auf der Preisliste und den unten beschriebenen Maßeinheiten. Sobald das im Voraus erworbene Credit-Guthaben aufgebraucht ist, wird jede weitere Nutzung als On-Demand-Verbrauch in Rechnung gestellt.

Preisliste für Credits

So berechnen wir „pro aktivem Mitwirkenden und Tag“

Der Credit-Verbrauch für Plattformfunktionen, die „pro aktivem Mitwirkenden und Tag“ gemessen werden, wird anhand der täglichen Anzahl aktiver Mitwirkender in allen von dieser Funktion überwachten Repositorys bestimmt. Der Verbrauch beginnt an dem Tag, an dem die Überwachung beginnt, und endet am Tag, nachdem das Repository aus der Überwachung entfernt wurde. Ein Repository, das nur einen Teil des Tages überwacht wird, verbraucht die Credits für einen vollständigen Tag.

Ein aktiver Mitwirkender ist jeder eindeutige Mitwirkende, der für Sie oder in Ihrem Namen handelt und innerhalb eines rollierenden Zeitraums von 90 Tagen einen Commit an ein privates, von Snyk überwachtes Repository vorgenommen hat. Aktive Mitwirkende können menschlich oder nicht menschlich sein. Dazu zählen beispielsweise Ihre Mitarbeitenden, unabhängigen Auftragnehmer, Agenten, Bots von Drittanbietern, automatisierte Systeme und Dienstkonten. Native automatisierte Snyk-Bots wie <snyk-bot@snyk.io> werden bei dieser Zählung ausgeschlossen.

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. Wenn ein Projekt für eine Funktion erstellt wird, wird sein Status auf aktiv gesetzt und bleibt aktiv, bis es deaktiviert wird. Ein Repository gilt auch dann als überwacht, wenn es an einem bestimmten Tag nicht aktiv gescannt wird.

Um aktive Mitwirkende für eine bestimmte Funktion zu zählen, identifiziert Snyk jeden Mitwirkenden anhand des Benutzernamens über alle von dieser Funktion überwachten Repositorys hinweg. Jeder eindeutige Benutzername zählt als ein aktiver Mitwirkender, unabhängig davon, in wie vielen überwachten Repositorys er vorkommt. 

Snyk leitet aus der E-Mail-Adresse eines Mitwirkenden einen Benutzernamen ab, indem die Adresse in Kleinbuchstaben umgewandelt, zusätzliche Leerzeichen entfernt, jede Subadresse entfernt (einschließlich des Pluszeichens sowie aller Zeichen zwischen dem ermittelten Benutzernamen und der Domain) und die Domain entfernt wird. Die Deduplizierungslogik erkennt außerdem häufige Varianten derselben Identität – etwa standardmäßige E-Mail-Aliase und private No-Reply-Adressen von GitHub und GitLab – und führt sie zu einem einzigen Benutzernamen zusammen. Die folgenden Beispiele zeigen, wie verschiedene E-Mail-Formate auf einen Benutzernamen reduziert werden.

Snyk behält sich das Recht vor, Kontenaktivitäten und Daten zur Identität von Mitwirkenden zu überprüfen, wenn nach vernünftigem Ermessen davon auszugehen ist, dass eine Manipulation von Benutzernamen oder andere Identitätsmuster verwendet werden, um eine genaue Messung der aktiven Mitwirkenden zu umgehen.

Zwei wichtige Hinweise:

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

• IP-Adress-Domains: Eine E-Mail-Adresse, deren Domain eine IP-Adresse ist, wird nicht auf einen Benutzernamen reduziert; die vollständige E-Mail-Adresse zählt als ein aktiver Mitwirkender.

Veranschaulichendes Beispiel:

So berechnen wir „pro überwachtem Image und Tag“

Der Credit-Verbrauch für Container basiert auf der Anzahl der überwachten Images, die an einem bestimmten Tag beobachtet werden. Ein überwachtes Image ist jedes eindeutige Container-Image, das an diesem Tag in Snyk importiert, in einer synchronisierten Registry beobachtet oder in der CLI oder IDE getestet wird und für das ein offenes Containerprojekt 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 Containerprojekt überwacht wird. Ein Containerprojekt ist offen, sofern es nicht gelöscht oder archiviert wurde. Jedes überwachte Image, das während eines beliebigen Teils eines Kalendertags über ein offenes Containerprojekt verfügt, verbraucht für diesen Tag die Credits für einen vollständigen Tag. Der Verbrauch endet am Tag nach dem Löschen oder Archivieren eines Containerprojekts. Ein Projekt wird archiviert, wenn sein Überwachungsstatus als inaktiv gekennzeichnet wird; dadurch werden automatisierte tägliche Scans und Sicherheitswarnungen sofort pausiert. Durch das Löschen eines Containerprojekts, das Archivieren eines Projekts oder das Aufheben der Synchronisierung einer Registry werden diese Images aus der Überwachung entfernt und ihr Verbrauch am folgenden Tag beendet. Entfernte Images werden am Tag ihrer Entfernung weiterhin für die Messung berücksichtigt. Wenn mit einem bestimmten eindeutigen Image kein offenes Containerprojekt verknüpft ist, gilt das Image als nicht überwacht und verbraucht an diesem Tag keine Credits.

Einmalige Tests über einen nicht überwachten Test in der CLI werden bei der Messung überwachter Images nicht berücksichtigt, da kein Projekt erstellt wird. Dockerfile-Scans sind von der Image-Anzahl getrennt und tragen nicht zur Messung bei. Ein Dockerfile-Scan-Projekt ist kein überwachtes Image und verbraucht bei dieser Maßeinheit keine Credits. Dockerfile-Scans sind in einem Enterprise-Snyk-Plattform-Abonnement enthalten.

Der SHA-256-Digest eines Container-Images ist die maßgebliche Quelle für seine Eindeutigkeit bei der Deduplizierung. Ein Digest wird unabhängig davon nur einmal gezählt, auf wie viele Tags, Repositorys, Projekte, Organisationen oder Gruppen er innerhalb des Kontos verweist. Zwei Images mit demselben Tag, die zu unterschiedlichen Digests aufgelöst werden, sind zwei unterschiedliche Images. Ein veränderlicher Tag, der mit einem neuen Digest neu erstellt wird, erzeugt ein neues überwachtes Image. Die Deduplizierung erfolgt kontoweit. Alle Projekte aus allen Organisationen und Gruppen eines Kontos werden vor der Zählung pro Tag zu einer einzigen unterschiedlichen Digest-Menge zusammengeführt.

So berechnen wir „pro bereitgestelltem Ziel und Tag“

Der Credit-Verbrauch für API und Web basiert auf der Anzahl der täglich in Ihrem Konto bereitgestellten Ziele. Der Verbrauch beginnt an dem Tag, an dem ein Ziel hinzugefügt wird, und endet am Tag, nachdem es entfernt wurde. Jedes Ziel, das nur einen Teil des Tages bereitgestellt ist, verbraucht die Credits für einen vollständigen Tag.

Jede in der Plattform definierte eindeutige Basis-URL ist ein bereitgestelltes Ziel. Administratoren können bereitgestellte Ziele im Bereich „Ziele“ der API- und Webplattform anzeigen und verwalten.

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

Bereitgestellte Ziele umfassen den Zugriff auf verschiedene Scanarten:

So berechnen wir „pro aktivem Computer und Tag“

Der Credit-Verbrauch für Coding Agent Security basiert auf der Anzahl der von Snyk an einem Tag beobachteten aktiven Computer. Ein aktiver Computer ist eine Entwicklerumgebung, die entweder aus einem Endgerät oder einer virtuellen Umgebung besteht und auf der KI-Agenten ausgeführt werden. Ein Computer ist an einem bestimmten Tag aktiv, wenn innerhalb dieses Tages eines der folgenden qualifizierenden Telemetrieereignisse auf ihm auftritt:

1. Agent Scan: Abgeschlossener Scan der Umgebung.

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

Wenn beide Telemetrieereignisse an einem bestimmten Tag auf demselben aktiven Computer beobachtet werden, zählt Snyk diesen aktiven Computer bei der Messung nur einmal. Ein aktiver Computer wird unabhängig davon, wie viel Telemetrie aus einem der beiden qualifizierenden Ereignisse an diesem Tag beobachtet wird, einmal pro Tag abgerechnet. Computer verbrauchen nur an den Tagen Credits, an denen sie aktiv sind. Vergeht ein vollständiger Tag, an dem kein qualifizierendes Telemetrieereignis auf dem Computer auftritt, wird er nicht als aktiv gezählt und verbraucht für diesen Tag keine Credits. Der aktive Status eines Computers wird unabhängig von anderen Tagen bestimmt, an denen er möglicherweise zuvor aktiv war.

Snyk zählt zwei verschiedene Arten aktiver Computer:

1. Endgerät – Ein Laptop, Desktopcomputer 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), in 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 und eindeutigen Hardwarekennung auf Betriebssystemebene. Die konkrete von Snyk verwendete Kennung variiert je nach Plattform (IOPlatformUUID auf macOS, SMBIOS / Win32_ComputerSystemProduct.UUID auf Windows, /etc/machine-id auf Linux). Eine virtuelle Umgebung zählt Snyk hingegen anhand der eindeutigen und stabilen Kennung des Inhaber-Logins, Benutzernamens oder der Principal-ID der Cloudplattform (je nach Plattform), nicht anhand der Workspace-Instanz selbst. Daher kann ein einzelner Entwickler innerhalb seiner virtuellen Umgebung (der Kennung des Cloudplattform-Inhabers) an einem Tag mehrere kurzlebige Workspaces starten und trotzdem nur als ein aktiver Computer zählen. Wenn derselbe Entwickler Coding Agent Security sowohl lokal auf seinem Endgerät als auch in seiner virtuellen Umgebung ausführt, würde Snyk diese Aktivität jedoch als zwei eindeutige und unabhängige Einheiten für die Messung zählen, also als zwei aktive Computer. Wenn ein einzelner Entwickler Coding Agent Security außerdem über mehrere verschiedene virtuelle Umgebungen hinweg ausführt, entweder auf verschiedenen Plattformen (z. B. Coder und JetBrains) oder über mehrere Logins innerhalb derselben Plattform, wird die Aktivität dieses Entwicklers pro eindeutiger Login-Kennung gemessen, und jede solche Kennung stellt einen separaten aktiven Computer dar. Snyk misst die kombinierte Anzahl aktiver Computer aus Endgeräten und virtuellen Umgebungen, um den täglichen Gesamtverbrauch an Credits eines Kunden für Coding Agent Security zu bestimmen.

So berechnen wir „pro Assessment“

Der Credit-Verbrauch für AI-Pentesting basiert auf der Anzahl abgeschlossener Assessments. Ein Assessment bezeichnet eine vollständige Ausführung der KI-Pentesting-Agenten von Snyk gegen eine einzelne Anwendung, einschließlich zugehöriger Microservices, die von dieser Anwendung aufgerufen werden, sowie aller nachgelagerten erneuten Tests, die im Rahmen des Assessments ausgelöst werden.

Eine Anwendung ist das bewertete Ziel eines Assessments. Sie wird durch eine primäre Web-URL, zusätzliche URLs innerhalb des Geltungsbereichs, eine Zulassungsliste, eine Ablehnungsliste und Benutzeranmeldedaten definiert. Microservices sind zusätzliche Backend-Dienste oder APIs, die die Anwendung aufruft und die während des Tests ausgeführt werden, wie anhand des während des Laufs beobachteten Aufrufgraphen ermittelt. Alle diese Microservices sind durch den Preis für ein einzelnes Assessment abgedeckt; es fällt keine separate Gebühr pro Microservice an.

Die erneute Prüfung nach der Behebung ist ein nachgelagerter Workflow, bei dem eine in einem Assessment identifizierte Schwachstelle vom Benutzer behoben wird. Anschließend kann der Benutzer den Agenten auffordern, dieselbe Schwachstelle erneut zu prüfen, um die Behebung zu bestätigen. Bei der erneuten Prüfung wird entweder bestätigt, dass dieselbe Schwachstelle behoben wurde, oder sie besteht weiterhin; in diesem Fall kann der Workflow zur erneuten Prüfung wiederholt werden. Die erneute Prüfung gilt ausschließlich für Schwachstellen eines bestehenden Assessments, ist als Teil des ursprünglichen Abrechnungsvorgangs im Tarif „pro Assessment“ enthalten und wird nicht als neuer Vorgang abgerechnet.

Der vollständige Lebenszyklus eines Assessments umfasst die Initiierung durch den Benutzer, die Validierung des Ziels, Schwachstellentests, Risikoanalyse und die Erstellung des Berichts. Ein Assessment ist nur dann abgeschlossen, wenn es weder von Snyk noch vom Benutzer abgebrochen wird und nicht zu einem Scanfehler führt. Nur abgeschlossene Assessments gelten als abrechenbare Nutzung; fehlgeschlagene Scans werden dabei nicht berücksichtigt.

Ein Scanfehler tritt auf, wenn ein gestartetes Assessment nicht abgeschlossen wird. Zu den erwarteten Fehlerfällen gehören fehlende Anmeldedaten, ein nicht erreichbares Ziel und eine Blockierung durch eine WAF. Scanfehler werden nicht berechnet.

Jedes Assessment testet eine einzelne Anwendung und deren sekundäre URLs. Bei besonders komplexen Zielen mit einzigartiger Testtiefe kann ein abgeschlossener Bericht Angriffspfade aufzeigen, die eingehendere, dedizierte Tests rechtfertigen. Die Durchführung solcher Tests ist ein separates Assessment, für das sich der Kunde entscheidet. Während der Testphase wendet Snyk ein Token-Limit für die Schlussfolgerung an, das 2.000 USD entspricht. Wenn sich ein Assessment diesem Limit nähert, identifiziert der Agent Bereiche, die zusätzliche Analysen erfordern, dokumentiert diese Bereiche im Bericht und empfiehlt ein Folge-Assessment. Das ursprüngliche Assessment wird dennoch mit einem vollständigen Assessment-Bericht abgeschlossen. Der Kunde kann sich dafür entscheiden, die gekennzeichneten Bereiche als separates, abrechenbares 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 Bestandteil des zugewiesenen Abonnementkontingents und der beschränkten Lizenzgewährung für Snyk-Produkte und -Services. Wenn der Kunde Credits verwendet, zieht Snyk die für die betreffenden Services erforderliche Anzahl an Credits vom Credit-Guthaben des Kunden ab. Credits müssen innerhalb der Laufzeit der entsprechenden Bestellung verwendet werden. Danach verfallen nicht verwendete 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. Nach vollständigem Verbrauch der vorausbezahlten Credits des Kunden kann Snyk dem Kunden alle Credits in Rechnung stellen, die über das vorausbezahlte Credit-Kontingent hinaus verbraucht wurden, und zwar zu den geltenden Credit-Verbrauchsraten gemäß der Rate Card und zum Preis pro Credit des Kunden gemäß der entsprechenden Bestellung.