Product Updates

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 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 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’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’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.

You can now scan COBOL codebases for security vulnerabilities using Snyk Code. This update helps large Organizations, particularly in retail and financial services, include legacy mainframe applications in their security programs and meet compliance or audit requirements.

Many Organizations manage significant COBOL codebases that previously lacked automated security scanning support. By adding COBOL support to Snyk Code, you can identify risks earlier in the development process and maintain a consistent security posture across your entire application portfolio.

Supported features

This release provides security coverage for standard COBOL, including CICS constructs.

Key features include:

• Support for .cbl, .ccp, .cob, and .cpy file extensions.

• 15 security rules across cryptography, injection, secrets, and error handling.

• Integration with the Snyk web UI for vulnerability management.

How to get started

You can access this feature through Snyk Preview.

Learn more about Snyk Codes COBOL support int he documentation.

Snyk Code expands Ruby analysis with interfile data flow support

Starting April 7, 2026, Snyk Code includes interfile data flow analysis for all Ruby Projects. This update moves beyond single-file analysis to detect vulnerabilities that span multiple files, providing a more accurate assessment of your code.

Improve Ruby on Rails security

Ruby on Rails applications often distribute logic across models, views, and controllers. By analyzing data flows across the entire codebase rather than individual files, Snyk Code identifies complex vulnerabilities that were previously difficult to detect. We've also refreshed the Ruby on Rails ruleset to provide better coverage for modern development patterns.

Key enhancements

• Interfile analysis:

  You can now trace data flows across multiple files in all Ruby Projects scanned by Snyk Code.

• Updated ruleset:

  We've improved the Ruby on Rails rules to ensure more comprehensive vulnerability detection.

• Zero configuration:

  This feature is active by default for all customers on April 7, 2026, and requires no manual setup.

Support for security teams

These improvements help security teams perform more effective risk assessments on large Ruby codebases. By closing the gap on interfile support, Snyk Code provides the same depth of analysis for Ruby as it does for other major languages.

Because analysis quality is enhanced, you may notice a change in your scan results, including new true positives and the removal of previous false positives.

For more information, you can review the current Ruby and rules documentation at https://docs.snyk.io.

Snyk API & Web MCP Server brings even more security to your IDE

You can use the Snyk API & Web MCP server to bring Snyk security capabilities directly into your AI-native development environment. By using the Model Context Protocol (MCP), you can use natural language to onboard targets, configure DAST authentication, scan targets, and triage vulnerabilities without leaving your IDE.

Security workflows often require manual effort and constant context switching. We built the Snyk API & Web MCP server to eliminate this friction. Previously, setting up and onboarding new targets required significant manual work. This integration simplifies these processes and removes the need for security plumbing between tools.

This release benefits Appsec and Dev Teams using MCP-enabled tools like Claude Desktop, Cursor, or Windsurf.

• From UI-heavy to chat-native: Instead of navigating menus to set up a scan, you can tell your assistant to automatically onboard and configure a new Snyk API & Web target

• Automated authentication: Use AI to help generate and implement the authentication scripts required for deep web scans.

Learn more about these capabilities in the Snyk API & Web MCP Server documentation.

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

• Security Fixes

  • We have implemented a fix for a vulnerability identified in our underlying gRPC library

• Snyk Open Source

  • Optimized Privilege Evaluation: Resolved a bug where the CLI repeatedly checked user feature flags when scanning multiple Go projects, resulting in smoother performance.

  • Enhanced PackageURL Handling: Fixed an issue where Go projects using a replace directive with relative paths would encounter formatting errors.

• Snyk Container

  • Go Standard Library: This update introduces expanded support for the Go Standard Library within Snyk Container scans.

• Snyk Evo (Agent Red Teaming)

  • Attack Profiles: Users can now leverage the --profile flag to choose from pre-configured attack goals, including fast, security, and safety profiles.

  • Improved Terminology: We have updated our internal naming conventions for goals, strategies, and attacks to provide a more intuitive user experience.

  • Improved Onboarding: Interactive wizard to guide users through Agent Red Teaming configuration and setup.

Release notes can be found here.

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