A developer opens a Snyk Code scan on a mid-size Java service and sees 47 findings. Eleven are labeled security vulnerabilities — a SQL injection risk here, a hardcoded credential there. The other 36 are flagged as code quality issues: an unused import, an empty catch block, a method with a cyclomatic complexity score that makes it hard to maintain. Both lists carry severity ratings. Both show up in the same pull request check. So why does Snyk treat them as two separate categories instead of one flat list of "problems"?
The answer sits in how Snyk Code's underlying engine — built on technology from its 2020 acquisition of DeepCode — tags, scores, and routes findings. Understanding that split matters for anyone deciding what blocks a merge, what gets a Jira ticket, and what a security team should actually be measured on. This piece walks through the mechanics as Snyk has publicly documented them.
What Actually Separates a Security Issue From a Code Quality Issue in Snyk Code?
A security issue is a weakness that maps to a known exploitable pattern — typically tied to a CWE (Common Weakness Enumeration) identifier such as CWE-89 (SQL injection) or CWE-79 (cross-site scripting) — while a code quality issue is a pattern that hurts reliability, maintainability, or performance without representing an attacker-reachable weakness. Snyk Code's product interface and documentation present these as two distinct result sets, each filterable independently in the UI, the IDE plugins, and the API. A SQL query built through unsanitized string concatenation gets classified as a security vulnerability because it corresponds to a documented weakness class that attackers actively exploit. A method that catches an exception and does nothing with it, or a variable declared but never read, gets classified as a quality issue because it represents a defect in the code's correctness or clarity, not a route for external compromise. Both categories can carry a Critical, High, Medium, or Low severity label, which is part of why teams sometimes conflate them — a "High" quality issue and a "High" security issue look similar in a summary view even though they mean very different things operationally.
How Does the Engine Decide Which Bucket a Finding Belongs To?
Each detection rule in Snyk Code's rule database carries category metadata set at authoring time, and that metadata — not a runtime judgment call — is what routes a match into the security or quality bucket. Snyk Code's static analysis engine parses source into an abstract syntax tree and builds data-flow and control-flow graphs to trace how values move through a program — for example, following a value from an HTTP request parameter through to a database call to determine whether it reaches a sensitive "sink" without sanitization. Rules that describe this kind of tainted-data-reaching-a-sink pattern are authored and tagged as security rules with an associated CWE. Rules that describe structural or stylistic problems — dead code, redundant conditions, resource handles that are opened but never closed — are authored and tagged as quality rules, generally without a CWE mapping because they don't correspond to a recognized attacker technique. The AI layer Snyk describes as a hybrid of symbolic reasoning and machine learning is used to improve precision within each category — for instance, reducing false positives on taint paths by learning from patterns in verified fixes — but the category assignment itself comes from the rule's own metadata, not a separate confidence score deciding "this is security" after the fact.
Where Did This Detection Approach Actually Come From?
Snyk Code's engine traces back to DeepCode, a static analysis company spun out of research at ETH Zurich, which Snyk announced it had acquired on September 14, 2020. DeepCode's pitch at the time was that traditional SAST tools produced too much noise because they relied on rigid pattern matching, and that training a system on a large corpus of real-world open-source repositories and their commit histories — including how developers actually fixed bugs — would let the engine recognize meaningful patterns rather than surface-level syntax matches. Snyk rebranded the technology as Snyk Code and integrated it into the broader Snyk platform alongside Snyk Open Source (dependency scanning), Snyk Container, and Snyk Infrastructure as Code. That lineage is relevant to the security-versus-quality split because it explains why the rule set was built with two distinct purposes from the start: DeepCode's original research explicitly covered both bug-finding (quality) and vulnerability-finding (security) as separate but related problems, and Snyk carried that dual structure forward rather than building a security-only scanner and bolting quality checks on later.
Does Severity Get Scored the Same Way Across Both Categories?
No — both categories use the same four-tier Critical/High/Medium/Low scale, but what feeds into that score differs by category. For a security finding, severity reflects factors tied to exploitability and impact: the type of weakness (a remote code execution pattern rates higher than an information disclosure pattern), whether tainted input can reach the vulnerable sink with minimal sanitization in between, and the potential blast radius if exploited. For a quality finding, severity reflects impact to the codebase itself — how likely the pattern is to cause a runtime bug, how much it degrades maintainability, or how far it deviates from language-specific best practice — with no exploitability dimension because there is no attacker path to model. This is why a "Medium" security issue and a "Medium" quality issue can require entirely different responses: the former might justify blocking a release, while the latter is often routed to a backlog for the next refactor cycle.
Can Teams Triage or Gate on Each Category Independently?
Yes — Snyk Code exposes the two categories as independently filterable in the web UI, IDE integrations, and API/CLI output, which lets teams build different workflows around each one. A common pattern is configuring CI/CD policies to fail a build only on security findings above a chosen severity threshold (for example, blocking on High and Critical security issues) while leaving quality issues visible but non-blocking, so they surface in code review without stalling a deploy pipeline. This separation is also what lets a security team report a metric like "security issues resolved per sprint" without that number being diluted by unrelated maintainability cleanup, and lets an engineering-quality initiative track code-health trends without security noise skewing the count.
How Safeguard Helps
Snyk Code's split between security and quality findings is useful precisely because it happens inside a single tool scanning first-party source. The harder problem for most organizations is that first-party source is only one slice of what actually ships — the rest is open-source dependencies, container base images, build pipelines, and third-party packages, each with its own scanners producing their own severity scales and their own definitions of "critical." Safeguard's software supply chain security platform is built to sit across that whole surface: it ingests findings from SAST tools like Snyk Code alongside SBOM data, dependency provenance, and build-pipeline integrity signals, and correlates them into one risk view instead of a dozen disconnected dashboards. That matters concretely when a Snyk Code security finding in application logic touches a code path that also depends on a vulnerable open-source package — Safeguard can surface that connection instead of leaving two teams to independently triage what is really one exposure. For organizations already relying on Snyk Code's security-versus-quality classification to keep their AppSec backlog focused, Safeguard extends that same discipline — separating what's actually exploitable from what's just noise — across the entire software supply chain, not just the code a scanner can see.