Product Updates

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

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'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’ve introduced the follow-scan command to the Snyk API & Web (DAST) command-line interface (CLI) starting with version 0.0.1a15. This update allows the CLI to wait for a scan to finish before your CI/CD pipeline continues. We've also added new configuration options that let you set time limits for scans and define specific vulnerability thresholds that will automatically fail a build. After each run, we provide a direct link to your results for faster triaging.

You can now automatically block high-risk code from progressing through your CI/CD pipeline. By using the latest CLI version, you gain native control over build failures without needing to manage complex workarounds or manual checks.

To learn more, visit Snyk API & Web CLI documentation.

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 have updated Snyk Container to support scanning for stripped Go binaries and those built using CGo. We have enhanced the scanner to use module-level analysis via .go.buildinfo, allowing Snyk to accurately identify dependencies even when debug information is removed or C libraries are used.

Historically, stripped binaries and CGo builds made it difficult for scanners to accurately parse dependencies, potentially leaving vulnerabilities undetectable. This update closes that visibility gap.

Users scanning Go containers may now see new vulnerabilities that were previously hidden due to the limitations of scanning these specific binary types. This ensures more complete security coverage for Go applications.

This improvement is available in Snyk CLI v1.1302.0 (preview and stable releases). Update your CLI to the latest version to ensure your Go container artifacts are fully covered.

We have introduced a new optimization mechanism to support scanning for enterprise-scale projects with massive dependency graphs. We added a graph pruning capability that allows scans exceeding the standard maxVulnPathsLimit to complete successfully.

Certain large projects generate dependency graphs with over 100,000 vulnerable paths. Previously, these massive graphs hit a hard limit in the Snyk Container monitor, causing the scan to fail completely for large enterprise workloads.

This unblocks scans for large projects. Users who were previously unable to monitor their largest containers due to timeout or complexity errors can now successfully scan them.

CLI users can use the --prune-repeated-subdependencies flag immediately. Customers using container registry integrations should request that the corresponding Feature Flag be enabled for their organization by contacting support.

We have added support for scanning Node.js applications that use pnpm as their package manager within container images. When you scan a container image, Snyk will now automatically detect pnpm-lock.yaml files. If your project contains both a lockfile and node_modules, we will use the lockfile to generate a more accurate dependency graph.

Previously, Snyk Container scans for pnpm-based projects relied on node_modules analysis or less granular detection methods. As pnpm adoption has grown due to its speed and disk efficiency, we wanted to ensure container scanning provided the same depth of coverage as our CLI and SCM integrations.

This update brings container scanning into parity with other Snyk integrations. Users will see improved accuracy in their scan results without needing to change any configurations.

This feature is available in the latest Snyk CLI release. To learn more, visit the Supported workloads page in our user documentation.