OSINT Jet · Public code provenance

GitHub OSINT: Did This Account Build the Project or Copy It?

A repository sitting under an account’s name does not tell you which parts that account created. Start with the claimed contribution, then trace the relevant change. The useful result is a small, checkable account of who is credited with what—not a verdict based on a profile picture or a busy contribution chart.

Turn “we built this” into a question you can answer

Suppose a supplier links a public repository as evidence of a scheduling feature. Before exploring the account, ask what the link is supposed to demonstrate: publishing the repository, writing the feature, maintaining it today, or operating the service. Those are different claims. A good contribution check starts with a named file, behavior or release.

Write the claim exactly as presented and retain its source. If the wording is only “our project,” do not quietly turn that into “we wrote every line.” Your first finding may be that the claim is too vague to verify.

Keep four objects on separate rows

GitHub describes a fork as a separate repository that begins as a copy of an upstream repository. The upstream link appears below a fork’s name. That is a reason to examine the inherited history, not to dismiss the fork: a small addition can be valuable. See GitHub’s fork reference.

No visible fork label is not enough to declare a project original. Keep that conclusion open unless the evidence supports it. The test is about the claimed work, not whether a platform badge happens to appear.

Read the change before counting the commits

Open the relevant file’s history and select the change tied to the claim. The diff—the comparison showing additions and removals—should answer a concrete question. Was this a new scheduling function, a documentation correction, a dependency update or a renamed variable? Read enough surrounding code or documentation to avoid mistaking a label for a feature.

You do not need to download or run unfamiliar code to inspect public text and history. If understanding the behavior requires execution or specialist review, record that as an untested part. A read-through cannot establish that software works, is safe or was deployed.

For the handoff, keep the full commit link and a link to the exact file version. GitHub documents the Y shortcut for turning a file view into a commit-specific permalink. A branch link can later display changed content. See permanent file links. A stable version reference still depends on the material remaining accessible.

A name and a Verified badge answer different questions

A Git author name is configurable text; it is not the same field as a GitHub account name. Do not identify a person from that name alone. GitHub’s name-setting documentation explains the distinction.

A Verified commit badge concerns signature verification. Open its details and preserve what it says. It does not certify the truth of the README, the quality of the code or the signer’s employment. GitHub also retains successful verification records within a repository network, so the badge is not a fresh check of every present-day relationship. See signature verification documentation.

Worked case: a long history and a very small addition

Fictional teaching case. A supplier presents “Calendar Lantern” as its scheduling engine. Its repository carries a fork notice pointing to an upstream project. The linked upstream version already contains the scheduling function. In the supplier’s branch, the one change attached to the claim replaces the README’s contact address. These observations are invented for this exercise, not a product test or a real accusation.

The correct finding is narrow: “The reviewed copy inherits the scheduling function from the identified upstream version. The inspected change updates contact information; it does not demonstrate authorship of that function.” Do not extend this to “the supplier never contributes” or “the entire service is fake.” Work elsewhere may exist, and deployment was not examined.

Now change one fact: the diff adds a documented accessibility option. The finding changes with it. Credit that option where the attribution evidence supports it, while keeping the inherited scheduler separate. Counting all inherited commits would miss both the exaggeration in the first case and the useful work in the second.

A provenance note that another reviewer can use

Claim and where it appeared:
Repository URL and observation date:
Visible upstream relationship:
Feature or file under review:
Exact commit and file-version links:
Observed change:
Displayed attribution and signature details:
Supported contribution / unresolved part:
What was not tested:

If the account name has changed, use the separate username-change guide before merging old and new references. If this is part of a broader supplier review, keep the project evidence alongside the company verification work rather than treating either as a substitute for the other.

One clearly explained diff may settle the question without a paid service. When a public software claim conflicts with company, website and representative claims, OSINT Jet’s manual investigation route gives you a place to request a defined review. Supply the exact links and the disputed contribution. Ask for scope and pricing before commissioning work; do not assume an automatic GitHub integration or a code audit is included.