How would your incident response to a hardcoded secret committed to a repository differ if the repository were private rather than public?

The core response is the same either way — rotate the credential immediately, treat it as compromised — because "private" only means restricted to a specific audience, not "never exposed to anyone untrusted": every current collaborator, every CI system with repo access, and (for platforms that cache or index content) potentially the platform itself all had access to that secret, and any one of those could be compromised independently of the repository's own visibility setting. The genuine difference is scope of exposure, not whether rotation is necessary — a public-repo exposure needs to assume the secret was seen by anyone in the world (including automated scanners that actively look for exactly this), while a private-repo exposure's exposure is bounded by the actual list of people/systems with repository access, which affects the scope of investigation but not the decision to rotate.

The instinct that "private repo" means "safer, maybe don't need to rotate" doesn't hold up to scrutiny once you consider who actually had access. A private repository is still accessible to every current collaborator with repo access, every CI/CD system integrated with it, any third-party tool with repo access (a code-quality scanner, a deployment tool), and potentially cached or indexed by the hosting platform itself in ways not immediately visible (search indexing, code-scanning features, or platform-internal processes). Any of these represents a real, if smaller, population that had access to the secret — and any single compromised account or system among that population is enough to have actually exposed it, regardless of the "private" label. Given that, "was this secret exposed to anyone untrusted" isn't fully answerable just from the repo being private, which is why rotation remains the correct default response either way.

What genuinely differs: scope of investigation. For a public repo, the investigation has to assume worst-case exposure — anyone in the world could have seen it, including automated bots that actively scrape GitHub and similar platforms specifically looking for committed secrets (this happens at real, documented scale, often within minutes of a secret being pushed to a public repo) — so the investigation focuses on "assume compromised, minimize time-to-rotation" rather than trying to determine who specifically saw it. For a private repo, the actual population with access is enumerable (the specific list of collaborators, integrated CI systems, connected third-party tools), which makes it feasible to investigate more specifically — checking access logs for suspicious activity from that bounded population, rather than assuming the worst case by default.

What doesn't differ: the rotation decision itself, and the git-history remediation question (rewriting history versus rotating and accepting a worthless value remains in history) — these are the same considerations regardless of repo visibility, since both flow from "the secret is potentially compromised," not from "how many people could see it."

• A private repository's "private" label restricts visibility to a specific audience, but that audience (collaborators, CI systems, third-party integrations, platform indexing) is still a real population that could have been compromised — rotation remains the correct default response either way.
• Public repositories require assuming worst-case, world-wide exposure, including automated bots actively scanning for committed secrets at scale.
• Private repositories allow a more specific, bounded investigation (checking the actual enumerable population with access) rather than assuming worst-case exposure by default.
• The rotation decision and git-history remediation question are the same regardless of repository visibility — both follow from "potentially compromised," not from audience size.

• GitHub Docs: About secret scanning
• GitHub Docs: Removing sensitive data from a repository