Dependency pull request checks

Dependency pull request checks show you which dependency vulnerabilities a pull request adds or fixes, before anyone merges it. In GitHub and GitLab repositories, Oneleet scans pull requests opened against the repository’s target branch (GitLab calls these merge requests) and reports the result on each one as Oneleet Dependency Scan, a check that GitLab calls a commit status. If a pull request adds or fixes any vulnerabilities, Oneleet also posts a comment on it that lists them.

Dependency pull request checks are in beta. To use them, contact Oneleet support and we’ll turn them on for your workspace. After that, only workspace admins can turn them on for individual repositories.

Turn on dependency pull request checks

Dependency pull request checks are off for every repository by default. To turn them on for a repository:

1. Go to Code security, click Configure, and click the repository on the Repositories tab.
2. Under Scan configuration, check that Automatic scanning is enabled. If it isn’t, click Enable automatic scans.
3. Select the dependency checkbox in the checks section for the repository’s provider:
   • GitHub: Automatically scan pull requests for new dependency vulnerabilities, under GitHub pull request checks
   • GitLab: Automatically scan merge requests for new dependency vulnerabilities, under GitLab merge request checks

The checks section appears only while automatic scanning is enabled. If you turn automatic scanning off later, dependency pull request checks stop running, even though their checkbox stays selected. Code security pull request checks have their own checkbox in the same section, so either kind can be on without the other.

GitLab connection requirements

The GitLab connection’s token needs the api scope, and the token’s owner needs at least the Maintainer role on the project. If either is missing, selecting the checkbox still shows a success message, but no checks run. On a self-managed GitLab instance, checks also run only if the instance can reach Oneleet’s API.

When Oneleet scans a pull request

Once dependency pull request checks are on for a repository, Oneleet scans each pull request opened against the target branch when it’s opened, and again each time someone pushes a commit to it while it’s open. Oneleet skips drafts until someone marks them ready for review. A pull request that’s already open when you turn them on isn’t scanned until someone pushes a commit to it or marks it ready for review.

Scans on GitHub

Pull requests from forks are scanned too. To scan a pull request again, click Re-run on its Oneleet Dependency Scan check.

Scans on GitLab

Oneleet skips merge requests from forks. Reopening a merge request or changing its target branch also starts a scan. GitLab has no re-run, so to scan a merge request again, push a new commit to it.

What the check compares

For each pull request, Oneleet scans the dependencies at the pull request’s latest commit and at the commit where it branched off from the target branch. Vulnerabilities published since the target branch’s last scan don’t count against the pull request, and changes merged into the target branch after the pull request branched off don’t count for or against it.

A vulnerability counts as introduced when the pull request’s dependencies have it and the branch point doesn’t, and as fixed in the reverse case. Updating a package to a different version that’s still affected by the same vulnerability counts as neither.

When the check fails

Oneleet Dependency Scan fails when the pull request introduces at least one vulnerability with a High or Critical risk level. New vulnerabilities with a lower risk level are listed, but the check still passes. The risk level comes from public data about the vulnerability, such as its CVSS score, and leaves out the AI exploitability assessment that adjusts findings on the platform. So a pull request can fail on a vulnerability whose finding on the platform is already rated below High.

If the scan itself can’t finish, the check fails with the title “Dependency scan failed” and shows the error, such as “Scan timed out.” To try again, start a new scan as described in When Oneleet scans a pull request.

Block merges on a failing check

A failing check blocks merging only if the repository requires it to pass.

Require the check on GitHub

Require the Oneleet Dependency Scan status check in a branch protection rule or ruleset.

Require the check on GitLab

Turn on the Pipelines must succeed merge check under Settings > Merge requests > Merge checks. If several kinds of pipeline run for the same merge request, GitLab checks only the merge request pipelines for this setting.

What developers see

Developers see the Oneleet Dependency Scan check on the pull requests Oneleet scans. Once a pull request introduces or fixes at least one vulnerability, Oneleet also posts a comment on it. Later pushes update that same comment, even when they introduce and fix nothing, and the comment’s first line names the commit it describes.

The comment lists each introduced vulnerability with its package, severity, contextual risk, and the manifest file it comes from, most urgent first. Vulnerabilities the pull request fixes are listed in a collapsed Fixed vulnerabilities (N) section. Each list shows up to 25 entries, followed by a count of the rest.

For each vulnerability the pull request introduces, the comment’s What should I do now? section suggests one of two things: update the package to a version that fixes it (or remove the package), or merge the pull request and resolve the finding once it appears on the platform after the next scan of the target branch. To resolve a finding, see Findings and triage.

Confirm a fix before merging

To check that a pull request fixes a vulnerability before you merge it, look for the vulnerability in the Fixed vulnerabilities (N) section of Oneleet’s comment on it. When the pull request introduces no vulnerabilities, the check’s title also counts the fixes, as “No new vulnerabilities, N fixed”.

Findings on the platform change only when the target branch is scanned, so the finding stays open until the fix is merged into the target branch and that branch’s next scan completes. Oneleet scans the target branch’s dependencies every 6 hours, and pushing to the target branch doesn’t start a scan. For more on how findings resolve, see Findings and triage.