Copy-pasted code is one of the quietest ways vulnerabilities spread through a codebase. A developer fixes an SQL injection bug in one service, forgets that the same vulnerable block was cloned into three other repositories eighteen months earlier, and the fix never reaches them. For several years, Snyk Code shipped a built-in answer to part of this problem: a "Code Quality" findings category, separate from its security rules, that flagged duplicate code, near-identical branches, dead code, and other structural smells directly inside the same scan that ran SAST checks. That capability was retired on June 24, 2025. This post explains how the underlying duplicate and similar-code detection actually worked while it existed, why Snyk pulled it, and what teams that depended on it need to do now.
What did Snyk Code's duplicate and similar-code detection actually flag?
It flagged structural code problems that sit adjacent to, but distinct from, security vulnerabilities: duplicate code blocks, branches with identical logic on both sides of a conditional, unreachable ("dead") code, and predefined conditions that always evaluate the same way. These showed up under a "Quality" tab or filter, next to Snyk Code's "Security" findings, in both the web UI and the IDE plugins (VS Code, JetBrains, Visual Studio, Eclipse). Quality issues were scored on Snyk's Low/Medium/High severity scale like security issues, but they carried no CWE mapping and didn't factor into a project's vulnerability count — they were presented as maintainability signal, not risk signal. Because they rode along in the same scan as Snyk Code's SAST analysis, a team running Snyk in CI got duplicate-code visibility "for free" without configuring a second tool, which is the main reason it got adopted by smaller teams that didn't already run a dedicated quality gate like SonarQube or Codacy.
How did the engine actually identify duplicates, rather than just diffing text?
It worked at the semantic level, not the text level, because the underlying engine came from DeepCode.ai — the static analysis company Snyk acquired in 2020 and folded into Snyk Code. DeepCode's approach, which Snyk carried forward, parsed source into an abstract syntax tree (AST) and built a semantic representation of what the code does, rather than comparing raw tokens or lines. That distinction matters for duplicate detection specifically: a naive text-diff tool misses a "duplicate" where someone renamed three variables, reordered two independent statements, or swapped a for loop for a while loop with equivalent behavior. An AST/semantic comparison can still recognize those as structurally equivalent, because it's comparing the shape of the parsed code and its data/control flow rather than the literal characters. This is the same modeling approach Snyk Code has publicly described using for its core security engine — a hybrid of symbolic analysis and machine-learning models trained on large volumes of permissively licensed open-source commits — applied here to a quality-oriented rule set instead of a vulnerability rule set.
What technique did Snyk document for comparing code similarity across scans?
Snyk's own documentation on code analysis describes generating a min-hash of an issue's syntax tree and computing nearest neighbors between those hashes to identify similar findings across scans. Min-hashing is a standard technique for estimating the similarity between two sets (in this case, sets of AST features) without comparing every element pairwise — you hash multiple times, keep the minimum hash value from each pass, and compare the resulting hash "signature" between two code fragments to estimate how similar they are. Snyk describes using this for tracking and correlating issues over time — recognizing that an issue seen in one scan is the "same" or a "similar" issue seen in a later scan, even if the surrounding code moved. It's a useful, publicly documented illustration of how a fingerprint-and-compare approach can answer a similarity question at scale, which is conceptually the same class of problem duplicate-code detection has to solve, even though Snyk has not published a rule-by-rule spec of the exact algorithm the retired Code Quality feature used internally.
Why did Snyk retire Code Quality findings, including duplicate detection, in 2025?
Snyk stated that Code Quality findings were used by a small share of customers and that feedback indicated the feature set needed a rework rather than continued maintenance, so it was deprecated instead of revised. The change was announced as part of a broader update introducing a formal 12-month support policy for Snyk's IDE plugins, Language Server, and CLI versions, alongside the deprecation of a couple of other narrow features (JavaScript CDN library detection in HTML files, and container image detection in Kubernetes YAML). Effective June 24, 2025, Code Quality results stopped being generated in both the Snyk web UI and the IDE plugins; older plugin versions that still render a Quality section simply show it empty now. Snyk's stated rationale also noted that quality findings sometimes cluttered the view around the security findings that are the platform's core purpose — a reasonable prioritization call for a company whose product identity is security scanning, but one with real consequences for teams that had quietly folded that quality signal into their workflow.
What does this mean for teams that were using it as a quality gate?
It means any CI gate, dashboard, or dead-code cleanup process that depended on Snyk Code's Quality findings has lost that input with no in-product replacement, so it needs to be rebuilt on a different tool. Snyk Code itself continues to run — its security rules, taint analysis, and AI-assisted autofix suggestions for vulnerabilities are unaffected — but duplicate code, identical branches, and dead code will no longer appear anywhere in Snyk's output. Teams that want that coverage back are pointed toward dedicated code-quality platforms (SonarQube, Codacy, DeepSource, and similar tools are the ones most commonly cited for this) that treat duplication percentage, cyclomatic complexity, and maintainability debt as first-class metrics rather than a secondary tab. The practical takeaway is that "security scanner" and "code quality scanner" are reverting to being two separate categories of tool in most stacks, which was arguably the more common setup industry-wide even before Snyk added the combined view.
How should teams rebuild duplicate-code coverage without conflating quality and security?
They should keep the two concerns in separate tools with separate gates, and only merge the findings at the reporting layer, not the analysis layer. Concretely: keep Snyk Code (or another SAST tool) focused on vulnerability detection with its own severity thresholds and CI-blocking rules; add a dedicated quality tool that reports duplication percentage and complexity metrics on its own schedule, since those checks tend to be run less urgently than a security gate; and correlate the two only when a duplicated block also happens to contain a known-vulnerable pattern, which is a materially different and higher-priority signal than duplication alone. That correlation step is where duplicate-code detection stops being a pure code-quality concern and becomes a supply-chain security concern — a vulnerable snippet copy-pasted across ten internal repos (or vendored into a dependency and never updated) is effectively the same unpatched exposure repeated ten times, and neither a standalone quality tool nor a standalone SAST tool is built to answer "where else does this exact risky pattern live across our entire estate."
How Safeguard Helps
Safeguard is built for that cross-repository, cross-artifact view that a single-repo scanner — quality or security — isn't designed to give you. Where Snyk Code's (now-retired) duplicate detection worked file-by-file inside one scan, Safeguard correlates findings, provenance, and dependency relationships across your entire software supply chain, so a vulnerable pattern that got copied, vendored, or forked into multiple places shows up as one connected risk instead of N separate, unrelated alerts. That includes tracking where open-source components and internal code have been duplicated or repackaged downstream, flagging when a fix landed in one location but a cloned or forked copy elsewhere never received it, and feeding that context into SBOM and attestation data so security and engineering teams can see propagation, not just point-in-time findings. Safeguard doesn't replace a dedicated code-quality linter or a SAST engine — it sits on top of the signals those tools produce (including Snyk's, SonarQube's, or others') and adds the supply-chain-wide correlation layer that tells you whether a single duplicate-code or vulnerability finding is actually a scattered, repeated exposure across your codebase, your forks, and your dependency tree.