GitHub credential inventory: turn the CSV into an exposure graph
The enterprise inventory brings tokens, keys and authorizations together; its security value emerges when metadata is normalized, correlated with audit evidence and tied to tested revocation.
Content produced with AI assistance for Thiago Silva’s website. Independent editorial analysis; it does not represent clients or employers.
The news behind this analysis
On September 21, 2026, GitHub announced credential inventory exports for Enterprise Cloud. According to the vendor, enterprise owners or roles with the View enterprise credentials permission can inspect metadata for SSH keys, personal access tokens, OAuth and GitHub Apps through CSV or API. The capability is read-only; the recommendations below are editorial analysis.
Original source ↗Inventory is evidence, not remediation
The new view closes a common incident-response gap: learning which credentials exist, who controls them and which organizations or repositories they reach. The documentation lists owner, state, creation, last use, expiry, scopes, permissions and repository selection. It also clarifies that secret values are not exposed. This makes the inventory useful for investigation without turning it into a vault of reusable tokens.
A row in the file does not prove abuse, however, and lack of recent use does not prove safety. The inventory is read-only, while access suspension, revocation or authorization removal varies by credential type. A response procedure must separate discovery, context validation and action. Revoking everything that looks old can disrupt legitimate people and automation; doing nothing because the file lacks the secret can leave active exposure in place.
Model relationships, not just rows
The CSV may repeat the same credential for every organization that authorized it. Some identifiers are unique only when combined with the credential type, and the opaque inventory identifier can change. Counting rows as distinct credentials therefore distorts exposure. Normalize type, the available stable identifier, owner and state first; then model relationships among identity, credential, application, organization and reachable repository.
The more useful output is an authorization graph with provenance: who issued or controls the credential, what permissions it carries, where it can act and when it was observed. In a hypothetical scenario, a narrowly scoped token authorized across many organizations may deserve higher priority than a broader token isolated in a lab. Priority should combine reach, destination sensitivity, expiry, last use and identity controls without converting a heuristic into an automatic verdict.
Correlate with audit evidence before concluding
The documentation recommends correlating token hashes or IDs and SSH fingerprints with audit events. That link changes the question from “what exists?” to “where and when was it used?”. Preserve the identifier used for the query, time window, filters and result. If an event cannot be tied to an authorized person or workload, record the attribution gap instead of filling it with an assumption.
Define a triage sequence: validate the owner, confirm purpose, examine authorizations, search for matching events and only then decide containment. An indicator such as “never expires” increases potential risk but does not demonstrate compromise. Likewise, no events may reflect insufficient retention or incomplete integration. Evidence should distinguish observed fact, vendor claim and analyst inference so leaders and responders understand the confidence behind each conclusion.
Protect the export as security data
The file does not contain secrets, but it maps valuable owners, permissions and targets. Restrict exports to the minimum role, record who requested them, use short retention and store them in an encrypted location with monitored access. The API requires enterprise read privileges; the asynchronous export produces a temporary URL. Neither mechanism removes the need to control local copies, attachments or pipeline artifacts.
For recurring automation, prefer incremental ingestion with the cursor treated as opaque and maintain a collection marker of your own. The API provides no total count, and export limits mean availability should not be assumed to be unlimited. Test pagination, partial failure and replay before feeding the data to a dashboard. Metrics should expose collection coverage and age, not just a credential count that may be incomplete or duplicated.
Revocation needs an owner and a rehearsal
Run an exercise with synthetic or test credentials: discover the item, correlate an event, identify dependencies, revoke it through the correct workflow and confirm access has stopped. Include reissuance and recovery for essential automation. The documentation warns that revocation can disrupt users and systems, so the decision needs an accountable owner, emergency criteria, communication and completion evidence.
The production architecture package should include the data model, permission matrix, export protection, audit correlation, prioritization rules and containment runbook. The business outcome is not another CSV; it is reducing the time from discovering a credential to making a defensible decision without causing unnecessary disruption. This analysis does not report a Thiago Silva deployment or human review of an environment; it proposes verifiable controls for a real assessment.