When you submit a pull request, bounty fix, or public security report, the hard part is often not the submission itself. The hard part comes later:
Did upstream actually change in a materially related way?
That sounds simple, but it is easy to get wrong.
A maintainer may merge your PR directly. Or they may implement a similar fix independently. Or only your contributor branch may change while upstream stays untouched. Review state can also become stale: an old CHANGES_REQUESTED review does not necessarily describe the current head of a PR.
That is the gap I built UpstreamWitness to address.
What UpstreamWitness does
UpstreamWitness is an open-source public-code evidence tracker for security researchers, bounty workers, and open-source contributors.
It starts from a public baseline — for example a pull request or submission date — and examines later public upstream activity such as:
- commits
- pull-request state
- releases
- changed paths
- symbols and high-precision anchors
- keyword overlap
- review chronology
It then produces a Markdown and JSON evidence report.
The important part is what it does not claim: correlation evidence is not proof of attribution, bounty acceptance, legal entitlement, or payment.
Why this distinction matters
Suppose your PR is still open, but two weeks later upstream changes the same path and touches the same symbol.
That may be interesting evidence, but it is not the same thing as your PR being merged.
UpstreamWitness therefore separates outcomes:
-
UPSTREAM_CONFIRMED— the tracked public PR itself was merged upstream. -
STRONG_SIGNAL— multiple independent public evidence channels correlate with later upstream changes; human verification is still required. -
POSSIBLE_SIGNAL— weaker but meaningful multi-channel overlap. -
NO_PUBLIC_SIGNAL— no meaningful public evidence found.
This keeps the tool useful without pretending to know more than the public evidence can support.
Review chronology is part of the evidence
One subtle case is stale review state.
A reviewer may request changes on commit A. The contributor then pushes commit B fixing the issue. If you only look at the old review label, you may conclude the PR is still rejected even though the branch has evolved.
UpstreamWitness records the chronology instead of collapsing everything into a single status label.
It also distinguishes a contributor branch update from actual upstream adoption. That distinction sounds obvious, but it matters a lot in bounty and security work.
Privacy boundary
UpstreamWitness is deliberately built around public repositories and public evidence.
It does not require you to upload a confidential vulnerability report, private bounty discussion, secrets, or internal correspondence.
If a case depends on private information, the tool should fail closed rather than silently turning confidential material into a public demo.
Quick start
For a public pull request, the initializer can create a sanitized trace case:
``bash upstreamwitness trace-pr https://github.com/owner/repo/pull/123 --out-dir my-trace ``
The project uses Python 3.11–3.13 and a standard-library runtime for the core package.
Where I want real feedback
I do not want to keep adding speculative features. The next stage is real usage.
If you have a public PR where you are genuinely unsure whether upstream later adopted related changes, open a public trace request in the repository. A repo/PR URL is enough; do not include confidential report text.
GitHub: https://github.com/ranvirjrj-beep/UpstreamWitness
Release candidate: https://github.com/ranvirjrj-beep/UpstreamWitness/releases/tag/v0.1.0-rc.1
The goal is simple: make post-submission evidence easier to inspect, while keeping the conclusions disciplined.
Top comments (0)