Product Updates

Key Capabilities of Unified Navigation

Grouped Navigation for Faster Orientation Snyk's menu is now organized around how security work actually happens. Related items are grouped, so you spend less time hunting through menus and more time in context.

Context-Aware Shortcuts Snyk now recognizes what you are working on. This reduces the steps for common workflows from 8 clicks down to just 2 or 3, allowing you to move at the speed of development.

The Core Problem: Navigational Complexity

Currently, security data is spread across disconnected areas, forcing users to hold a mental map of the product just to find what they need. Finding and understanding a specific security issue requires manual effort and several steps. Users often face:

• Action Overload: An overwhelming volume of results without a clear path to the most important task.

• Context Switching: Constant jumping between code, container, and infrastructure views to see the full picture.

• High "Click Tax": Simple tasks like finding a specific vulnerability can take 8 or more clicks.

The new Snyk Unified Navigation addresses this directly — by consolidating related items, reducing top-level noise, and adapting what's visible to the task at hand. The goal is simple: less time navigating, more time fixing.

The Value to Your Security Program

By unifying the interface, we aim to help organizations achieve three main outcomes:

• Reduce Triage Time: Cut the time spent reviewing alerts through faster navigation.

• Increase Efficiency: Enable developers to find and fix critical issues faster.

• Scale Security Teams: Allow small security teams to manage significantly more projects by removing manual navigation hurdles.

Snyk 2.0 platform improvements

Nobody likes a cluttered PR backlog. That's why Snyk now automatically closes Open Source Fix PRs if the vulnerabilities they target are no longer present in your project.

Whether a developer manually applied a fix, removed the dependency, or a transitive update resolved the issue, Snyk will catch it during your next recurring test and close the outdated PR. We will also drop a comment on the PR explaining exactly which issues were resolved, ensuring your team always has the right context without the extra noise.

How it works:

• Snyk checks your open Fix PRs during your regular recurring tests.

• If the targeted issues are gone—whether the dependency was removed, updated transitively, or fixed manually—the PR is automatically closed.

• Snyk leaves a comment on the PR listing the resolved issues so your team knows exactly why it was closed.

This update gives you a cleaner, more actionable PR pipeline with zero extra effort.

Get Started Today This feature is going live as an opt-in starting today. Just navigate to the Snyk Preview panel to get started, and we'll begin closing up to five obsolete PRs from your backlog per day. As we move towards General Availability, we'll be bringing you the ability to configure that daily limit to best suit your team's workflow.

Please note that this feature is opt-in for Early Access, but once we move to General Availability, it will move to opt-out. This feature is tentatively scheduled to move to General Availability on June 15, 2026.

And stay tuned—there is a lot more to come in our ongoing efforts to revolutionize the Snyk PR experience!

We’ve launched an Active security incident assessment banner to help you manage major zero-day events. When our Security team identifies a high-severity zero-day vulnerability in a widely used package, we’ll trigger a dedicated banner at the top of the Zero Day report. This assessment provides a look at your exposure, including the total number of assets needing triage, assets cleared, and the specific open-source (OSS) packages involved.

During a newly discovered security incident, teams need to quickly determine which assets may be affected and where to start investigating.

The active security incident assessment provides earlier visibility into repository exposure, helping teams:

• Understand the potential blast radius of an incident

• Identify assets requiring investigation

• Prioritize remediation and response faster

During an active incident, you can now immediately see which assets may contain vulnerable packages through the assets needing triage metric. As you remove or update impacted dependencies, SCM-based scans for Snyk Open Source will automatically move those repositories to assets cleared, giving you a record of your progress.

To learn more, visit Zero-Day report in our user documentation.

We’ve added new secure coding content, Snyk platform training, and expanded Snyk Learn coverage to help your security engineers and developers stay ahead of the latest risks.

We’ve included direct links to every new and updated lesson so you can easily share them with your team. You can also assign them directly through the Snyk Learning Management Add-On.

Security lessons

• We are creating lessons for the new OWASP Top 10 for Agentic Applications, with the first 4 lessons available.

  • [New] Agentic 01 - Agent goal hijack

  • [New] Agentic 02 - Agent tool misuse

  • [New] Agentic 03 - Identity and privilege abuse

  • [New] Agentic 04 - Agentic supply chain vulnerabilities

• [New] Cross-origin resource sharing

Snyk platform lessons

• [New] Snyk Billing and Credit Usage - a new lesson on how credits function within the Snyk platform and how to track and manage them in the Billing module.

• We have refreshed the following lessons to ensure all content reflects our current platform and products, also providing a streamlined learning experience:

  • [Updated] Prioritizing issues with Snyk

  • [Updated] Integrations for asset management and discovery

  • [Updated] Reviewing Inventory for asset management and discovery

  • [Updated] Asset Dashboard report for asset management and discovery

  • [Updated] Policies for asset management and discovery

  • [Updated] Overview of Snyk for asset management and discovery

  • [Updated] Snyk terminology for asset management and discovery

  • [Updated] Snyk Platform using Snyk Analytics

  • [Updated] Application context with ServiceNow® CMDB

  • [Updated] Application context with Backstage software catalog

Expanded framework & language coverage

We’ve also expanded Snyk Learn content to cover more of your tech stack:

• We have added support to almost 50 lessons for Ruby

• We have added support to 30 lessons for Rust

We're updating the stable Export API (version 2024-10-15) to include more granular filtering for the issues dataset. You can now filter your export request payloads using additional parameters, including issue status, issue type, and project origin. We've also added support for advanced filters such as common vulnerabilities and exposures (CVE) ID, reachability, and National Vulnerability Database (NVD) severity to help you refine your reporting.

We want to make data consumption more manageable and relevant for your specific workflows. Previously, these fields were available as export columns but could not be used to filter the initial request. By adding these parameters directly to the API contract, we're enabling you to reduce noise and achieve parity between our user interface (UI) reporting and your automated exports.

You can now customize your issue exports by applying the following new filters to your API requests:

• ISSUE_STATUS: Filter by Open, Resolved, or Ignored.

• ISSUE_TYPE: Limit results to vulnerabilities or licenses.

• PROJECT_ORIGIN: Filter by source, such as CLI, GitHub, or Jenkins.

• PROJECT_TARGET_REF: Target specific branches or artifacts.

• CVE: Search for a specific vulnerability ID.

• NVD_SEVERITY: Filter based on external severity ratings.

• REACHABILITY: Separate reachable from unreachable vulnerabilities.

• PROJECT_TARGET_DISPLAY_NAME: Use human-readable names for your reports.
  

To learn more, visit Export in our user documentation.

We’re adding an analytics overview widget that tracks the total number of Snyk projects being monitored. This key performance indicator (KPI) is available in the Widget selector, allowing you to add it to your saved dashboards. This update helps you visualize the total count of projects being continuously monitored for open-source vulnerabilities and license issues, after you use the snyk monitor command.

We want to provide better visibility into the scale of your security program. By adding a dedicated KPI for monitored projects, we make it easier for you to track the coverage of your continuous monitoring.

After you log in, navigate to your analytics dashboard and open the Widget selector. Select the new Projects Monitored KPI to add it to a Saved dashboard. This provides an immediate view of how many projects are being continuously monitored for vulnerabilities and license issues.

To learn more, visit Analytics or Snyk CLI commands in our user documentation.

We’re introducing a new Download CSV feature to help you export your data directly from the interface. Starting today, you can download a comma-separated values (CSV) file that matches your current table view, including any active filters or hidden columns. We'll follow this implementation soon after, with an enhanced version that gives you even more flexibility, by allowing you to choose from a wider range of fields, which ones to include in your CSV file. 

We recognize that managing security data often requires analysis outside of our platform. Previously, moving table data into other tools required manual effort or copy-pasting. We're adding this functionality to save you time and provide a powerful way to leverage your data for custom reporting and internal manipulation without the manual overhead.

This feature is available to all users across all account plans. If you have access to a table, you can now download its data.

To learn more, visit How to export table data to CSV in our user documentation.

We're introducing a new permission called Change Finding State to give you more granular control over how your teams manage security findings. Previously, the Change Finding permission covered several actions: changing a finding's state, review status, assignee, labels, and adding notes. We've separated these capabilities so that Change Finding State now specifically handles changing a finding's state and review status, and the existing Change Finding permission now focuses on managing assignees, labels, and notes. To prevent any workflow interruptions, all built-in and existing custom roles that currently have the Change Finding permission will automatically receive the new Change Finding State permission.

We made this change to help you better implement the principle of least privilege within your security programs. We heard that many organizations need to allow team members to contribute to the triage process — such as by adding notes or labels — without granting them the authority to officially ignore a finding or accept a risk. By decoupling these actions, we provide the flexibility to define more specific roles for your developers and security analysts.

You can now create custom roles that allow users to add context to findings without giving them the ability to change the security posture of an application. For example, if you want a user to be able to add notes to a finding, you can assign them the View Target and Change Finding permissions, but if you want a user to be able to ignore or accept findings, they will now require the Change Finding State permission. While this update does not change current access for existing users, we recommend reviewing your custom roles to see if you can further restrict permissions.

To learn more, visit Understanding Permissions at Snyk API & Web in our user documentation.

We’ve updated Snyk Open Source license detection to use the latest  SPDX license list  (v3.28), upgrading from the previously supported version (v3.20).

This update improves license recognition across dependencies and reduces the number of licenses previously categorized as “Unknown”. With this change, Snyk can now recognize and surface additional standard SPDX licenses, enabling more accurate license compliance insights and allowing customers to define policies for these licenses directly.

What’s changed

• Updated SPDX License List support to the latest version, v3.28 (previously v3.20).

• Snyk Open Source license detection now recognizes additional SPDX licenses included in the latest version.

• Newly recognized licenses can now be managed in License Policies, reducing cases where licenses appear as “Unknown.”

Who’s affected

• This update applies to all customers using Snyk Open Source license scanning.

• Newly supported licenses will appear after the next dependency scan or project re-test.

Why this matters

Previously, some dependencies using valid SPDX licenses were categorized as “Unknown” because they were not yet supported by Snyk.

By expanding SPDX license coverage, this update helps teams:

• Improve the accuracy of license detection in dependency scans.

• Define policies for a broader set of open source licenses.

• Reduce manual investigation when licenses appear as “Unknown”.

If you have any questions about this update, please reach out to the Snyk Support team.

To learn more about licenses, visit the Snyk documentation.

We’ve updated how newly supported licenses behave in Snyk Open Source license policies.

When Snyk adds support for new licenses, they will now default to a severity of None and will not inherit the severity configured for the Unknown license type.

As a result, newly supported licenses will not generate findings unless a severity is explicitly configured in your License Policy.

What’s changed

• Newly added licenses now default to severity = None.

• Newly added licenses do not inherit the severity configured for the Unknown license type.

• These licenses will only generate findings if a severity is explicitly configured in your License Policy. These licenses will still be detected and visible in SBOMs and in your Project’s dependency data. 

• You can review and configure severity levels for newly supported licenses directly in your License Policies.

Why this matters

• This change makes license policy behavior more predictable and gives you full control over how newly supported licenses are classified.

• Previously, newly added licenses could inherit the severity configured for the Unknown license type, leading to unexpected findings when new licenses were introduced.

Recommended action

• If you rely on license policies to flag licenses in scan results, we recommend periodically reviewing your License Policies and assigning severity levels to newly supported licenses that are relevant to your organization.

If you have any questions about this change, please reach out to the Snyk Support team.

To learn more about licenses, visit the Snyk documentation.