XRAY-133157 - Scan the merge base instead of the target branch tip - #1415
Draft
Jordanh1996 wants to merge 4 commits into
Draft
XRAY-133157 - Scan the merge base instead of the target branch tip#1415Jordanh1996 wants to merge 4 commits into
Jordanh1996 wants to merge 4 commits into
Conversation
…cannot be downloaded
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Background
PR scans diff the source branch tip against the target branch tip. When a branch is behind its target, anything the target gained since the branch point looks newly introduced by the PR — so the target's already-fixed vulnerabilities are reported as new findings on a PR that changed no dependency file.
A customer hit this: two SCA violations for
CVE-2026-41710onspring-retry:2.0.12, on a PR with nopom.xmlchange. Their master already carried2.0.13— the CVE's fix version. GitHub's Files-changed view uses the merge base, so nothing looked modified; Frogbot used the tip.What changed
downloadSourceAndTargetnow resolves the merge base through the git provider and downloads the target tree at that commit instead of at the branch tip.Resolution is two rungs — provider API, else target tip:
The bottom rung is exactly today's behavior, so no provider can regress. GitHub and GitLab resolve today (jfrog/froggit-go#195); Bitbucket Cloud, Bitbucket Server and Azure Repos take the warned fallback until their own PRs land.
When the branch is up to date the merge base equals the target tip, so the scan is unchanged. Only stale branches behave differently.
Notes for reviewers
.git; measured on a real monorepo that costs 118.7s / 1.3GB versus ~480ms for the provider API. A commits-only partial fetch is far better (~9s) but silently degrades to the full fetch when a server refuses the filter — a fallback whose worst case is 250x the happy path. The provider API is also size-independent: 472ms on a 140k-commit repo.pull_request.base.shais not the merge base. It looks correct and diverged in 11 of 25 sampledcli/cliPRs. Only the compare/merge-base endpoints are authoritative.Blocked on
jfrog/froggit-go#195 must merge and release first. Draft until then — the froggit-go bump is the only remaining commit.
Refs XRAY-133157.