This section provides references to the Snyk data model and the most popular fields. For a complete reference to the Snyk API data fields please see the Snyk API documentation
There are a few core entities and cardinality you should be familiar with in the Snyk API data model. These entities are listed here including a description and URL link to the API documentation.
Groups - A collection of organizations in Snyk. Groups contain a Group Id, Members, Service Accounts, etc. Groups aggregate organization information and provide global policies. Customers may have zero, one, or more groups. Groups apply to Snyk Pro and Enterprise customers only.
Organizations - A collection of Projects in Snyk, Organizations provide configuration for Access Rights, Policies, Service Accounts, etc. Customers may have one or more organizations per group. Snyk customers using Standard or free plans only have organizations.
Project - A project is a package that is actively tracked in Snyk and created as part of an import action. It represents the package manager manifest file that lists the set of dependencies for the application. Customers may have zero, one, or more projects per organization.
Issues - A collection of issues in Snyk. Issues include both licensing violations and vulnerabilities and are attached to a specific project. A project may have zero, one, or more issues per project. The issues are the actual scan results that contain the license issues and vulnerabilities.
Users - A user represents the person accessing, configuring, or being assigned to Groups, Orgs, or Projects.
Integrations - A integration represents the configurations of a specific DevOps tool like SCM or Container Registry. Integrations can also be used to import or remove projects from Snyk.
Snyk scan results contain a rich set of metadata about the vulnerabilities discovered. Use table below for a quick reference of the most popular fields and their potential usage inside your platform:
Array of strings
Discoverer / Reporter of the vuln
Array of strings (CVE format)
CVE(s) if exists. Not all vulns have a CVE as that takes a while to be assigned.
Cvss V3.1 score, computed based on the base score of the cvss vector
String (CVSS format)
Cvss V3.1 vector, including base score. Might include partial temporal score where applicable
Array of strings (CWE format)
The common weakness enumeration (CWE) of the vuln
Full description of vulnerability. This field is meant for human consumption, and repeats a few machine-readable fields such as references and remediation. The format is markdown, making this easy to display to users.
"## Overview\n\norg.quartz-scheduler.internal:quartz-core is a job scheduling library.\n\n\nAffected versions of this package are vulnerable to XML External Entity (XXE) Injection\nvia the
String (date-time format)
Timestamp of when the vulnerability was first made publicly available (either known to us or as appears the vulnerability source)
String, supported exploit maturity values as appear in cvss vector specification
Snyk looks for exploits in the wild and evaluates their maturity. Snyk also writes it’s own POC to evaluate vulnerability exploitability. This knowledge goes into assessing the maturity of the exploit as appears in this field. Values are from section 3.1 in https://www.first.org/cvss/v3.1/specification-document
Is there a fixed version- i.e. a newer version without this specific vulnerability
Snyk’s Vulnearbility’s ID
Array of strings
This indicated the earliest version that is vuln-free. As this might be a backport fix, this does not mean that newer versions aren’t vulnerable to it. We highly recommend using the field vulnerableVersions
[ "2.2", "2.6.14", "2.7.11"]language
Specifies the ecosystem of the vulnerability (java,python, etc)
Indication if the vuln is known to mark a malicious package