Product Updates

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.

We’ve also improved the report interface by expanding the selection filters and adding detailed breakdown charts for the issues backlog.

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

Additional usability updates to the Zero day report now enable you to better view applied filters, filter by open or closed issues within the issue drill-down drawer, and view the backlog trend line across multiple events to see exactly how previous zero-day incidents are affecting your long-term security posture.

To learn more, visit Zero-Day report, Snyk Vulnerability Database, or Snyk Open Source 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.

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 Early Access launch of Breakability Analysis for Snyk Pull Requests, furthering our mission to help developers fix vulnerabilities without slowing down innovation.

We understand that the "fear of breaking the build" is a major blocker to keeping dependencies up to date. Updating a library to fix a security issue shouldn't feel like a gamble. That’s why we have introduced a new predictive risk assessment to help you distinguish between a quick fix and a complex upgrade.

Starting today via Snyk Preview, Snyk will analyze proposed dependency upgrades and assign a Breakability (Merge) Risk Score directly within the PR description:

• 🟢 Low Risk (Safe to Merge): We have high confidence the upgrade contains only non-breaking changes (e.g., security patches or EOL runtime drops). These are strong candidates for auto-merging.

• 🟡 Medium Risk: Caution is advised due to ambiguous change log data or environmental factors.

• 🔴 High Risk (Action Required): We have identified likely breaking changes (e.g., API removals) that likely require code refactoring. These should be prioritized for a dedicated sprint.

This insight allows your team to burn down the backlog of "Low Risk" fixes quickly while preventing "High Risk" upgrades from silently breaking your builds.

This feature is available now in Early Access for supported ecosystems. You can enable it for your organization by navigating to Settings > Snyk Preview.

Read more about the assessment here.

Enjoy merging with confidence!

P.S. Please note that at this time, Breakability Analysis involves sending package information, including the current and proposed upgrade version, to an LLM. AI generated content may contain errors and should be reviewed for accuracy before use.

We’ve completed the migration of Snyk Advisor into security.snyk.io, bringing package intelligence directly into the security experience.

Package pages now include Snyk Advisor insights alongside vulnerability data, providing a more complete and consistent view of open-source package health.

What’s new

• Snyk Advisor metrics - Popularity, Maintenance, Security, and Community - now appear directly on package pages for supported ecosystems.

• Package health insights can be explored without leaving security.snyk.io.

• Advisor URLs now redirect to their corresponding package pages on security.snyk.io.
  

These updates make it easier to evaluate open source packages in context, supported by the same trusted data that powers Snyk Advisor.

To explore the updated experience, visit any package page on security.snyk.io. For more details, see Snyk Docs and the Blog post.

We are excited to share that we've made several improvements to how you test CycloneDX and SPDX SBOM files with Snyk, now available in Early Access for Snyk Open Source and Snyk Container.

These changes give you greater feature parity and a more consistent experience across your CLI testing workflows.

Here's what you can expect in Snyk CLI version 1.1302.0 and greater:

• The snyk sbom test command no longer requires the use of the --experimental option.

• You can now use previously unsupported options, including --severity-threshold, --reachability, --reachability-filter. These additions provide more granular control over your SBOM scanning results.

• Findings are returned by default in a human readable output and now include any applicable enrichments such as Reachability, Policy, Ignores, and Fix Advice.

• When you use the --json option, findings will be returned in a new JSON schema.

• We've also introduced clearer error messages, helping you quickly understand and resolve issues if Snyk is unable to test your SBOM file.

To minimize disruption to your workflows, we recommend reviewing your current integration and making any necessary changes prior to updating.

For those using Snyk CLI versions 1.1301.0 and below, the --experimental flag remains supported, and findings are returned in the previous format.

For more details, please refer to our User Docs.

We are pleased to announce the latest stable Snyk CLI release, v1.1302.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 Container

  • Support for OCI images with manifests missing platform fields

  • Container scan support for cgo and stripped Go binaries

  • Added pnpm lockfile support

• Snyk Open Source

  • Improved PackageURLs in SBOM documents for go.mod projects

  • Added support for deb, apk, and rpm in SBOM test

  • Added PackageURL information to go.mod dependency graphs for snyk test

  • Added support for poetry development dependencies

• Additional changes

  • MCP Scan is now part of the Snyk CLI, allowing you to test the supply chain of agent-based developer tools like Cursor and Claude Code.

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.