Snyk Code's ability to flag a SQL injection or an unsanitized data flow before code ever reaches a pull request review didn't come from hand-written rules alone. It came from an engine called DeepCode AI, built by an ETH Zurich spin-off that Snyk acquired in September 2020, whose core bet was that open-source commit history is one of the richest labeled datasets for "bad code" and "fixed code" that exists. Every time a maintainer patches a bug and pushes a commit, they leave behind a before-and-after pair that a model can learn from at scale. This post walks through, mechanically and without editorializing, how that pipeline is documented to work: where the training data comes from, how symbolic analysis and machine learning are combined, and how that same commit-mining approach now feeds Snyk's LLM-based autofix capability. The goal is to understand the plumbing, not to score it against any other vendor's approach.
What is DeepCode AI, and why does it matter to Snyk Code?
DeepCode AI — often shortened to Snyk DeepCode since Snyk absorbed the technology — is the machine learning engine underneath Snyk Code, Snyk's static application security testing (SAST) product, and it originated outside Snyk entirely. DeepCode was founded by researchers connected to ETH Zurich and EPFL who worked on applying machine learning to program analysis; Snyk announced its acquisition of the company on September 23, 2020, describing DeepCode's technology as combining data-driven machine learning with symbolic, rule-based static analysis. That combination — rather than a pure deep-learning black box — was the acquisition's stated rationale: Snyk wanted a scanner that could reason about code semantics quickly enough for real-time developer workflows while keeping false-positive rates low enough that developers wouldn't tune it out. Since the acquisition, DeepCode AI has been rebranded as the underlying engine of Snyk Code and later extended into Snyk's autofix capability, now called Agent Fix.
Where does the training data actually come from?
The training data is drawn from public open-source repositories, specifically commits that fix a known bug or vulnerability under a permissive license — one of the open source licensing models that, unlike copyleft terms, places no restriction on reusing the code for training a commercial model. According to Snyk's own product documentation, the models are trained on millions of open-source commits spanning a wide range of languages, and Snyk states explicitly that customer code is never used to train the shared models — training data is limited to public, permissively licensed projects with verifiable fixes. Mechanically, this means the pipeline has to find pairs of commits (or diffs within a single commit) where a vulnerable pattern appears in the "before" state and a corrected pattern appears in the "after" state — for example, a database query built with string concatenation in one revision and the same query rebuilt with a parameterized statement in the next. Collecting these pairs at scale requires filtering: repositories need enough history and enough real fix activity to be useful, license terms need to be checked, and commits need to be distinguishable from unrelated refactors, formatting changes, or feature work that happens to touch the same lines.
How does symbolic analysis fit alongside the machine learning model?
Symbolic analysis is what turns raw source code into a structured representation the ML model can reason over, and it runs before and alongside the learned component rather than being replaced by it. When Snyk Code scans a file, it builds an abstract syntax tree and a data-flow representation that tracks how values move from sources (like user input) through the program to sinks (like a database call or a shell command), including where sanitizers appear along the way. This symbolic layer is what lets the tool trace a vulnerability across multiple functions or files instead of pattern-matching a single line. The machine learning layer, trained on the commit-derived dataset described above, is applied on top of this structured representation to recognize which data-flow patterns historically correlate with real, fixed vulnerabilities versus which superficially similar patterns turned out to be safe. Snyk has described this pairing as intended to reduce both false negatives (missed bugs that don't match a hand-written rule) and false positives (flagged patterns that aren't actually exploitable), rather than relying on either symbolic rules or a learned model alone.
How does commit history turn into an actual autofix suggestion?
Commit history feeds autofix by supplying matched pairs of vulnerable and patched code that a language model is trained or fine-tuned to reproduce, and this specific mechanism is documented in a 2024 research paper published by Snyk's own researchers, "DeepCode AI Fix: Fixing Security Vulnerabilities with Large Language Models" (arXiv:2402.13291). The paper describes building a dataset of real-world vulnerability fixes mined from open-source repositories and using it to fine-tune and evaluate several language models — including StarCoderBase, Mixtral, T5, GPT-3.5, and GPT-4 — on the task of transforming vulnerable code into a fixed version, with the original evaluation centered on JavaScript, TypeScript, and their React/Vue extensions. That research line has since evolved into Snyk's production autofix feature, now branded Agent Fix, which Snyk has said moved to an agentic architecture and expanded language coverage well beyond the paper's original scope, including Java, Python, C/C++, Go, and Apex. Snyk has publicly cited roughly 80% accuracy for its autofix suggestions, though that figure describes suggestions a developer still reviews and applies, not a fully autonomous patching pipeline.
How current does the training data stay, and who decides what gets ingested?
The dataset and the rules built from it are described as continuously refreshed rather than trained once and frozen. Snyk's materials describe an ongoing pipeline that keeps ingesting newly disclosed fix commits from open-source projects, and separately describe human security researchers vetting and curating the resulting detection rules so that new vulnerability classes and new coding patterns get incorporated without waiting for a full model retrain. In practice this looks like two update cadences layered on top of each other: a slower cadence for retraining or fine-tuning the underlying models on newly collected commit data, and a faster cadence for adding or adjusting individual detection rules as researchers identify gaps or false-positive patterns in production usage. This is consistent with how most vendors running ML-assisted SAST describe their update loops, since retraining a full model is expensive but shipping a rule adjustment is not.
What are the inherent limits of training on commit history?
Training on public commit history means the model's coverage mirrors the coverage of open-source activity itself, which is not evenly distributed across languages, frameworks, or vulnerability classes. A language or framework with a large, active open-source ecosystem and a habit of writing descriptive fix commits will produce more usable training pairs than a niche or predominantly closed-source stack, and a vulnerability class that gets fixed frequently and visibly in public repos (like injection flaws) will be better represented than one that is rare, subtle, or usually patched privately before disclosure. Filtering for permissive licenses and verifiable, real fixes — as Snyk describes doing — also shrinks the usable pool relative to the full universe of public code, since only a subset of open source licensing models qualify for reuse in a training set, and any bias in which projects get scanned or which commits get labeled as genuine fixes versus incidental changes will propagate into the model's blind spots. None of this is unique to DeepCode AI; it's a structural property of any system trained primarily on open-source commit history, and it's part of why Snyk pairs the learned model with symbolic, rule-based analysis rather than shipping the ML component on its own.
How Safeguard Helps
Understanding how a SAST vendor's models are trained matters beyond curiosity, because AI-assisted findings and AI-generated autofixes are increasingly part of the code that flows into your software supply chain, and that code still needs provenance, review, and integrity guarantees regardless of which engine produced it. Safeguard helps teams apply that scrutiny consistently: tracking the origin and change history of dependencies and generated patches so an autofix commit — whether it came from Snyk DeepCode's suggestion engine, another SAST tool, or a developer's own IDE assistant — is attributed, reviewable, and tied to an auditable trail rather than merged on trust. Safeguard also correlates findings and remediation activity across your SBOM and CI/CD pipeline, so a fix accepted from any tool can be verified against real dependency and build context before it ships, and so security and compliance teams have a consistent record of what changed, when, and why. For organizations layering multiple AI-assisted security tools into their pipeline, that independent verification layer is what keeps "the model suggested a fix" from becoming the only check a critical change receives before it reaches production.