Product Updates

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.

Snyk API & Web MCP Server brings even more security to your IDE

You can use the Snyk API & Web MCP server to bring Snyk security capabilities directly into your AI-native development environment. By using the Model Context Protocol (MCP), you can use natural language to onboard targets, configure DAST authentication, scan targets, and triage vulnerabilities without leaving your IDE.

Security workflows often require manual effort and constant context switching. We built the Snyk API & Web MCP server to eliminate this friction. Previously, setting up and onboarding new targets required significant manual work. This integration simplifies these processes and removes the need for security plumbing between tools.

This release benefits Appsec and Dev Teams using MCP-enabled tools like Claude Desktop, Cursor, or Windsurf.

• From UI-heavy to chat-native: Instead of navigating menus to set up a scan, you can tell your assistant to automatically onboard and configure a new Snyk API & Web target

• Automated authentication: Use AI to help generate and implement the authentication scripts required for deep web scans.

Learn more about these capabilities in the Snyk API & Web MCP Server 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.

We are excited to announce the general availability of Broken Object Level Authorization (BOLA) detection for OpenAPI targets, starting today. This feature uses artificial intelligence (AI), particularly large language models (LLMs), to identify unauthorized data access risks. You can now test for these vulnerabilities using the built-in API Normal or API Full scanning profiles.

BOLA is ranked as the primary risk in the OWASP API Top 10. By automating the detection of this complex vulnerability, we help you move beyond manual security reviews and reduce the risk of data leaks. Our goal is to provide proactive protection for your APIs by identifying authorization flaws before they can be exploited.

To use this feature, you must configure API target authentication for two separate users. The second user acts as the attacker and should have the same or lower privileges than the first user, and should not have access to the first user's resources. Once configured, our scanning engines will automatically attempt to detect if the second user can inadvertently access data belonging to the first, providing clear visibility into potential authorization gaps.

To learn more, visit How to set up your target for testing BOLA vulnerabilities? in our user documentation.

We're excited to introduce the first automatic solution for correlating static application security testing (SAST) and dynamic application security testing (DAST) findings. By connecting Snyk Code issues with Snyk API & Web results, we can now pinpoint the exact line of code responsible for a DAST vulnerability, helping you understand exactly where your code needs to be fixed and speed up your remediation process.

Vulnerabilities discovered during DAST can often be difficult and time-consuming for developers to locate within the source code. This update automates that manual search process. By using artificial intelligence to map runtime findings back to static code analysis, we're helping your teams reduce the mean time to remediate and focus on fixing issues rather than finding them.

In order to use our SAST/DAST correlation, you just need to link your Snyk API & Web targets to your Snyk Code projects and scan your API & Web targets the way you're used to. We'll do all the heavy lifting for you, and show you the corresponding SAST issue that matches our DAST finding, with the context and link directly to the code that needs to be fixed to mitigate the vulnerability.

Learn more about it here

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’ve activated direct links to Snyk Learn lessons within the findings details pages of Snyk API & Web. When you are reviewing a vulnerability, you can now find educational content under the Description tab. Snyk Learn provides hands-on lessons to help you understand, prevent, and fix security issues in your code.

We want to bridge the gap between identifying a security risk and knowing how to remediate it. By embedding these lessons directly where you work, we're making it easier for you to build security knowledge without leaving the platform.

You can now quickly access expert-guided security training for specific vulnerabilities you encounter. This helps you not only resolve the current issue but also acquire the skills to prevent similar vulnerabilities in the future, ultimately enhancing your overall security posture.

To learn more, visit Snyk Learn.

Experience greater flexibility in authenticating your scans with the new Signature capabilities for API targets. With Snyk API & Web, you can now configure signed requests using your own algorithms.

We added this feature to support complex authentication requirements that require signed requests. By providing a dedicated space to manage these signatures, we're making it easier for you to run automated security scans against protected API endpoints that verify message integrity and authenticity.

If you have the message signature feature enabled, you can now navigate to your API target settings to set up signing methods. This ensures your scans can successfully authenticate with APIs that require cryptographic signatures for every request.

To enable this feature, please contact the Sales team.

To learn more, visit How to configure Signed Requests for API Targets in our user documentation.