When a maintainer quietly patches a security bug in a changelog note, when a GitHub Security Advisory drops at 2 a.m. UTC, or when a researcher privately reports a flaw before any CVE exists, someone still has to notice, verify, and score it before development teams can act on it. For the open source ecosystem, that job largely falls to vulnerability intelligence vendors, and the Snyk Vulnerability Database (marketed as Snyk Intel) is one of the most widely embedded feeds behind commercial software composition analysis tools today. Unlike the National Vulnerability Database, which mostly waits for a CVE ID to exist before publishing, Snyk's database is built by a dedicated security research team that actively hunts for issues, cross-references a dozen public feeds, and assigns its own identifiers when no CVE is available. This piece walks through what Snyk has publicly documented about how that pipeline works: sourcing, verification, scoring, and disclosure timing, without speculating on parts of the process Snyk hasn't disclosed.
Where does Snyk's vulnerability data actually come from?
Snyk pulls from a mix of public advisory feeds, vendor bulletins, and its own in-house research team rather than relying on a single upstream source. Its documented inputs include the NVD/CVE feed, the GitHub Security Advisory (GHSA) database, ecosystem-specific advisory repositories such as RubySec for RubyGems and the PHP Security Advisories Database for Composer packages, and vendor bulletins from Linux distributions like Red Hat, Debian, and Ubuntu for container and OS-level packages. Alongside these automated feeds, Snyk maintains a public disclosure form where independent researchers can privately submit findings, and it publishes original research through its own security research team via security.snyk.io and the Snyk blog. This layered sourcing model is why Snyk's database entries are almost never a straight mirror of NVD: an npm package flaw might originate from a GHSA entry, a Python package flaw from a PyPI advisory, and a container base-image flaw from a distro's own security tracker, each normalized into Snyk's internal schema before it reaches a customer's scan results.
How does Snyk catch vulnerabilities that never get an official CVE?
Many open source vulnerabilities are fixed silently, with a one-line commit message and no formal advisory, so Snyk assigns its own SNYK-prefixed identifiers to track these issues independently of the CVE program. A typical ID follows an ecosystem-package-number pattern, for example SNYK-JS-LODASH-567746, which lets Snyk publish and version an advisory even when MITRE or a GitHub Security Advisory never gets involved. To find these silent fixes, Snyk has publicly described monitoring package repository activity, commit histories, and changelog language for patterns associated with security fixes, such as commit messages referencing "XSS," "prototype pollution," or "buffer overflow," which then get routed to a researcher for manual confirmation before anything is published. The lodash prototype pollution research is a well-documented example of this in practice: Snyk's security research team was directly involved in identifying and helping coordinate disclosure for a string of lodash issues between 2018 and 2020, including CVE-2018-16487, CVE-2019-10744, and CVE-2020-8203, several of which trace back to independent research rather than an inbound CVE assignment.
What happens between a raw tip and a published advisory?
Every candidate disclosure goes through a manual triage step where a security researcher reproduces the issue, confirms the affected and fixed version ranges, and writes remediation guidance before it becomes a public advisory entry. In practice, that means pulling the actual package source at the reported version, attempting to reproduce a proof-of-concept where one exists, and testing surrounding versions to establish precise "vulnerable" and "patched" boundaries, an area where NVD entries are frequently vague or simply wrong because MITRE does not independently retest every submission. Once confirmed, the researcher classifies the issue by weakness type (mapped to a CWE category), writes a plain-language description of the impact and exploitation path, and links to the upstream fix commit or release. Only after this review does the entry get a public-facing page on security.snyk.io, at which point it starts appearing in scan results for any tool consuming the Snyk Vulnerability Database, including Snyk's own CLI and IDE integrations.
Why does Snyk recalculate CVSS scores instead of just using NVD's?
Snyk frequently overrides or supplements the NVD-supplied CVSS score because NVD scores a vulnerability generically against the software in isolation, while Snyk's researchers score it in the context of how the package is actually consumed as a dependency. A prototype pollution bug in a small utility library, for instance, might carry a modest NVD score on its own, but Snyk's writeup will typically note how severity changes depending on whether the vulnerable function is reachable from user input in a typical application. Snyk's documentation also describes a separate "Priority Score," distinct from CVSS, that factors in signals like exploit maturity, how widely a package is used, and whether public exploit code exists, specifically to help teams triage a backlog of findings rather than treat every CVSS 9.8 as equally urgent. This is also why two scanners referencing the "same" CVE can surface different severities for a customer: one may be quoting NVD's base score verbatim, while the other is quoting a vendor's contextually adjusted score.
How does responsible disclosure and embargo timing actually work?
Snyk follows a coordinated disclosure model that typically gives a maintainer a defined window, consistent with common industry norms of roughly 90 days, to ship a fix before full technical details go public, though the timeline compresses when a flaw is already being actively exploited or has already leaked elsewhere. This is visible in how Snyk handled Log4Shell: CVE-2021-44228 became public on December 9, 2021, and rather than sitting on an embargo that no longer applied, Snyk published detection and remediation guidance the same day, since the vulnerability was already circulating widely and the priority shifted from coordinated disclosure to rapid customer notification. For vulnerabilities discovered through Snyk's own research rather than an existing public report, the standard practice is to notify the maintainer privately first, work with them on a patch and version bump, and only publish the Snyk advisory once a fixed version is available, or once the disclosure window lapses without a response.
How Safeguard Helps
Understanding how any single vendor's vulnerability database is built matters because no one feed is complete on its own, and dependency graphs in real applications routinely pull data that different databases classify, score, or timestamp differently. Safeguard's approach is to treat vulnerability intelligence as a multi-source problem rather than trusting one feed as ground truth: normalizing entries from NVD, GHSA, ecosystem advisory databases, and vendor bulletins against the actual software bill of materials generated for a given build, so a gap or delay in any single source doesn't become a blind spot in a customer's risk picture. Where public databases disagree on severity or version ranges, Safeguard correlates the underlying evidence, fix commits, affected version boundaries, and exploit maturity signals, against the specific artifact and its provenance, rather than surfacing a generic score disconnected from how the component is actually built and shipped. That context matters most in the moments this article describes: the gap between a silent upstream fix and a formal advisory, or between a CVE's publication and a coordinated disclosure window closing, where teams that can only see one vendor's view of the timeline are the ones left reacting last.