Salesforce made Heroku OAuth token custody a developer-platform accountability test

Summary

• Heroku's 2022 GitHub-integration incident matters because OAuth tokens are not ordinary passwords; they are delegated authority that can connect source repositories, deployment pipelines, build systems, customer applications, and downstream software users.
• GitHub publicly warned that an attacker used stolen OAuth user tokens issued to Heroku and Travis CI, while Heroku's incident communications required customers to follow rotating guidance as investigation, revocation, and credential resets evolved.
• The accountability question is not only whether Heroku eventually rotated keys or restored integrations. It is who controlled token custody, customer notice, GitHub application behavior, source-code access evidence, CI/CD trust boundaries, and post-incident proof.
• This article treats Heroku, GitHub, Travis CI, Salesforce, IETF, NIST, CISA, and MITRE sources as separate evidence lanes; no public source is treated as a complete internal forensic record.
• The durable lesson is that developer-platform convenience has to carry a custody ledger: which integration token exists, why it exists, what scope it has, where it is stored, who can revoke it, and what evidence customers receive when the token becomes suspect.

Why this case belongs in a risk and accountability file

Salesforce made Heroku OAuth token custody a developer-platform accountability test because Heroku is a managed developer platform whose value rests on trust at the boundary between code, deployment, identity, and operations. Customers use Heroku to connect applications to source repositories, deploy code, automate build flows, manage teams, run add-ons, attach data services, and operate production workloads. A Heroku-to-GitHub integration is therefore not a cosmetic convenience. It can become a bridge from a customer's source-code system into a deployment platform and from a deployment platform back into customer operational risk.

The 2022 public trigger was visible because GitHub published a security alert at https://github.blog/news-insights/company-news/security-alert-stolen-oauth-user-tokens/ describing stolen OAuth user tokens issued to Heroku and Travis CI. Heroku's own status incident page at https://status.heroku.com/incidents/2413 and Heroku's public April 2022 incident review at https://blog.heroku.com/april-2022-incident-review frame the matter from the platform side. Travis CI's security bulletin at https://www.travis-ci.com/blog/2022-04-15-security-bulletin/ supplies another affected-integration lane. Those sources establish the public contours: OAuth tokens connected to developer workflows, customer notification, investigation updates, and a sequence of protective actions.

The case matters because OAuth changes the shape of accountability. A stolen password can often be explained through a single user account. A stolen OAuth token may represent delegated authority that survived beyond the moment a user last thought about consent. It may carry repository access, automated workflow access, API scope, metadata access, organization membership implications, or deployment authority. IETF OAuth 2.0 material at https://datatracker.ietf.org/doc/html/rfc6749 and the OAuth security best-current-practice record at https://datatracker.ietf.org/doc/html/rfc9700 are not incident reports about Heroku, but they help define why token issuance, scope, storage, rotation, revocation, replay resistance, and client trust matter.

The accountability file should not flatten Heroku, Salesforce, GitHub, Travis CI, and customers into one actor. Salesforce owned Heroku as a business and brand. Heroku controlled platform integration design, customer communications, credential handling in its platform, and the proof it could publish. GitHub controlled its own investigation, token revocation, source-host evidence, OAuth application controls, and customer-facing security alert. Travis CI controlled its affected integration channel and customer messaging.

Customers controlled their own repository permissions, deployment choices, secret rotation, audit review, and response to instructions. Downstream software users carried risk if source-code access or deployment trust produced later exposure.

That role map is important because developer platforms create shared responsibility without always giving shared evidence. Heroku customers could be told to rotate credentials or inspect repositories, but they could not independently reconstruct every Heroku-side token-storage path or GitHub-side attacker action. GitHub users could revoke an OAuth application, but they might not know which Heroku deployment pipeline, application, or team required replacement access. A procurement officer could ask whether the platform remained acceptable, but the decision depended on technical details that were not all public.

The accountable question is therefore evidence allocation: what did each actor know, what could each actor prove, and what did customers have to do while uncertainty remained?

The public record also shows why developer-tool incidents belong in software-supply accountability, not only account-security accountability. Source-code access is upstream of application security, secrets, CI/CD jobs, build artifacts, deployment credentials, and product releases. MITRE ATT&CK's application-access-token technique at https://attack.mitre.org/techniques/T1528/ and alternate-authentication-material technique at https://attack.mitre.org/techniques/T1550/ are useful vocabulary because they distinguish token misuse from ordinary credential guessing. CISA's secure-by-design materials at https://www.cisa.gov/securebydesign and NIST's Secure Software Development Framework at https://csrc.nist.gov/pubs/sp/800/218/final help explain why source-code custody and build-system trust have to be treated as production controls.

This article does not claim access to Heroku private logs, GitHub private repository audit data, Travis CI internal records, customer-by-customer notices, law-enforcement communications, or Salesforce board materials. It uses the public file to ask whether the evidence made practical control visible.

A strong accountability record would show not only that tokens were revoked, but when the suspicious activity was detected, what scopes were involved, which customers needed action, what repository access was confirmed or ruled out, what secrets might have been exposed, when credentials were rotated, and what changed so that the same token-custody path could not repeat silently.

OAuth consent becomes custody after the first click

The first operational mistake in many OAuth reviews is to treat consent as a one-time user decision. In a developer platform, consent becomes custody. Once a user authorizes an application to reach a repository, the platform, identity provider, source-code host, and customer administrator all inherit continuing obligations. The token has a lifecycle. It is issued, stored, refreshed, used, logged, scoped, revoked, replaced, and eventually forgotten or retired. The Heroku incident matters because the public record forced customers to think about that lifecycle after the trust decision had already been embedded in development workflows.

GitHub's current OAuth documentation at https://docs.github.com/en/apps/oauth-apps and maintaining-OAuth-app guidance at https://docs.github.com/en/apps/oauth-apps/maintaining-oauth-apps are useful because they show the control vocabulary around OAuth applications, client secrets, callback URLs, ownership, and application management. GitHub's enterprise audit-log guidance at https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/about-the-audit-log-for-your-enterprise shows why organizations need activity evidence after a suspected integration event. Heroku's GitHub integration documentation at https://devcenter.heroku.com/articles/github-integration shows the customer-visible feature surface. None of those documents proves exactly what happened in 2022. They establish the operating surface customers had to secure.

Custody means the platform must answer a different set of questions from ordinary uptime. Where were OAuth tokens stored? Were refresh tokens or access tokens involved? Were they encrypted, segmented, or isolated by tenant? Which service or database could read them? What monitoring would show unusual use? Who could revoke them? What customer action was needed after revocation? Could Heroku deploy from GitHub without the customer's renewed consent? Were build-time secrets, config variables, repository contents, or deployment keys at risk? Which of those answers were known at first notice, and which were still under investigation?

Those questions are not hostile. They are the basis of trust. A developer platform can have a valid reason to store tokens, but the reason has to be paired with protection evidence. A platform can revoke tokens quickly, but revocation evidence has to be paired with customer instructions. A platform can require rotation of Heroku user passwords or API keys, but customers need to know why that rotation is necessary and whether repository inspection is also required. A platform can say that no customer action is needed for a subset of users, but that statement should be tied to a technical boundary.

The Heroku public record included evolving customer instructions. That evolution is not automatically a failure. Incident response often moves from suspicion to confirmation through stages. The accountability issue is whether the stages are visible enough that customers can follow without guessing. If a customer's first message says one thing and a later message requires broader action, the platform should explain what evidence changed. If a customer is told to rotate credentials, the instruction should specify which credentials, which deadline, which application contexts, and which logs customers should review.

The economic dimension is real. Developer teams optimize for fast integration because manual deployment and credential management are expensive. OAuth apps reduce friction. But when the provider-side custody path fails, the cost of convenience reappears as emergency labor: reviewing repositories, rotating secrets, rebuilding integrations, searching logs, explaining exposure to customers, and answering auditors. Developer tool economics therefore belong in the article's topic list. The platform that benefits from easy integration has to invest in custody, revocation, and evidence.

Source-code access is not the same as production compromise, but it is not harmless

The public record has to resist two bad simplifications. The first is to say that stolen OAuth tokens automatically mean production applications were compromised. The second is to say that source-code access is harmless if no production outage occurred. Both statements are weak. Source code can contain application logic, dependency information, internal endpoints, deployment scripts, configuration patterns, test fixtures, comments, old secrets, infrastructure names, and security assumptions. At the same time, source-code access alone does not prove runtime access, data theft, or deployment manipulation.

GitHub's alert and Heroku's incident communications are important because they put source-code access risk into the public file. A customer with connected repositories needed to know whether an attacker could read private repositories, whether repositories had secrets committed, whether deployment credentials existed outside GitHub, whether GitHub Actions, Heroku pipelines, review apps, or CI jobs exposed additional materials, and whether repository-level audit logs showed unusual access. If the customer used Travis CI, the same questions could extend to CI environment variables and build logs.

NIST SP 800-218 at https://csrc.nist.gov/pubs/sp/800/218/final is useful because it treats secure software development as a lifecycle, not only code writing. NIST SP 800-204D at https://csrc.nist.gov/pubs/sp/800/204/d/final helps frame cloud-native application security and service identity questions. NIST SP 800-53 Rev. 5 at https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final gives control vocabulary for access control, audit, configuration, incident response, and system integrity. Those materials are not Heroku-specific findings. They are benchmarks for deciding whether a developer-platform incident should be reviewed as a software-supply event.

The key boundary is proof. If a platform can determine that an OAuth token was used only for a certain repository or customer set, it should explain the basis of that determination. If it cannot determine customer-by-customer access because of logging limits, it should say so. If GitHub can notify affected users based on token use or repository access, the public record should identify what the notification means and what it does not mean. If customers need to inspect their own logs, the provider should state which log sources matter.

The public risk also differs by customer maturity. A large enterprise may have GitHub enterprise audit logs, centralized secrets scanning, software composition analysis, CI/CD segregation, and incident-response staff. A smaller Heroku customer may have a simple GitHub connection, one or two maintainers, and limited log retention. The same token event therefore creates different burdens. A mature accountability record does not assume every customer can independently fill provider evidence gaps. It gives small teams practical steps and gives large teams enough technical detail to automate review.

The downstream audience is broader than Heroku account owners. If source-code access reveals vulnerabilities or secrets, downstream users of the customer's software may be affected later, even if the original platform incident did not cause immediate downtime. That does not mean every downstream user was harmed. It means the accountability analysis has to trace the risk path: token theft, possible repository access, possible source or secret exposure, possible CI/CD misuse, possible production access, and possible downstream harm. Each step needs evidence before it becomes a claim.

Notification timing is part of the control surface

Incident communication is often treated as a legal or public-relations function, but for developer platforms it is operational control. Customers cannot revoke tokens, rotate secrets, rebuild integrations, or inspect repositories until they know what to do. A delayed, vague, or changing notice can extend the period in which customers are exposed or unsure. A fast but incomplete notice can create unnecessary work. The accountability standard is therefore not simply speed. It is decision usefulness at each stage.

Heroku's incident page at https://status.heroku.com/incidents/2413 is useful because status updates show a sequence rather than a single final statement. GitHub's security alert supplies another timeline lane. Travis CI's bulletin supplies a third. A careful reader should not collapse those timelines into one perfect chronology unless the sources support it. The useful question is how each actor's notice changed customer action. Did customers need to revoke app authorization? Did they need to rotate Heroku API keys? Did they need to rotate Heroku user passwords? Did they need to inspect GitHub repositories? Did they need to check CI environment variables? Did they need to rebuild deployment hooks?

The answer may have changed as facts emerged. That is acceptable when the changes are explained. A notice can say "we are investigating possible access and will provide additional instructions." It can say "we have revoked tokens and customers must reauthorize." It can say "we require password reset because we cannot rule out access to hashed credentials." It can say "we found no evidence for a category, but customers should inspect their own logs for these indicators." What weakens accountability is not uncertainty. What weakens accountability is uncertainty presented as closure.

Customer notification also has a segmentation duty. Not every Heroku customer used GitHub integration. Not every GitHub user authorized Heroku. Not every Travis CI user had the same scope. Not every repository contained sensitive material. A useful notice distinguishes affected, potentially affected, unaffected, and unknown groups. If exact segmentation is not possible, the provider should explain why. Customers should not have to infer whether a message applies to them from broad headlines.

Communication quality can be measured. Did the provider publish durable incident pages? Did messages include dates and timestamps? Did they identify affected services? Did they provide concrete customer actions? Did they update prior guidance when it changed? Did they keep direct-customer and public records consistent? Did they publish a post-incident review that named control improvements without disclosing exploitable private detail? Those are accountability questions as much as communications questions.

In developer-tool economics, unclear communication transfers cost to customers. Every vague sentence becomes a meeting, a ticket, a log search, a customer email, or an audit exception downstream. A platform may be legally cautious, but a platform that sells developer trust should treat decision-useful notice as part of the product. The Heroku incident shows why incident communications need product engineering discipline: versioned instructions, scoped audiences, traceable corrections, and evidence of completion.

Forced rotation is a remedy only if customers know what changed

Forced credential rotation can be necessary and still incomplete as a trust repair. A customer may rotate an API key, reset a password, or reauthorize an OAuth app, but the customer also needs to understand what changed in the platform's custody model. If the same storage path, scope design, monitoring gap, or customer evidence gap remains, rotation may restore access without restoring confidence. The public record around Heroku's 2022 incident placed rotation and reauthorization at the center of customer action. The accountability question is whether those actions were matched by durable control evidence.

Heroku Dev Center pages such as https://devcenter.heroku.com/articles/oauth, https://devcenter.heroku.com/articles/platform-api-reference, https://devcenter.heroku.com/articles/heroku-cli, and https://devcenter.heroku.com/articles/account-security show the broader access-management environment around Heroku platform use. The Heroku two-factor authentication page at https://devcenter.heroku.com/articles/heroku-2fa provides customer-side account-hardening context. Again, current documentation is not proof of the 2022 internal state. It helps readers understand the kinds of credentials and user actions that can sit around a Heroku account.

Rotation has three distinct layers. First, there is revocation of compromised OAuth tokens so the attacker cannot continue using the delegated authorization. Second, there is customer-side replacement or reauthorization so legitimate workflows can resume with new tokens. Third, there is review of adjacent credentials, including API keys, passwords, deploy keys, CI variables, repository secrets, personal access tokens, and cloud credentials. A platform notice should make clear which layer is required and why.

The hardest layer is source-code secret exposure. If an attacker could read repositories, rotating only the OAuth token may not be enough. Customers may need to search repositories for committed secrets and rotate any exposed value. GitHub's secret-scanning documentation at https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning gives present-day vocabulary for that customer-side review. CISA's software supply chain guidance at https://www.cisa.gov/resources-tools/resources/software-supply-chain-risk-management-sscrm and secure-by-design materials help explain why secrets in code can turn a repository event into broader operational risk.

Forced rotation also needs a completion signal. Customers should know whether old tokens are invalid, whether reauthorization is required, whether disabled integrations will remain disabled until action, whether password reset completion is tracked, and whether stale credentials are still accepted anywhere. Without a completion signal, every customer has to run its own reconciliation. That is expensive and error-prone.

The platform also needs internal completion evidence. Which customer accounts completed required steps? Which accounts remain in exception state? Which customers were unreachable? Which integrations were abandoned? Which tokens could not be mapped to a current owner? Which controls were added to prevent silent long-lived token retention? A public postmortem may not disclose customer names, but it can disclose the shape of the cleanup. That is the difference between "we rotated" and "the risky state no longer exists."

GitHub, Heroku, Travis CI, Salesforce, and customers each owned different evidence

The incident's accountability map is multi-party. GitHub owned source-host evidence, OAuth-application visibility, and the security alert it published. Heroku owned its platform integration, customer communication, token custody, and forced credential program. Travis CI owned its affected CI/CD integration lane and customer guidance. Salesforce owned Heroku governance, resource allocation, risk escalation, and the duty to make platform repair credible. Customers owned repository hygiene, secrets rotation, organizational OAuth approvals, and deployment review. None of those roles cancels the others.

This matters because customer harm can result from gaps between roles. If GitHub knows a token was used but a customer does not know what Heroku application mapped to it, the customer's response is slower. If Heroku knows which accounts used GitHub integration but cannot tell whether repository contents were accessed, customers must review more broadly. If Travis CI and Heroku share a GitHub alert but have different customer instructions, organizations using both have to reconcile conflicting or overlapping actions.

If Salesforce treats Heroku as a subsidiary brand while customers treat Heroku as a production platform, governance has to bridge the brand boundary.

Cloud and SaaS shared-responsibility documents often say that provider and customer obligations differ. The Heroku incident shows that shared responsibility also requires shared evidence. A customer cannot responsibly accept a provider's assurance if the provider does not disclose which part of the chain the assurance covers. A provider cannot responsibly shift all action to customers if customers lack the logs or product features needed to act. A source host cannot assume downstream tools will translate its alert perfectly. Each actor has to make its evidence useful to the next actor in the chain.

The IETF, NIST, MITRE, CISA, GitHub, Heroku, and Travis CI sources together form a bounded public file. They do not reveal every private fact, but they allow a clear accountability model. OAuth tokens should be scoped narrowly, stored defensibly, revocable quickly, monitored continuously, and mapped to current business purpose. Developer platforms should communicate incidents with enough specificity to let customers act. Customers should review integrations periodically instead of treating authorization as permanent.

Source hosts should make audit evidence available enough that customers can distinguish possible exposure from confirmed access.

The role map also cautions against simplistic blame. If an attacker steals a token, the attacker is responsible for misuse. But accountability asks who could reduce the opportunity, blast radius, and uncertainty. Token-storage design can reduce opportunity. Scope minimization can reduce blast radius. Fast revocation can reduce duration. Good logs can reduce uncertainty. Clear customer instructions can reduce wasted labor. Post-incident control evidence can reduce recurrence. Those are design choices, not only after-the-fact statements.

Customer-verifiable evidence is the missing half of shared responsibility

The Heroku incident also shows the limit of shared-responsibility language when evidence is asymmetric. A platform can tell customers that they are responsible for repository hygiene, secret rotation, and OAuth-app review, but the customer still depends on provider evidence to decide where to look. If the provider cannot say whether a token had repository read scope, whether it was used after a certain date, whether it was tied to a particular application, or whether customer-specific logs exist, then customer responsibility becomes a guessing exercise. A fair shared-responsibility model gives customers both duties and usable evidence.

Customer-verifiable evidence begins with an inventory. Each customer should be able to see which Heroku applications were connected to which GitHub organizations, repositories, users, and deployment flows. The inventory should show current status, last authorization, scope, owner, reauthorization requirement, and whether the connection was disabled by the provider. Without that map, a security team must reconstruct the integration from old tickets, repository webhooks, deployment history, and personal developer accounts. That is exactly the kind of emergency labor a platform should reduce after a provider-side token event.

The second evidence layer is activity. Customers need to know which logs can show repository access, OAuth authorization use, API-key use, Heroku account activity, deployment events, build events, and configuration changes. If the relevant evidence exists only on GitHub, the provider should direct customers to GitHub audit records. If relevant evidence exists only on Heroku, the provider should expose a customer-specific view or support path. If some evidence is unavailable because logging was not retained or was not collected, the provider should say that clearly.

"No evidence of misuse" is decision-useful only when customers know what evidence was reviewed.

The third layer is secret exposure. Repository access risk is not limited to source code as intellectual property. It also includes committed secrets, historical configuration, test credentials, deployment tokens, cloud keys, database connection strings, and comments that reveal architecture. Customers need guidance that links the token incident to secret-scanning and rotation. A strong platform response would say which categories are likely, which categories are possible, and which categories are outside the known path. It would also avoid implying that a token revocation alone closes repository-content risk.

The fourth layer is software-release assurance. If a customer uses Heroku for automatic deploys from GitHub, the customer needs to know whether unauthorized repository access could have influenced deployed code, build artifacts, review apps, pipelines, or release history. That does not mean such influence occurred. It means the customer should receive enough information to prove or disprove it. Release history, build provenance, deployment timestamps, repository commit signatures, branch protections, and CI logs all become part of the accountability file.

The fifth layer is durable cleanup. A customer should be able to tell when the suspicious state ended. Were old OAuth tokens revoked? Were integrations reauthorized with new tokens? Were password or API-key rotations completed? Were abandoned applications disabled? Were orphaned personal authorizations removed? Did the platform prevent the old token class from remaining active in any background job or legacy path? Provider assurance is strongest when customers can reconcile their own tenant state against provider completion evidence.

This customer-evidence model does not require a provider to publish sensitive private logs on the open web. It can be delivered through account dashboards, direct notices, support exports, enterprise incident briefings, or contractual evidence packs. The form can vary by customer tier and sensitivity. The principle should not vary: when a provider asks customers to act, it should also supply the evidence customers need to act proportionately.

Procurement and governance should treat integrations as standing access

The procurement lesson is that OAuth integrations are standing access, not one-time setup tasks. A vendor-risk questionnaire that asks only whether the provider supports encryption, multifactor authentication, or uptime targets will miss the Heroku lesson. The sharper questions are about integration inventory, token storage, scope minimization, customer logs, emergency revocation, tenant-level notifications, build-system isolation, and post-incident proof. Developer platforms should expect those questions because their products intentionally sit close to software delivery.

Contract language should also avoid vague responsibility transfers. A provider can require customers to protect their repositories and credentials, but it should state how provider-side integration incidents will be handled. Will the provider notify every customer using the affected integration? Will it provide affected time windows? Will it identify whether source-code access is confirmed, possible, or not observed? Will it require reauthorization? Will it expose audit events? Will it provide a post-incident summary? Will it support regulated customers that need their own notifications? These are not luxury terms for large enterprises.

They are basic operational questions for any customer whose software supply chain depends on the platform.

Governance inside Salesforce and Heroku also matters. The public should not assume that a subsidiary brand carries less accountability because it is developer-focused. Heroku applications can be production applications, internal tools, public APIs, prototypes that became critical, or back-office systems that handle sensitive workflow. The ownership structure matters because governance determines investment in logging, token custody, incident response, customer support, and security engineering. A parent company does not need to disclose every board discussion to show that a developer-platform incident received serious control attention.

The same governance question applies to product management. A product team may want seamless GitHub integration because it reduces friction and helps customers deploy quickly. A security team may want short-lived tokens, narrow scopes, customer-visible logs, and periodic reauthorization. A support team may want messages simple enough for small customers. An enterprise sales team may want contract evidence. Accountability appears where those incentives are reconciled before an incident, not only after one. If the platform cannot explain who owns token-custody risk in normal operations, it will struggle to explain who owns it during a crisis.

For customers, the practical governance response is to classify integrations by consequence. A personal productivity integration is different from a deployment integration that can read production source code. A read-only repository app is different from an app that can create deployments or manage webhooks. A trial Heroku app is different from a customer-facing production application. Organizations should assign stronger review, logging, and recertification to integrations that can affect production code or secrets. The Heroku incident is a reminder that "connected app" is a governance entity, not only a convenience feature.

The result is a more mature accountability standard. Developer platforms should publish enough incident evidence that customers can complete their own risk decisions. Customers should maintain enough integration inventory that provider evidence can be acted on quickly. Source-code hosts should keep OAuth and audit controls usable. CI/CD vendors should separate build secrets from broad repository trust. Parent companies should treat developer trust as production trust. The 2022 Heroku incident becomes more than a historical security alert when it is read this way.

It becomes a test of whether the software delivery chain can identify standing access before attackers force everyone to look.

What durable repair should look like after an OAuth custody incident

The durable repair standard for a developer-platform OAuth incident has at least eight parts. First, the provider should publish a clear timeline: detection, GitHub notification, Heroku investigation, customer notification, token revocation, credential rotation, reauthorization availability, and postmortem. Second, it should identify the affected integration surface without implying that every customer or repository was equally affected. Third, it should explain the difference between stolen OAuth tokens, customer passwords, API keys, deploy keys, repository secrets, and CI variables.

Fourth, the provider should publish customer actions in a checklist that distinguishes required, recommended, and conditional steps. Fifth, it should state what evidence the customer can see and what evidence only the provider or source host can see. Sixth, it should identify what controls changed: token storage, encryption, secret management, scope review, monitoring, anomaly detection, customer audit access, or integration deprecation. Seventh, it should provide a completion signal, such as forced reset completion, token revocation completion, or reauthorization enforcement. Eighth, it should state residual unknowns clearly.

The Heroku public file contains meaningful evidence, but the accountability lesson is broader than one incident. Developer platforms should design for suspicious-token days before they happen. That means OAuth application inventory, owner mapping, scope minimization, token-age tracking, automated revocation workflows, customer notification templates, customer-specific action pages, audit-log export, and periodic integration recertification. It also means testing the customer experience of a forced reauthorization before a crisis. If customers cannot understand the repair path on a calm day, they will not understand it during an incident.

Customers also need durable habits. They should inventory OAuth apps, remove unused integrations, restrict organization-wide approval, require review for high-scope apps, use secret scanning, avoid committing credentials, rotate long-lived secrets, preserve audit logs, and map deployment flows. GitHub and Heroku documentation provide many of the building blocks, but the governance work belongs to each organization. A vendor incident becomes more manageable when customers already know which apps are connected to which repositories and production systems.

The final accountability test is not whether the platform can say that the incident is closed. It is whether the closure can be traced to evidence. Were suspect tokens invalidated? Were impacted customers notified? Were required resets completed? Were source-code access questions answered at the level the evidence allowed? Were secrets and deployment credentials reviewed? Were product controls changed? Were residual unknowns preserved? A "yes" to those questions is stronger than a general statement of confidence because it tells customers what changed.

Heroku's 2022 OAuth incident therefore belongs in Daniel Kade's risk-and-accountability series because it makes developer trust visible. The incident turns a familiar integration button into a custody question. It shows that source-code platforms, deployment platforms, CI/CD vendors, and customers are connected by delegated authority that survives the user click. When that authority is stolen, accountability follows the token: who issued it, who stored it, who could see it, who revoked it, who warned users, who proved repair, and who paid the cost while proof was still incomplete.