Product Updates

The "What"

Repo Content Sync keeps your Snyk Projects aligned with what your repositories actually contain. When a change is merged to a branch Snyk monitors, Snyk creates and begins monitoring Projects for newly added manifest, Dockerfile, and configuration files, and deactivates the Projects whose files were removed. A file that is moved or renamed is picked up at its new path, and the Project at the old path is deactivated.

Until now, keeping Snyk in step with a repository was a manual step: someone re-imported the repository, or a newly added dependency file simply went unscanned. Repo Content Sync makes repository content itself the trigger, so your Project list reflects the code as it is today rather than as it was at import.

Sync covers Code, open source, secrets, infrastructure as code, and container (Dockerfile) Projects, and it works on custom branches as well as default branches.

Repo Content Sync will be rolled out gradually over the next several weeks.

The "Why"

A Snyk Project is a point-in-time snapshot of a repository. The moment a developer adds a manifest, a Dockerfile, or an infrastructure-as-code config — or removes one, or renames it — Snyk's view of that repository is out of date, and closing the gap depends on someone remembering to re-import.

The cost lands on both sides of that gap. Coverage decays quietly between imports, so a security team cannot tell the difference between a repository that is clean and one that was never looked at. And when a source file is deleted, its Project lingers as a stale asset, inflating inventory and issue counts that someone then has to explain.

Repo Content Sync removes the manual step. Coverage follows the repository, so what Snyk monitors and what your developers merge stay in step on their own.

The "How"

Repo Content Sync is on by default for organizations on an Enterprise plan. There is nothing to enable and no configuration to change. It is rolling out to Enterprise organizations, so it may reach your organizations over the following weeks. If you already turned it on through Snyk Preview, it stays on and nothing changes for you.

Once it reaches an organization, your Project list moves with your repositories: Projects appear as new scannable files are merged, and Projects are deactivated when their files are removed. Inventory and issue counts shift to match.

Considerations and known limitations:

• A Project you deactivate yourself, through the UI or the API, is not reactivated by sync — manual deactivation is respected.

• If you delete a Project and want it to stay deleted, select the option to exclude it from future scans in the delete dialog; without that, a Project whose source file still exists can be recreated on the next sync.

• Upon GA, if some projects were previously deleted but not removed from SCM, they might reappear and will require a 'permanent' deletion via the option to 'exclude it from future scans.'

For more information check Repo Content Sync Docs

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.

Starting August 18, 2026, a user's Evo data is limited to the Snyk Organizations they can read.

Until now, everyone with access to Evo saw every repository, asset, and issue in the Tenant. Evo now
reuses your existing Snyk Organization hierarchy, so there is nothing new to model and no migration to
run. Nobody loses access until an administrator changes their role.

What's new:

• Tenant Viewer now grants read access to the assets and issues in the Organizations the user belongs to, and to nothing outside them

• Tenant Member grants no Evo access, letting administrators withhold Evo without removing Snyk platform access

• Full-Tenant access continues for Tenant Admin and for the two roles ending in "with Evo access"

• Organization names appear alongside repositories, distinguishing the same repository imported into more than one Organization

Note for administrators:

Existing users keep their access, and Tenant Viewers gain scoped read access for the first time. New
users join as Tenant Member, which carries no Evo access, so each one needs a role change. Scoped
users are read only, and assets without an Organization stay hidden, which today means all Agent
Supply Chain Security and Continuous Offensive Security data.

Documentation: Access and authentication

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.

Starting August 17, 2026, Evo by Snyk uses a rebuilt model risk score to evaluate the AI models discovered in your organization.

The previous Risk Index is replaced by a single score from 0–1,000 that combines attack success rate with the potential impact of a successful attack, tested against categories including prompt injection, data exfiltration, and insecure code generation. The result is a score that reflects both how easily a model can be compromised and how much damage that compromise could cause — not just whether an attack succeeded.

What's new:

• Impact-weighted scoring: Risk scores now factor in the real-world consequence of an attack succeeding, not only its likelihood.

• Four severity bands: Scores map to low (0–249), medium (250–499), high (500–749), and critical (750–1,000), so you can triage at a glance.

• Broader attack coverage: Testing spans a wider range of direct and indirect attack categories against each discovered model.

• Framework-mapped: Findings map to OWASP LLM Top 10, OWASP Agentic Security, MITRE ATLAS, and NIST AI 600-1/100-2e2025, so you can connect model risk to the compliance frameworks you already report against.

• Policy-ready from day one: Evo applies default policies across common attack categories automatically, and you can create custom policies scoped to specific attack categories or goals to match your organization's risk tolerance.

If you have policies built on the old Risk Index: those policies remain visible but no longer evaluate under the new scoring. Review and recreate any Risk Index-based policies against the new model risk score to keep enforcement active.

Read more in the Risk intelligence documentation.

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

• Clearer error messages when the CLI cannot reach a configured proxy. Failures now report the proxy URL the CLI attempted to use, with credentials redacted, along with the specific error code SNYK-CLI-0028, making proxy misconfiguration quicker to diagnose in CI and behind corporate networks.

• An updated embedded runtime, moving Node.js from 22.22.2 to 22.23.2 and OpenSSL from 3.5.5 to 3.5.7, which brings in fixes for six high-severity CVEs plus additional OpenSSL security fixes.

• Fixed vulnerabilities:

  • SNYK-JS-JSYAML-18593780

  • CVE-2026-45447

  • CVE-2026-48618

  • CVE-2026-48933

  • CVE-2026-56846

  • CVE-2026-56848

  • CVE-2026-58043

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.

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

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

This update includes the following:

• Updates bundled dependencies to remediate known vulnerabilities, keeping the CLI current for teams with supply chain policies on the tools running in their pipelines.

• Fixed vulnerabilities:

  • SNYK-JS-SHESCAPE-18319522 (CVE-2026-14257)

  • CVE-2026-69152

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 API & Web now supports NTLM v2 authentication for Web targets. Security teams can configure NTLM credentials (username, password, domain, workstation) directly in the target settings, enabling authenticated scans of Windows-authenticated applications without requiring separate tools.

Many enterprise customers — especially in financial services, insurance, and government — run internal applications protected by NTLM authentication. Without this capability, these applications remained unscanned, creating security blind spots.

Security engineers can now scan Windows-authenticated internal applications that were previously inaccessible, eliminating coverage gaps. To configure NTLM authentication, navigate to Target Settings > Authentication tab, locate the Basic Auth / NTLM module, and select the NTLM option.

To learn more, visit NTLM in our user documentation.

Starting August 4, 2026, Snyk secrets scanner is generally available to help secure your entire SDLC against credential leaks.

Stolen credentials remain a leading initial access vector in security breaches, and the rise of AI-generated code increases the risk of exposing sensitive data. You can now use Snyk secrets scanner to detect hardcoded credentials, API keys, and tokens across your repositories and prevent them from reaching commits or being leaked.

Key capabilities include:

• Machine learning driven detection and prevention across your development surfaces.

• Secrets detection for both human-written and AI-generated code.

• Governance and finding management directly within the Snyk web UI.

For more information, please read the blog and Snyk Secrets 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.