Shifting responsibly left with the enhanced Snyk security gating on pull requests

We’re pleased to announce we’ve enhanced Snyk’s security and license testing for pull requests to better support shift-left security and secure development workflows!

Pull requests — the backbone of GitHub-based development workflows — make it easier to collaborate on projects. Individual contributors can share changes they’ve pushed to a branch in a repository, discuss them with other collaborators, and subsequently commit and merge them into the base branch.

Designed to allow developers and security teams to apply security testing as an integral part of these workflows — and as early as possible in the SDLC — Snyk automatically tests changes included in pull requests for security vulnerabilities and license issues. If an issue is identified, the Snyk test fails and the developer is informed via a corresponding status check. To ensure Snyk’s security testing for pull requests is not interfering with development pipelines, users can decide exactly when to fail status checks, for example, only for high severity issues or when a fix is available.   

The latest enhancements made to Snyk’s security testing for pull requests take this up a notch. To further ensure development pipelines are not broken needlessly and to give developers full visibility into the results of Snyk’s security testing, developers can now see the full details on why their pull request failed and subsequently request the administrator to skip the test and “force pass” the pull request. 

Let’s see this in action with a few simple examples.

Snyk status checks for pull requests

Once GitHub completes checking for conflicts, running against the manifest files in the project (e.g. package.json / package.lock, requirements.txt, or Gemfile.lock / Gemfile), Snyk then performs the security tests. If the changes made don’t introduce vulnerabilities, the test passes with flying colors:

On the other hand, if the changes do introduce vulnerabilities, Snyk’s status checks fail the pull request. In the example below, the inclusion of a dependency caused Snyk’s security testing to fail:

Regardless of the number of projects (and related manifest files) in a repository, only two Snyk status checks are displayed — one for security tests and the other for license checks. This is especially useful for mono-repos, as it reduces the number of status checks received from Snyk for integrated projects.

Administrators can configure Snyk’s security testing for pull requests to be more strict or lenient. For example, testing can be configured to fail if the repository has any existing vulnerabilities or if only high vulnerabilities are introduced.

Skipping failed security tests

Seeing failed status checks on pull requests can be frustrating for developers, especially when they come with no contextual information on why the test failed in the first place. Snyk provides both the visibility into vulnerabilities and license issues that were found during the test and the ability to circumvent the failed test and force pass it.

If a pull request fails Snyk’s tests, Snyk users can view the reasons why by clicking the Details link that is displayed next to the failed check status. This leads the user to the Snyk app, where all the information about why the testing failed is displayed on the Combined Status page:

All the relevant checks performed for the project are displayed with information on results and their state — ‘Error’ for tests that could not be completed, ‘Failed’ for tests that failed due to issues identified, ‘In Progress’ for tests still taking place, and ‘Successful’ for tests that passed.

Users defined as collaborators can send a request to a Snyk administrator user to force pass one or more of the tests displayed on this page.

Administrators can click the Mark as successful in SCM button to comply with the request. The status changes automatically on GitHub.

Every skip action performed to force pass a failed security test is logged for future reference, with auditing information on who performed the action and when, as well as a link to the Combined Status page.

A supervised shift-left

Shifting security left is a cornerstone for successfully implementing a DevSecOps strategy but must be done responsibly. This can be done by empowering developers to integrate security into existing development workflows in a frictionless and impediment-free manner and with the right degree of supervision.

Snyk’s enhanced security testing for pull requests ensures developers have early and full visibility into the automated security testing executed on their pull requests, together with the ability to request a forced pass of the failed testing. What’s more, security teams have the control they need to remove blocks in a safe way.

Want to give it a try? These capabilities are provided in all Snyk plans, including the Free plan.