Product Updates

This update will be available on October 26, 2026.

Snyk Code reports significantly more findings in this update. Affected projects will report the additional findings on their next scan.

Snyk Code now analyzes more deeply and more accurately in Java, Kotlin, Go, TypeScript, JavaScript, Python, C#, PHP and Ruby.

Go, TypeScript and JavaScript

Snyk Code reads the Project's own configuration to resolve imports. For Go, it reads go.mod, which defines the module path that a project's packages import each other through. For TypeScript and JavaScript, it reads tsconfig.json and jsconfig.json, which define path aliases.

As a result, Snyk Code now analyzes these projects more accurately and with greater depth.

PHP

Snyk Code corrects boolean typing in PHP analysis. Previously skipped findings now appear across cross-site scripting, path traversal, SQL injection and other checks.

Java

Coverage is added or improved for these libraries:

• Spring Data MongoDB

• AWS SDK for Java, DynamoDB

• AWS SDK for Java 2.x, DynamoDB

• AWS SDK for Java 2.x, DynamoDB Enhanced Client

• Apache Commons FileUpload

Snyk Code adds a Mass Assignment rule for Spring applications. It reports request data that binds directly onto a database entity. Path traversal detection is wider.

More detection

Snyk Code reports additional findings in these areas:

• Python: XML external entity injection.

• JavaScript: deserialization, XML external entity injection and zip slip.

• JavaScript, Bootbox: DOM-based cross-site scripting.

• JavaScript, d3: DOM-based cross-site scripting.

• C#: path traversal.

• Go: SQL injection.

• Go, AWS SDK for Go v2: path traversal through S3 object keys.

• Ruby: path traversal, and a new server-side request forgery rule.

Template file analysis and serverless analysis

Snyk Code analyzes template files and serverless applications more accurately and with greater depth, building on the September update. Both will yield additional findings in projects that use template engines or serverless frameworks.

Learn more in the Snyk Code documentation.

Snyk Code priority scores dropped by up to 200 points on September 1, 2026, for findings whose rule had a fix example.

What changed

A finding used to earn 200 of the 1,000 available priority score points when Snyk held a fix example for its rule. The August 17, 2026 release retired fix examples, and the scoring factor went with them. The removal became live on September 1, 2026.

Why

Fix-example availability describes Snyk's content coverage. It says nothing about the risk in your code. Two findings of the same severity could sit 200 points apart because one rule happened to have an example behind it. Priority score should rank findings by how urgently they need fixing, so we removed the factor.

What you saw

Snyk Code findings reordered when the factor came out. Every remaining scoring factor works as it did before, including severity, which still contributes the largest single share at up to 500 points. No finding was added, removed or re-rated.

We should have told you

The August 17 release notes said no action was required. That was wrong, and we apologize. We have added a check so that any future change to priority score appears in the release notes. The priority score documentation now lists the current factors.

Learn more in the Snyk Code priority score documentation.

Snyk Container will begin reporting vulnerabilities from the Go standard library for all customers. Scans of container images built from Go binaries identify the standard library version the binary was compiled with and report known vulnerabilities against it.

Affected images gain a new stdlib dependency in the dependency graph, versioned to the Go release used for the build, for example stdlib@1.25.10. Detection works for standard, stripped, and CGo builds.

No configuration is required, and reporting is enabled automatically for all organizations. Standard library reporting in the Snyk CLI requires v1.1303.2 or later.

This change is scheduled to take effect on October 7, 2026.

Snyk Container reported vulnerabilities in third-party Go dependencies, but not in the Go standard library itself, the HTTP, TLS, JSON, and other libraries that ship with the Go toolchain rather than being installed as dependencies. Those vulnerabilities were visible only indirectly, through distro advisories, so teams shipping Go binaries in containers had no reliable way to see them.

That left two gaps: one between what Snyk Container reported and what Snyk Open Source already reported for the same code, and one in real coverage for any Go application running in a container - this change closes both.

If you scan container images built from Go binaries, your vulnerability counts will increase. Each affected project gains a fixed number of new findings, determined by the Go version the binary was built with. Older Go releases carry more.

Building with a current Go patch release substantially reduces or eliminates these findings. Images built with Go 1.25.13 or later, or Go 1.26.6 or later, report no new vulnerabilities from this change. We recommend reviewing the Go versions used in your build pipelines ahead of the release date.

Considerations and known limitations:

• Snyk does not perform reachability analysis on standard library packages. Snyk reports all known vulnerabilities for the standard library version in your binary, rather than only those in packages your code imports. This is consistent with the approach taken by other container scanners.

• Findings that are not relevant to your application can be ignored in Snyk as usual

For more information, see Application vulnerabilities in Snyk Container and Snyk Open Source in the Snyk user documentation: https://docs.snyk.io/scan-fix-and-prevent/scan-with-snyk/snyk-container/how-snyk-container-works/application-vulnerabilities-in-snyk-container-and-snyk-open-source

We've expanded Snyk Open Source coverage with improved scanning capabilities. These updates help you close security gaps and manage dependencies more effectively. Key improvements include new support for the uv package manager and enhanced Go scanning for private dependencies.

uv SCM support

The uv package manager is an emerging tool in the Python ecosystem. Following our earlier CLI release, uv is now available in SCM integrations. You can import uv projects and workspaces, use PR Checks, and monitor your code directly from your connected Git repositories. You do not need to use the CLI for these tasks. uv joins pip, Poetry, and Pipenv as the fourth Python ecosystem with native support in Snyk Open Source.

To get started, enable this feature for your Groups and Organizations in Snyk Preview. You can find more details in the Snyk documentation.

Improved Go scanning

Our Go scanning improvements are now generally available. This update features support for private dependencies. Go teams that use private module proxies, such as Artifactory or Nexus, or private repositories via Broker, can now achieve the same depth of scanning available for public modules.

This ensures you have no blind spots in your dependency graph when a module lives behind authentication. We support both brokered and direct connections across all SCM integrations. We are rolling this out to all users over the next two weeks. You can learn how to configure private dependencies in the Snyk documentation.

We are excited to be launching Repo Monitor Configuration, which allows for management of repository coverage and monitoring configurations centrally across your entire Snyk Group from the Group-level Inventory page. This means you can monitor and manage repositories without navigating between individual Snyk Organizations.

Repo Monitor Configuration provides the following capabilities:

• Centralized asset monitoring: view monitoring status for all products, identify health status, and see required actions (such as enabling Snyk Code or resolving SCM integration issues) in one view.

• Bulk import: import repositories directly from the Group Inventory page into specific Snyk Organizations.

• On-demand retesting: trigger a retest for specific repositories directly from Inventory.

• Actionable error resolution: clear guidance ia available when testing fails due to integration issues or entitlements. After the underlying issue is resolved, testing resumes automatically.

We are excited to be launching Repository Content Sync (Early Access), an enhancement to how Snyk manages your imported repositories, ensuring your security posture always reflects your current codebase. This will be available to all Enterprise customers via Snyk Preview during the week of April 13th, 2026.

This new feature provides native, automated synchronization between your Source Code Management (SCM) tool and Snyk, eliminating the need for manual re-imports or external synchronization tools. It ensures:
New Files are Detected: Snyk automatically creates new projects and monitors manifest, Docker, or configuration files as they are added to your SCM.
Deletions are Reflected: Projects associated with manifest files deleted in your SCM are automatically deactivated in Snyk.
This functionality is available across all Snyk-supported SCMs.

Please note: Because this feature enables Snyk to automatically detect and potentially create projects from newly added files, customers who enable the feature are likely to see an increase in issues.

https://docs.snyk.io/scan-with-snyk/import-project-repository/snyk-repo-content-sync

We’ve launched broker context for Universal Broker, which is now generally available (GA). This new feature allows you to create specific contexts within a single Universal Broker client to modify any of the connection parameters based on the Organization (Org) or Group. You can now use many narrow-scoped source control manager (SCM) credentials rather than one broad credential, with configuration handled through our APIs or the snyk-broker-config tool.

We’re introducing this to provide more precise control over SCM visibility while reducing the overhead of managing multiple broker clients. By allowing you to overwrite parameters like SCM credentials at the Org level, we're making Universal Broker more flexible so that follow your own security policies when creating and providing credentials.

If you use Universal Broker, you can immediately start using this. Please note that this is not available for Classic Broker, so you’ll need to upgrade your Organizations to Universal Broker to take advantage of these improvements.

To learn more, visit Universal Broker or Universal Broker configuration resources in our user documentation.

We're excited to share that "improved .NET scanning" has moved out of Snyk Preview and is now generally available.

It is now easier than ever to onboard your .NET repos and gain visibility into your software supply chain with a high degree of accuracy.

This release covers both SCM integrations, the CLI and CI/CD plugins, and the IDE—providing consistent results across your software development lifecycle.

Private package and Snyk Broker support

Managing private dependencies is critical for enterprise development, so we have expanded support for self-hosted and private NuGet packages to ensure you have visibility into your entire software supply chain.

• Universal Broker: If you use the universal Broker, you can now fully scan private packages hosted on brokered connections to Artifactory and Nexus.

Enhanced accuracy and performance

We have updated the scanning architecture to use the native dependency resolution logic of the .NET ecosystem. By using the dotnet SDK directly to resolve dependencies,  Snyk now provides a highly precise representation of your project's dependency graph.

Expanded project support

We are removing the barriers to scanning complex configurations. You can now scan any SDK-style Project that builds successfully with the dotnet SDK. This includes broad support for standard build customization files such as global.json, Directory.Build.props, and Directory.Packages.props without requiring additional configuration.

Additionally, this update unlocks support for Windows-specific frameworks—including WPF and WCF—for environments running .NET SDK 10 or higher.

Availability

These improvements will be released gradually starting in mid-February and are designed to be non-disruptive to your existing workflows.

For more information on configuration and support, see the Snyk documentation for .NET.

We're excited to announce a series of coverage and quality improvements for Snyk Open Source across several key developer ecosystems, rolling out over the coming weeks. Our goal is to help you secure your applications as you evolve and scale them, keeping pace with the latest releases and reliably scanning large, complex projects.

Improved SCA Coverage

We are committed to keeping up with the rapid pace of ecosystem updates. By broadening our support for the latest language versions and library structures, we help ensure your projects remain modern and protected without any friction.

Yarn 4

Snyk now supports Yarn 4 in both the CLI and the SCM integrations.

• Availability: CLI support is available on January 14 in version 1.1302.0, with a gradual SCM rollout throughout January.

• Note: Fix PRs and Upgrade PRs are currently not supported for Yarn workspaces.

• No action required: Projects that previously failed now successfully scan.

Ruby 4

Snyk now supports Ruby 4 in both the CLI and the SCM integrations.

• Availability: Support for both the CLI and SCM becomes available the week of January 21..

• No action required: Since the Ruby version is selected based on your Gemfile, no customer action is needed to begin using this.

PHP 8.5 & Swift 6.2

In addition to the above, we are pleased to announce upcoming support for PHP 8.5 and Swift 6.2 to ensure our users on the bleeding edge of these ecosystems remain secure.

Improved vulnerability coverage

We’ve enhanced our coverage for Go by adding vulnerabilities impacting packages in the Go Standard library to our vulnerability database. Previously, these vulnerabilities were not supported they are now detectable in both the CLI and SCM integrations.

• Availability: SCM and CLI support will become available throughout January.

Improved Quality

Beyond just supporting new versions, we are constantly refining our underlying scanning technology. These "under the hood" improvements focus on making scans faster and more resilient, especially for resource-intensive modern workloads.

Python (pip) Performance Improvements

We've introduced significant performance improvements for Python pip projects using SCM scanning. Previously, large projects—including those using AI and ML libraries such as pytorch—occasionally failed to resolve dependencies during scans. This problem has been resolved, helping you secure your Python applications.

• Availability: SCM rollout is happening throughout January, with CLI support following  in March.

We've enhanced our Docker Hub integrations by adding GitHub App support. This update allows you to attach a Dockerfile to your Snyk Container images directly through your GitHub Cloud and GitHub Server App integrations.

Attaching a Dockerfile gives you more precise fix advice, including smarter base image recommendations for both major and minor upgrades, and a wider range of alternative upgrade paths. This new capability means Snyk gains deeper context about your image during scans, leading to more actionable and tailored recommendations.

No explicit action is required to enable this feature. To start, simply navigate to your Snyk Container image Project settings. There, you can use the Configure Dockerfile option to select the appropriate Dockerfile via your GitHub App integration.

To learn more, visit Detect Vulnerable Base Images from your Dockerfile.