{
  "id": 7744569,
  "title": "I Built UpstreamWitness to Track What Happens After You Submit a Fix",
  "url": "https://urgent.news/2026/09/16/i-built-upstreamwitness-to-track-what-happens-after-you-submit-a-fix",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-16T08:24:48.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/ranvir_jat_de4777a8ac884e/i-built-upstreamwitness-to-track-what-happens-after-you-submit-a-fix-2k0o"
  },
  "original_language": "en",
  "account": "Submitting a pull request, bounty fix, or public security report is just the beginning. The real challenge lies in determining if the changes made on upstream reflect the submitted work. It can be tricky as multiple scenarios are possible. A maintainer might directly merge your request, implement a similar fix on their own, or leave your branch untouched. Review state can also become outdated, with an old review not matching the current state of a PR. This is where UpstreamWitness comes into play. UpstreamWitness is an open-source tool designed to help security researchers, bounty workers, and open-source contributors track and analyze public evidence related to their submissions. By starting from a public baseline, such as a pull request or submission date, it examines later upstream activity including commits, pull-request states, releases, changed paths, symbols, and keyword overlap. It then generates a Markdown and JSON evidence report. However, it's crucial to understand that this tool does not claim correlation evidence as proof of attribution, bounty acceptance, legal entitlement, or payment.\n\nThe tool makes a distinction between different outcomes. UPSTREAM_CONFIRMED means the tracked public PR has been merged upstream. STRONG_SIGNAL indicates multiple independent public evidence channels that correlate with future upstream changes, but human verification is still needed. POSSIBLE_SIGNAL refers to weaker but meaningful multi-channel overlap. NO_PUBLIC_SIGNAL means no meaningful public evidence was found. This helps maintain the tool's usefulness without overestimating what public evidence can support.\n\nOne subtle case is dealing with stale review state. If a reviewer requests changes on commit A, and the contributor pushes commit B fixing the issue, it might seem like the PR is still rejected even if the branch has evolved. UpstreamWitness addresses this by recording the chronology rather than collapsing everything into a single status label. It also distinguishes contributor branch updates from actual upstream adoption - a distinction that is important in bounty and security work.\n\nUpstreamWitness is built around public repositories and public evidence, meaning it doesn't require confidential information like vulnerability reports, private discussions, secrets, or internal correspondence. If private information is needed, the tool should fail closed rather than inadvertently sharing confidential material. To start using UpstreamWitness, you can create a sanitized trace case for a public pull request with a command like: `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. The next stage is real usage, so if you have a public PR where you're unsure about whether upstream has adopted related changes, open a public trace request in the repository. You only need a repo/PR URL, no confidential report text is needed. For more information, visit the GitHub repository: https://github.com/ranvirjrj-beep/UpstreamWitness. The release candidate can be found at: https://github.com/ranvirjrj-beep/UpstreamWitness/releases/tag/v0.1.0-rc.1. The goal is to make post-submission evidence easier to inspect while keeping conclusions disciplined.",
  "summary": "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…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}