Product Updates

Starting on March 6, 2026, we’re introducing Credentials Manager to help you store and manage sensitive authentication data separately from your target configurations. This update simplifies secrets management and allows teams to share authentication setups without exposing actual credentials.

The Credentials Manager replaces the Secret Obfuscation feature, which is now discontinued.

Running dynamic application security testing (DAST) scans requires sensitive information like logins, passwords, and tokens. Previously, these were stored directly within each Target. This made it difficult to manage authentication across multiple targets and made regular password rotation time-consuming. We built this to provide a centralized way to manage these secrets more efficiently.

The Credentials Manager introduces several changes to how you handle sensitive data:

• Centralized storage: You store credentials in a dedicated place, keeping them separate from your Target configuration.

• Write-only secrets: Some credentials are write-only. You can use these in authentication settings, but the values remain hidden after you save them.

• Flexible configuration: You can still create credentials for a single Target if you do not want to save them to the central Credentials Manager.

To learn more, visit How to manage target authentication credentials in Snyk API & Web.

We have released a new CLI hotfix (v1.1303.1) to address the following:

• IDE plugins: Fixes an issue where customers using our most recent IDE plugins release may encounter scans not triggering when Snyk Code is enabled in their IDE settings

• UI: Fixes an issue where JSON output was rendered twice to disk and to standard output

• MCP: Fixes an issue where Snyk rules were not written locally

Release notes can be found here.

If you have any questions, please don’t hesitate to reach out to the Snyk support team.

We are pleased to announce the release of new stable versions for our IDE plugins.
The new versions are:

• Visual Studio Code v2.29.0

• JetBrains v2.20.0

• Eclipse v3.8.0

• Visual Studio v2.8.0

This release is focused on enhancing stability and reliability, with key updates including:

• Better error messages when the CLI binary is corrupt

• Bug fix for JetBrains plugins to prevent crashes on startup

• Improvements for “New” issues view when using non-standard git configurations

• Improved org selection when an empty org is specified

Along with additional bug fixes, security updates, and improvements.

Please refer to the changelog for each of our plugins for a more detailed list of additional bug fixes and enhancements. You can learn more about the Snyk IDE plugins in our Learn resources.

If you have any questions, feel free to reach out to the Snyk Support team.

We are introducing Learning Programs in Snyk Learn, now available in early access (EA) for Learning Management Add-On customers. This feature allows you to curate specific paths of security education and product training, then assign them to groups of users from across your Snyk Tenant. You can build these tracks using our existing catalog, enroll participants in bulk, and monitor progress in real time. To help maintain high completion rates, we have also added automated email reminders.

We want to help you move beyond ad-hoc training by providing a structured way to automate security onboarding, meet compliance requirements like SOC2 or ISO27001, and drive targeted remediation. By grouping lessons into formal programs, we make it easier for security leaders to ensure that the right teams are learning the right skills at the right time.

Tenant admins can now manage these initiatives directly from the Snyk Learn dashboard under the Management menu. You can delegate management to team leads or security champions by creating a custom role via the Snyk API with specific permissions. Your developers will see a dedicated "assigned programs" section on their dashboard with a familiar Learning Path experience to guide them through their required lessons.

While in Early Access, learning programs are limited to 300 users per program, and programs must be created using the UI. Throughout Early Access, we will be rolling out workflow enhancements and additional reporting capabilities via Snyk Learn Program Reports.

You can provide feedback through in-app pop-ups, to your Snyk account team, and to support@snyk.io.

To get started, visit Snyk Learn or our Snyk Learn User Documentation for more information.

Starting February 25, 2026, we are introducing snyk_package_health_check for Snyk Studio. This update brings Secure at inception protection to dependency selection in agentic development workflows, ensuring that AI coding assistants evaluate open-source packages before they enter your project.

As AI coding assistants increasingly select and install dependencies autonomously, security must move earlier in the workflow. This feature enables AI agents to use insights from the Snyk security database to evaluate packages at the moment they are chosen.
This functionality is available in an Experimental profile for several supported ecosystems, including npm, PyPI, Maven, NuGet, and Golang.

New capabilities

• Package health checks across four dimensions: Security, Maintenance, Community, and Popularity.

• Clear guidance outcomes to help manage agent behavior, including Healthy, Review recommended, Not recommended, and Unknown/insufficient data.

• Policy-driven guardrails that allow Organizations to require health checks, pause on risk signals, block unsafe packages, and enforce human approval.

Why this matters

Evaluating package health before installation reduces supply chain risk, which is critical because AI agents can introduce dependencies at scale. Integrating snyk_package_health_check into MCP extends your security policies and governance directly into AI-assisted development.

If you have any questions, please reach out to the Snyk Support team. To learn more about snyk_package_health_check, visit the Snyk documentation.

We are pleased to announce the latest stable Snyk CLI release, v1.1303.0.

We are introducing the following key improvements in this version. To learn more about bug fixes and additional enhancements beyond what is highlighted below, please reference the full release notes.

This update includes the following:

• Snyk Open Source

  • Multiple enhancements to sbom test

    • JSON output will now include the additional fields (isDisputed, severityBasedOn, alternativeIds) for richer vulnerability context and reporting.

    • For Maven and npm projects, new dependency scope information (for example, dev vs. production) helps teams understand which vulnerabilities affect production code.

• Additional changes

  • AIBOM users can now persist their AIBOMs to their Snyk Organization using --upload and --repo flags.

  • Redteam users can view an HTML report for easier stakeholder review.

Release notes can be found here.

If you have any questions, feel free to reach out to the Snyk support team. We encourage everyone to upgrade to the latest version to take advantage of these new features and improvements.

We are excited to share that starting on 9 March, we will introduce significant coverage and quality improvements to Reachability for JavaScript, Java, and Python. By deepening our mapping of cross-package relationships and upgrading our underlying ecosystem analysis, we've increased both the precision and recall of our engine.

Why Reachability matters 

Snyk’s Reachability analysis scans your source code to determine if the specific code that makes a vulnerability exploitable is actually being called, either directly or transitively.

This critical context allows you to:

• Gauge exploitation likelihood: Easily distinguish between theoretical risk and actual, exploitable risk.

• Prioritize effectively: Cut through the noise and focus your developers on the vulnerabilities that matter most.

• Drive risk-based security: Use Reachability independently or alongside the Snyk Risk Score to build a comprehensive risk-prioritization strategy.

What this release means for you 

By addressing both false positives and false negatives, we are ensuring your findings are more accurate and actionable than ever before. As we release these changes, you may notice significant fluctuations in the reachability and Risk Score for issues in the following project types: npm, pnpm, yarn, maven, gradle, pip, pipenv, and poetry. 

For more information on how to optimize your workflows with these new improvements, please check out our user documentation.

We’ve added new analytics functionality to the Risk Exposure report to help you better understand and manage your security posture. We’re introducing clickable objects within the Risk Breakdown table that allow you to drill down into specific issues and assets directly from the report. To provide more context, we’ve also added tooltips for categories such as Baseline Issue, Non Preventable Issue, Preventable Issue, and Other New Issue. Additionally, the Risk Exposure Trend now includes new viewing options, allowing you to filter open issues by Snyk product, exploit maturity, and top organizations (Orgs).

We’re moving this report from early access to general availability (GA) to provide a more comprehensive view of your application security (AppSec) risk. By aligning widget filters and adding trend data for specific products and exploit maturity levels, we're making it easier for you to pinpoint exactly where risk is originating and how it's evolving over time.

You can now interact with the Risk Breakdown table and trend lines to open detailed drawers for specific issues and impacted assets. This makes it faster to investigate why a trend has changed without leaving the report. The new tooltips clearly define how we categorize different issue types, ensuring your team has a shared understanding of risk definitions. If you manage multiple organizations, the new "Top Orgs" view helps you quickly identify which areas of your business require the most attention based on open issue counts.

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 are excited to announce the general availability of Broken Object Level Authorization (BOLA) detection for OpenAPI targets, starting today. This feature uses artificial intelligence (AI), particularly large language models (LLMs), to identify unauthorized data access risks. You can now test for these vulnerabilities using the built-in API Normal or API Full scanning profiles.

BOLA is ranked as the primary risk in the OWASP API Top 10. By automating the detection of this complex vulnerability, we help you move beyond manual security reviews and reduce the risk of data leaks. Our goal is to provide proactive protection for your APIs by identifying authorization flaws before they can be exploited.

To use this feature, you must configure API target authentication for two separate users. The second user acts as the attacker and should have the same or lower privileges than the first user, and should not have access to the first user's resources. Once configured, our scanning engines will automatically attempt to detect if the second user can inadvertently access data belonging to the first, providing clear visibility into potential authorization gaps.

To learn more, visit How to set up your target for testing BOLA vulnerabilities? in our user documentation.