Product Updates

We added a new Known Exploited Vulnerabilities (KEV) filter to help you identify risks that the Cybersecurity and Infrastructure Security Agency (CISA) tracks as already exploited in the wild. While we already allow you to filter vulnerabilities and Common Vulnerabilities and Exposures (CVE) by their exploit maturity level, this update specifically targets the CISA KEV catalog. You can find this filter on any page where issue filters are available to help you manage your security backlog.

The CISA KEV catalog is a vital resource for meeting global security standards. For instance, FedRAMP requires strict remediation service-level agreements (SLAs) for any vulnerability listed in this catalog. Furthermore, the European Union Cyber Resilience Act (EU CRA) mandates that organizations actively monitor for vulnerabilities found in the CISA KEV catalog. We’re providing this filter to automate this visibility and help you maintain compliance across different regulatory environments.

You can now isolate vulnerabilities within the CISA KEV catalog with a single click. This helps you prioritize remediation based on documented real-world exploitation rather than just theoretical risk. By using this filter, you ensure your team addresses the specific issues that auditors and regulators prioritize, reducing the manual effort needed to cross-reference your backlog against federal and international mandates.

To learn more, visit Issue vulnerability details in our user 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.

Python is at the heart of the modern AI revolution but for many developers the packaging ecosystem has felt like a bottleneck: burdened by slow installs and fragmented tooling. The emergence of uv has changed that, offering a high-performance alternative that has quickly become the industry standard.

Today, we are excited to announce that Snyk is bringing native support for uv to the Snyk CLI, IDE, and GitHub Actions. This integration ensures that teams can embrace the speed of uv without ever having to trade off on security.

With this update, Snyk enables you to seamlessly integrate uv security scanning directly into your existing Snyk workflows, wherever you are using the CLI.

What’s supported?

Native uv support is currently in Early Access. During this phase, you can use the following commands to secure your uv projects via the CLI:

• snyk test: Scan your uv dependencies for known vulnerabilities.

• snyk monitor: Continuously monitor your project and receive alerts for new risks.

• snyk sbom: Generate a Software Bill of Materials for your uv-based applications.

In addition to the CLI, this support extends to the Snyk IDE extensions, MCP server, and GitHub Actions, providing security coverage wherever you code.

Getting started

If you were part of the closed beta, you can begin using these features immediately on the latest stable release of the CLI (v1.1304). Otherwise, please enable the preview by navigating to the Snyk UI and toggle the feature under Snyk Preview.

What’s next?

We are committed to full-ecosystem support for uv. While this release focuses on the CLI and developer tools, SCM support will follow in the upcoming months.

Documentation

Please see the documentation for more information.

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

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

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.