DEV Community

Ranvir Jat
Ranvir Jat

Posted on

I built UpstreamWitness to trace what changed upstream after your fix or security report

When you submit a fix, bounty report, or open-source contribution, the story usually ends in a messy way.

You may know what you reported. You may know roughly when it was submitted. Then, days or weeks later, the upstream repository changes.

A file moves. A symbol changes. A PR lands. A release ships. Maybe the change is related to your work. Maybe it is not.

The hard part is separating publicly verifiable evidence from assumption.

That is the problem I built UpstreamWitness to handle.

UpstreamWitness is an open-source Python CLI that traces public GitHub activity after a baseline and produces a reproducible evidence report. It is designed for security researchers, bounty workers, open-source contributors, and maintainers who need a disciplined answer to one question:

What changed upstream after this work was submitted?

It correlates public activity using things like:

  • changed files,
  • patch symbols,
  • textual anchors,
  • PR review and merge state,
  • releases,
  • deterministic fingerprints.

It deliberately does not claim that correlation proves attribution, bounty acceptance, legal entitlement, or payment entitlement. That distinction matters.

Try it in about 60 seconds

``bash python -m pip install "git+https://github.com/ranvirjrj-beep/UpstreamWitness.git" ``

Then trace a public pull request:

``bash upstreamwitness trace-pr https://github.com/owner/repo/pull/123 --out-dir my-trace ``

The output is meant to be inspectable and reproducible rather than persuasive by wording alone.

Why I built it

During security and bounty work, I kept running into the same evidence problem: the useful facts were spread across commits, pull requests, reviews, releases, and code changes. Manually reconstructing the sequence is slow, and it is very easy to overstate what the public record actually proves.

UpstreamWitness turns that into a repeatable workflow.

What I want from early users

I am looking for researchers, contributors, and maintainers with a public PR or sanitized public-repository case who are willing to test the workflow and tell me where it breaks, confuses, or wastes time.

Please do not submit private vulnerability details, secrets, customer data, private PoCs, or confidential report text.

If you have a suitable public case, open a Public trace request here:

https://github.com/ranvirjrj-beep/UpstreamWitness/issues

Repo:

https://github.com/ranvirjrj-beep/UpstreamWitness

The project is Apache-2.0, Python 3.11+, with no runtime third-party dependencies.

If you work in bug bounty, OSS maintenance, or security research and this solves a problem you have actually had, I would especially like to hear what evidence you still have to gather manually today.

Top comments (0)