Skip to content

XRAY-133157 - Scan the merge base instead of the target branch tip - #1415

Draft
Jordanh1996 wants to merge 4 commits into
jfrog:mainfrom
Jordanh1996:feature/XRAY-133157-merge-base
Draft

XRAY-133157 - Scan the merge base instead of the target branch tip#1415
Jordanh1996 wants to merge 4 commits into
jfrog:mainfrom
Jordanh1996:feature/XRAY-133157-merge-base

Conversation

@Jordanh1996

Copy link
Copy Markdown
Contributor

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-41710 on spring-retry:2.0.12, on a PR with no pom.xml change. Their master already carried 2.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

downloadSourceAndTarget now 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:

  • Merge base resolved → scan that commit, log it at INFO.
  • Provider not yet implemented → scan the target tip, warn that results may contain findings already fixed on the target and that rebasing avoids it.
  • Any API error → scan the target tip, warn with the underlying error.

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

  • No generic-git fallback, deliberately. V2 computed this by fetching full history into a synthetic .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.sha is not the merge base. It looks correct and diverged in 11 of 25 sampled cli/cli PRs. Only the compare/merge-base endpoints are authoritative.
  • Every fallback warns. V2's silent fallback is why its breakage went unnoticed for a year; the warnings are asserted in tests, not just written.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant