Product Updates

We’re excited to announce that Issue Summary Comments and High-Context Inline Comments are now Generally Available! 🎉

As of May 1, 2025, the features are enabled by default for all customers using PR Checks on supported SCMs, marking a major milestone in how Snyk brings security into the developer workflow.

What’s included:

• Issue Summary Comments for both successful and failed PR checks, covering Snyk Code and Open Source security & license findings.

• Inline Comments for Snyk Code issue findings, providing high-context feedback directly in the pull request.

This applies to repositories connected via:

• GitHub: GitHub OAuth, GitHub Enterprise (PAT), and GitHub Cloud App

• BitBucket: Bitbucket Cloud (PAT) and Bitbucket Cloud App

To adjust your preferences, head over to Integration Settings in the Snyk UI where you can toggle comments on or off at any time. This release is a big step forward in our mission to make security native to the developer experience. We’re excited to see how this helps your teams catch and fix issues faster, right within your SCM! 🚀

Refer to the user documentation for more details!

Update: The rollout has officially started on April 22 and will proceed gradually through to May 1.

We are excited to announce that Issue Summary comment and High Context Inline comments are coming to General Availability soon! As part of this exciting milestone, we're taking the next step by enabling these capabilities by default for all customers who use PR checks on April 22nd, 2025. With this update, all GitHub and Bitbucket (except Bitbucket Server) repositories with PR checks enabled will automatically include both the Issue Summary comment and SAST High Context Inline comments, revolutionizing how your developers identify and address vulnerabilities without ever leaving the SCM.

The repositories onboarded via the following SCM integrations are in scope of this change:

• GitHub: GitHub OAuth*, GitHub Enterprise (PAT), and GitHub Cloud App

• Bitbucket: Bitbucket Cloud (PAT), Bitbucket Cloud App

Key highlights ​​of this release

On April 22nd, 2025, all repositories with PR checks enabled will automatically activate the following capabilities:

• Issue Summary comment for both PR check success and failure cases, covering Snyk Code and Open Source security & license checks.

• High Context Inline comments for Snyk Code findings.

Repositories that have either (1) manually disabled either of the comments after initial enablement or (2) disabled summary comments for success scenarios during Early Access will remain unchanged, ensuring prior preferences are respected.

Opt-Out Requests

• Opt-out requests can be submitted via our dedicated form or through your Snyk POC (include Group/Org IDs)

• Opt-out submissions received before April 21st, 2025 will not be default enabled

To customize your preferences at any time after default enablement, you can simply visit your integration settings in the Snyk WebUI where you can toggle comments off.

This milestone represents our ongoing commitment to transforming the developer experience with Snyk, making security an integrated, intuitive part of your development workflow 🚀

*Note: For GitHub OAuth integrations, a PAT token with the right permissions will need to be added to start receiving PR comments.

Currently, Snyk’s BitBucket Server integration reports on commit statuses (Snyk PR Checks) per project (i.e., per manifest file in the repo). This reporting approach consumes excessive SCM resources in large or complex repositories. To remedy this, the Snyk BitBucket Server integration will report per-product commit statuses beginning April 22, 2025.

By moving to per-product statuses, BitBucket Server integration users will benefit from:

• A more consistent UX with the rest of Snyk’s SCM integrations, which report their statuses on a per-product basis (Snyk Code, Snyk Open Source)

• Performance improvements through fewer calls made to their SCM by Snyk

• Access to existing features like Mark as Successful or new features such as PR Comments, which were not supported by per-project statuses.

We are announcing the Early Access release of PR Issue Summary Comment and SAST High-Context Inline Comments as part of our ongoing efforts to enhance the pull request experience. These features bring critical security insights directly into your PRs, reducing context switching and streamlining vulnerability remediation.

• PR Issue Summary Comment - With this feature, developers using Snyk PR Checks will receive a comment with a summary count of security, license, and code checks directly within their pull requests, categorized by severity (Critical, High, Medium, Low). This empowers developers to identify and address issues early, with detailed links provided for deeper investigation.

• High-Context Inline Comments display each SAST security finding alongside key information such as CWE (Common Weakness Enumeration) and priority score and a Snyk Learn link for further guidance—helping developers remediate issues faster without leaving their SCM. 🚀

This is part of a series of enhancements designed to improve your developers’ pull request experience with Snyk, and we remain committed to further improving it. If you’re interested in enabling this feature for your organization, you can self-opt in via the Pull Request Experience section in the SCM integration settings. Check out the user docs for more details. Try it out and connect with your account team to participate in feedback sessions to shape the future of your Snyk’s workflows.

Currently, Snyk can automatically create pull requests (PRs) on your behalf to upgrade your dependencies based on the relevant scan results. These can help you pay down your security vulnerability backlog, introduce fixes for newly discovered issues, or keep your dependencies up to date with new versions.

With our new "Snyk Generated Pull Requests" report now available in Early Access, you can visually track and measure the impact of these fix PRs. This report enables you to review how many Snyk Fix, Backlog, and Upgrade PRs were opened, merged, or closed across your repositories, and observe the overall mean time to merge. This report, available for all supported SCM integrations, can be filtered by organization, repository, project, or source and is refreshed every 90 minutes.

To view this report, simply navigate to the Reports section of your Group or Organization and choose “Snyk Generated Pull Requests” from the "Change Report" drop-down menu.

For more information, visit our reports documentation.

As part of our commitment to improving the pull request experience, we’ve introduced key enhancements to Inline Comments which boost developers' productivity by bringing detailed security findings directly into their PRs.

What’s new:

✅ Inline Comments are now capped at 10, prioritizing the most critical vulnerabilities by severity to prevent clutter and avoid SCM rate limits. If more than 10 findings exist, a note in the PR Summary Comment will notify you.

✅ Smarter vulnerability placement ensures that findings reported outside the PR diff are mapped to the nearest relevant changed line, keeping security issues visible even when the exact location isn’t commentable.

These updates streamline security reviews, reducing distractions while ensuring developers can quickly act on vulnerabilities within PRs.

PR Checks for Snyk Code are now Generally Available. Customers using Snyk Code to secure their applications can enable PR Checks to automatically scan their pull requests and provide a mechanism to gate those changes from being merged when new security vulnerabilities are discovered.

How do I enable PR Checks for Code?

Snyk Code PR Checks are available for all supported SCM integrations.

To turn them on for Snyk Code projects, navigate to the Pull Request Status Checks section under your organization’s integration settings and look for Code Analysis. From there, you can enable PR Checks and select your preferred failure condition (Low, Medium, or High severity issues).

You can then use PR Checks, along with your SCM’s configuration, to decide whether to prevent changes from being merged while the commit status check is in a failed state.