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.

We added a new Test configuration option to the Scan dropdown menu and the Target Settings page. This allows you to verify that your target is accessible and correctly configured before starting a full dynamic application security testing (DAST) scan. When you click this button, a side panel opens in your target settings to provide real-time feedback on connectivity, authentication, web application firewall (WAF) interference, schema validity, and any detected extra hosts.

We want to simplify your onboarding experience and prevent failed scans caused by misconfigured settings. By validating your setup upfront, we help you identify and fix issues immediately, reducing the need for troubleshooting or technical support later in the process.

You can now proactively test your target configuration. To use this feature, ensure you have the view_target, change_target_settings, and start_scan permissions.

To learn more, visit How to test target configuration in our user documentation.

Key Capabilities of Unified Navigation

Grouped Navigation for Faster Orientation Snyk's menu is now organized around how security work actually happens. Related items are grouped, so you spend less time hunting through menus and more time in context.

Context-Aware Shortcuts Snyk now recognizes what you are working on. This reduces the steps for common workflows from 8 clicks down to just 2 or 3, allowing you to move at the speed of development.

The Core Problem: Navigational Complexity

Currently, security data is spread across disconnected areas, forcing users to hold a mental map of the product just to find what they need. Finding and understanding a specific security issue requires manual effort and several steps. Users often face:

• Action Overload: An overwhelming volume of results without a clear path to the most important task.

• Context Switching: Constant jumping between code, container, and infrastructure views to see the full picture.

• High "Click Tax": Simple tasks like finding a specific vulnerability can take 8 or more clicks.

The new Snyk Unified Navigation addresses this directly — by consolidating related items, reducing top-level noise, and adapting what's visible to the task at hand. The goal is simple: less time navigating, more time fixing.

The Value to Your Security Program

By unifying the interface, we aim to help organizations achieve three main outcomes:

• Reduce Triage Time: Cut the time spent reviewing alerts through faster navigation.

• Increase Efficiency: Enable developers to find and fix critical issues faster.

• Scale Security Teams: Allow small security teams to manage significantly more projects by removing manual navigation hurdles.

Snyk 2.0 platform improvements

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’re introducing a new Download CSV feature to help you export your data directly from the interface. Starting today, you can download a comma-separated values (CSV) file that matches your current table view, including any active filters or hidden columns. We'll follow this implementation soon after, with an enhanced version that gives you even more flexibility, by allowing you to choose from a wider range of fields, which ones to include in your CSV file. 

We recognize that managing security data often requires analysis outside of our platform. Previously, moving table data into other tools required manual effort or copy-pasting. We're adding this functionality to save you time and provide a powerful way to leverage your data for custom reporting and internal manipulation without the manual overhead.

This feature is available to all users across all account plans. If you have access to a table, you can now download its data.

To learn more, visit How to export table data to CSV in our user documentation.

We're introducing a new permission called Change Finding State to give you more granular control over how your teams manage security findings. Previously, the Change Finding permission covered several actions: changing a finding's state, review status, assignee, labels, and adding notes. We've separated these capabilities so that Change Finding State now specifically handles changing a finding's state and review status, and the existing Change Finding permission now focuses on managing assignees, labels, and notes. To prevent any workflow interruptions, all built-in and existing custom roles that currently have the Change Finding permission will automatically receive the new Change Finding State permission.

We made this change to help you better implement the principle of least privilege within your security programs. We heard that many organizations need to allow team members to contribute to the triage process — such as by adding notes or labels — without granting them the authority to officially ignore a finding or accept a risk. By decoupling these actions, we provide the flexibility to define more specific roles for your developers and security analysts.

You can now create custom roles that allow users to add context to findings without giving them the ability to change the security posture of an application. For example, if you want a user to be able to add notes to a finding, you can assign them the View Target and Change Finding permissions, but if you want a user to be able to ignore or accept findings, they will now require the Change Finding State permission. While this update does not change current access for existing users, we recommend reviewing your custom roles to see if you can further restrict permissions.

To learn more, visit Understanding Permissions at Snyk API & Web in our user documentation.

We’ve added a new Custom Headers module to the Scanner tab within Postman target settings. Much like our existing functionality for Web and OpenAPI targets, you can now configure specific headers and determine whether they should be included in the test surface or not. By default, we treat these headers as static prerequisites — such as authentication tokens — that are sent with every request to satisfy API requirements without being actively tested. If you select the checkbox to test a header, the scanner treats that header value as a testable attack surface and runs full security checks against it.

We’re introducing this update to give you more flexibility and precision when scanning Postman targets. Many APIs require specific headers to function, but not all of those headers need to be subjected to security testing. By allowing you to define which headers are static prerequisites and which should be actively tested, we’re ensuring your scans are both compatible with your API requirements and focused on the right attack surfaces.

You can now manage your Postman targets’ scan configurations more effectively by adding custom headers directly in the UI. When you view your results, the Scan results page for Postman targets now includes a Custom Headers entry in the USED SETTINGS module. This clearly indicates whether custom headers were Enabled or Disabled for that specific scan, providing better auditability for your security testing.

To learn more, visit Understanding Custom Headers in Snyk API & Web in our user documentation.

Starting on March 6, 2026, we’re introducing Credentials Manager to help you store and manage sensitive authentication data separately from your target configurations. This update simplifies secrets management and allows teams to share authentication setups without exposing actual credentials.

The Credentials Manager replaces the Secret Obfuscation feature, which is now discontinued.

Running dynamic application security testing (DAST) scans requires sensitive information like logins, passwords, and tokens. Previously, these were stored directly within each Target. This made it difficult to manage authentication across multiple targets and made regular password rotation time-consuming. We built this to provide a centralized way to manage these secrets more efficiently.

The Credentials Manager introduces several changes to how you handle sensitive data:

• Centralized storage: You store credentials in a dedicated place, keeping them separate from your Target configuration.

• Write-only secrets: Some credentials are write-only. You can use these in authentication settings, but the values remain hidden after you save them.

• Flexible configuration: You can still create credentials for a single Target if you do not want to save them to the central Credentials Manager.

To learn more, visit How to manage target authentication credentials in Snyk API & Web.