Product Updates

We are pleased to announce Snyk CLI release, v1.1307.4

This release contains fixes and minor improvements. To learn more beyond what is highlighted below, please reference the full release notes.

This update includes the following:

• New experimental snyk studio command that sets up Snyk Studio in supported AI coding tools (Cursor, Claude Code, Codex, Copilot, Gemini, Kiro, and Windsurf), so the code they generate gets scanned in the background as it's written. This direct integration replaces the need for separate setup scripts (https://github.com/snyk/studio-recipes). Run snyk studio install --experimental to get started.

• New snyk fix --agentic filtering flags: --severity-filter to fix only the severities you choose, --breakability-filter to fix only Open Source upgrades with the breakability you choose, and --exclude-ids to fix everything except the issue IDs you list.

• snyk fix --agentic now keeps a failed fix's changes by default so you can review them, rather than reverting automatically. Pass --enable-revert to restore the automatic rollback behavior.

• Fixed an issue where the --iac, --docker, --container, and --code flags on snyk test could be silently dropped for organizations on the unified test API, causing scans to fall through to an open-source test instead (which could fail with "No supported files found" or scan the wrong target). These flags now route to the correct scan again.

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

Snyk Code priority scores dropped by up to 200 points on September 1, 2026, for findings whose rule had a fix example.

What changed

A finding used to earn 200 of the 1,000 available priority score points when Snyk held a fix example for its rule. The August 17, 2026 release retired fix examples, and the scoring factor went with them. The removal became live on September 1, 2026.

Why

Fix-example availability describes Snyk's content coverage. It says nothing about the risk in your code. Two findings of the same severity could sit 200 points apart because one rule happened to have an example behind it. Priority score should rank findings by how urgently they need fixing, so we removed the factor.

What you saw

Snyk Code findings reordered when the factor came out. Every remaining scoring factor works as it did before, including severity, which still contributes the largest single share at up to 500 points. No finding was added, removed or re-rated.

We should have told you

The August 17 release notes said no action was required. That was wrong, and we apologize. We have added a check so that any future change to priority score appears in the release notes. The priority score documentation now lists the current factors.

Learn more in the Snyk Code priority score documentation.

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

• Secrets

  • snyk secrets test now supports exclusions — add files or paths to the exclude section of your .snyk file to skip them during secrets scanning.

• Container

  • Container scans now surface image provenance attestations by default, so signed-image provenance metadata appears in results without any extra flag.

• .NET/NuGet

  • snyk test can now analyze already-restored .NET/NuGet projects fully offline and no longer requires .NET 6 to be installed.

• MCP

  • The full Snyk MCP profile now includes Snyk Secrets.

• Code & Secrets

  • SARIF suppressions now include reviewedOn and reviewedBy metadata.

• AI BOM

  • snyk aibom test --severity-threshold now filters the displayed and JSON results by severity, not only the exit code.

• Agent-optimized CLI

  • New experimental snyk agent command space — a scanning surface built for AI coding agents, with token-optimized output and ergonomics. snyk agent test runs Snyk Open Source, Code, and Secrets together.

• Additional Reliability and Performance Improvements

  • Adds support for scanning pnpm v11 pnpm-lock.yaml lockfiles.

  • Fixes a crash when scanning dependencies of Gradle 7.4–8.2 projects.

  • Fixes a bug where arguments after -- (for example snyk test . -- -s settings.xml) were treated as scan targets, which could silently drop the Risk Score.

  • Fixes scanning of projects using Hex versions newer than 1.19.

  • Excludes the .git folder from file discovery, preventing intermittent scan failures caused by changes to .git contents during a scan

  • Prevents a possible connection leak when the Snyk API returns an error response.

  • Updates dependencies to fix vulnerabilities.

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.

This update is available on September 14, 2026. It improves coverage and precision across Snyk Code: template files are analyzed, Java framework and library support is extended, detection gaps are closed in six languages, and .gitignore no longer hides committed files from analysis.

Template files

Snyk Code analyzes template files and follows data from your application code into the template. Cross-site scripting that only becomes exploitable where the template renders its output is now reported, with the data flow shown from the application through to the template.

Supported engines: Jinja2, Razor, FreeMarker, EJS, Handlebars, Pug, Thymeleaf, Twig, Mustache and Velocity.

Java

• Apache CXF — the web services framework, including its HTTP transport.

• OkHttp — the HTTP client.

• Spring Security OAuth2 Client — OAuth2 and OpenID Connect authentication.

• Google OAuth Client and Google API Client — Google authentication and API access.

• MSAL4J — Microsoft identity platform authentication.

• Apache Commons Collections — collection utilities.

• Flyway — database migrations.

• JAXB — XML binding.

• SAP Commerce (Hybris) — FlexibleSearch queries, with parameter binding recognised as safe.

Coverage for these libraries is added or improved, resulting in improved data flow analysis.

Python

LangChain LiteLLM is recognised as a source of untrusted data.

Java 25

Java 25 source is analyzed.

Rule coverage improvements

Detection coverage is extended for Java, Kotlin, C#, Go, JavaScript and PHP — additional sources, sinks and unsafe API patterns, in particular for cryptography.

Expect additional true positives and fewer false positives.

Files matched by .gitignore

• Committed files matched by a .gitignore rule are analyzed.

• Secrets committed and later matched by a .gitignore rule are now detected. Git ignores only untracked files, so this brings Snyk Code and Snyk Secrets in line with Git.

• These are pre-existing issues in code you already committed.

• The change applies across all interfaces and cannot be disabled.

Required for CLI scans. Upgrade to Snyk CLI 1.1307.0 or later, available from 26 August. Earlier versions keep the previous behavior, so CLI results will differ from your SCM and web results. SCM imports and scans need no action.

What is unchanged

• Untracked files matched by .gitignore remain excluded from analysis.

• .snyk exclude patterns behave as before, and remain the way to exclude a path deliberately.

• Severity levels and rule identifiers do not change.

Learn more in the Snyk Code documentation.

Until now, a developer could suppress a Snyk Code finding on their own — directly in the Web UI or IDE — with no review step.

Suppression happened silently and unilaterally, leaving security teams without a gate on what got ignored.

Ignore Approval Workflow changes that.

An ignore is no longer applied automatically — it becomes a request that only takes effect after a reviewer approves it. Developers submit ignores from where they work; a reviewer approves or rejects from the web; both sides are notified of the outcome. Suppression moves from an ungoverned action to a reviewed, auditable one.

What you can do

• Submit ignore requests from the CLI, IDE, or API — a reason is required, and the ignore is created as Pending rather than applied.

• Review from the web — reviewers with the review permission approve or reject on the Ignore Requests page.

• Auto-approve your own — reviewers can bypass triage for ignores they create themselves.

• Stay notified — reviewers are emailed on new requests and requesters on the outcome.

• Control access with roles — read / create / edit / review / delete permissions; by default Collaborators request and Admins review, with custom roles supported.

• Audit everything — export ignore-request data via the audit-logs API.

COBOL support becomes generally available on August 17, 2026. Snyk Code brings SAST to your mainframe applications, scanning fixed-format COBOL across the integrations you already use, so mainframe code receives the same real-time, in-workflow security coverage as the rest of your stack. Detection is tuned with feedback from design-partner environments across large finance and mainframe estates.

What you can do

• Scan COBOL applications for security issues alongside your other languages, with no separate workflow.

• Catch real, actionable findings, with COBOL engagement in line with mainline languages.

• Bring mainframe AppSec into the CLI, IDE, SCM, and PR-check integrations your teams already use.

Scope change at general availability

At general availability, the COBOL preview flag is removed and COBOL scanning runs automatically across all repositories. You may see new findings in repositories that were not scanned during the preview.

For design-partner customers

Thank you for shaping COBOL support during early access.

Learn more in the COBOL support documentation and the COBOL rules reference.

This update is available on August 17, 2026. It broadens language and framework coverage, adds serverless and LangChain support for Python, and cuts false positives in C++ and C#.

Python

• LangChain support — Snyk Code covers applications that use LangChain, flagging unsafe handling of data flowing through the framework.

• Serverless support — Snyk Code covers Python applications running on AWS Lambda.

• New detection — weak-hash detection and detection of debug features left enabled.

Java

• Spring Data coverage — data read through Spring Data repositories is tracked as a taint source, so injection, SSRF, path-traversal, and XSS findings reflect data flowing from the Spring Data layer.

• New framework recognition — vert.x, Jolokia, and Spring Cloud Config Client.

Reduced noise

• Fewer false positives in C++ DoubleFree and C# Code Injection.

Change to fix examples

• Fix examples no longer appear in Fix analysis in the Snyk Web UI, and no longer appear in SARIF output. The issue details, the data flow, and the CWE reference are unchanged.

• To remediate a Snyk Code finding, use Snyk Agent Fix. It generates a fix for that specific finding in your own code and verifies the fix by rescanning. See Fix code vulnerabilities automatically.

Overall, this release increases true-positive coverage and reduces false positives.

The July release expands Snyk Code coverage for C++ with several new rules and broader native C++ detection, improves detection for several popular Java libraries, and adds a new Insecure Transmission rule for JavaScript and TypeScript. These changes arrive with the July release on 13 July 2026

What's changing

New rules

• Log Forging, C++ (CWE-117, high): flags untrusted user input reaching a logging sink, which can let an attacker forge or corrupt log entries.

• Improper Privilege Management, C++ (CWE-269, high): flags a privilege-dropping call whose result is not verified; a failed call can leave the process running with elevated privileges.

• Missing Authorization, C++ (CWE-862, CWE-732): flags overly permissive file permissions (world-writable or world-executable), and calls that pass root (UID or GID 0) to privilege-escalation or file-ownership functions.

• SSL/TLS Certificate Verification Bypass, C++ (CWE-295, medium): detects disabled certificate verification across seven TLS frameworks (OpenSSL, Qt, mbedTLS, libcurl, Boost.Asio, libpq, libpqxx), which exposes connections to man-in-the-middle attacks.

• Insecure TLS Configuration, C++ (CWE-327, high): detects insecure TLS configuration, such as enabling outdated TLS versions.

• Sensitive Cookie Without Secure Attribute, C++ (CWE-614, low): flags cookies that omit the Secure attribute, either by default or explicitly set to false, leaving them exposed to man-in-the-middle attacks.

• Insecure Transmission, JavaScript (CWE-319): detects cleartext transmission over insecure transports beyond HTTP. Initial coverage targets Redis clients (@redis/client, ioredis, redis) connecting over a non-TLS redis:// URL. New rule-key, separate from HttpToHttps.

New C++ coverage

Detection now extended to native C++ for:

• Code Injection (CWE-94): across six framework modules: dlopen, LoadLibrary, Lua, CPython, Duktape, QuickJS.

• Insecure Storage (CWE-922, info): sqlite, realm, leveldb, rocksdb, lmdb, Qt.

• Insecure Cipher (CWE-327): broader native C++ crypto coverage (OpenSSL, Botan, libsodium, libtomcrypt, libgcrypt, Crypto++, mbedTLS).

Expanded Java library coverage

Improved detection for code using these popular Java libraries:

• Azure SDK for Java (com.azure:azure-core)

• Logback (ch.qos.logback:logback-classic)

• Reactor Netty HTTP (io.projectreactor.netty:reactor-netty-http)

• Apache Kafka clients (org.apache.kafka:kafka-clients)

• Jackson (com.fasterxml.jackson.core: jackson-databind and jackson-core)

Important details to note

• C++ customers may see new findings after the July release, in particular from the new rules above.

• TLS rule reclassification: the existing TLS rule (Inadequate Encryption Strength) is moving from CWE-326 to CWE-327 across C++, Groovy, Java, Kotlin, Python, Scala and Swift. Customers with policies or ignores tied to the TLS rule under CWE-326 should review them. The TLS detection has also been refactored, so customers may see a change in the volume of TLS-related findings.

• The C++ Insecure Storage rule is info-level and may increase findings, including some false positives (early triage sampled 50 of 491 new findings: 47 true positives, 3 false positives).

• The JavaScript Insecure Transmission rule ships as a new rule-key, separate from HttpToHttps, so ignore and policy scoping stays clean.

To learn more, visit our Snyk User Documentation.

The upcoming improvements for our Snyk Code: June Update will be postponed from June 15 to June 22. We're running a final round of quality validation to make sure these updates deliver the most accurate results.

These updates, including broader TLS and cryptographic detection for .NET and expanded PHP SQL injection coverage, will now go live on June 22.

We are thrilled to announce that the Prevention Report is now available in Early Access!

Measuring the true impact of "shifting left" has traditionally been a challenge. We designed the Prevention report to give you clear, actionable visibility into the effectiveness of security adoption directly within your development lifecycle.

This new report tracks the vulnerabilities developers proactively remediate at the point of creation in Snyk Code and Secrets—long before those issues ever reach a pull request or production environment. Data is seamlessly captured in the background as your team works across our developer surfaces, including Snyk Studio (MCP), IDE plugins and extensions, and the CLI.

The Prevention report enables you to:

• Measure proactive security: Track the total number of raw fixes and monitor your fix rate over time using our new prevention key performance indicators (KPIs).

• Analyze developer workflows: Break down fixes by surface area to understand exactly where your team prefers to resolve issues (MCP, IDE, or CLI).

• Identify trends and champions: Leverage the Fix-by-Developer leaderboard and detailed vulnerability breakdowns to see which types of vulnerabilities developers squash immediately, and which ones are detected but left unfixed.

• Enrich your Analytics Overview: Enable fix-by-surface KPIs and a new fix trends chart directly within your primary Analytics Overview dashboard for a comprehensive view of your security posture.

You can now directly measure the effectiveness of your IDE or MCP-based security efforts. By tracking vulnerabilities remediated early in the development lifecycle, you gain the data needed to prove the success of your security programs and validate your application security strategy.

To learn more, visit our Snyk User Documentation.