Salesforce transformou a custódia de token OAuth da Heroku em um teste de responsabilidade de plataforma para desenvolvedores

Resumo

• O incidente de integração com o GitHub da Heroku em 2022 é importante porque tokens OAuth não são senhas comuns; são autoridade delegada que pode conectar repositórios de código-fonte, pipelines de implantação, sistemas de build, aplicações de clientes e usuários downstream de software.
• O GitHub alertou publicamente que um invasor usou tokens de usuário OAuth roubados emitidos para Heroku e Travis CI, enquanto as comunicações do incidente da Heroku exigiram que os clientes seguissem orientações de rotação conforme a investigação, revogação e redefinição de credenciais evoluíam.
• A questão de responsabilidade não é apenas se a Heroku eventualmente rotacionou chaves ou restaurou integrações. É quem controlou a custódia do token, o aviso ao cliente, o comportamento do aplicativo GitHub, as evidências de acesso ao código-fonte, os limites de confiança de CI/CD e a prova pós-incidente.
• Este artigo trata fontes da Heroku, GitHub, Travis CI, Salesforce, IETF, NIST, CISA e MITRE como faixas de evidência separadas; nenhuma fonte pública é tratada como um registro forense interno completo.
• A lição duradoura é que a conveniência da plataforma para desenvolvedores tem que vir acompanhada de um registro de custódia: qual token de integração existe, por que existe, qual escopo tem, onde está armazenado, quem pode revogá-lo e quais evidências os clientes recebem quando o token se torna suspeito.

Por que este caso pertence a um arquivo de risco e responsabilidade

A Salesforce tornou a custódia de token OAuth da Heroku um teste de responsabilidade de plataforma para desenvolvedores porque a Heroku é uma plataforma gerenciada para desenvolvedores cujo valor depende da confiança na fronteira entre código, implantação, identidade e operações. Os clientes usam a Heroku para conectar aplicações a repositórios de código-fonte, implantar código, automatizar fluxos de build, gerenciar equipes, executar complementos, anexar serviços de dados e operar cargas de trabalho de produção. Uma integração Heroku-para-GitHub não é, portanto, uma conveniência cosmética.

Pode se tornar uma ponte do sistema de código-fonte de um cliente para uma plataforma de implantação e de uma plataforma de implantação de volta para o risco operacional do cliente.

O gatilho público de 2022 foi visível porque o GitHub publicou um alerta de segurança emhttps://github.blog/news-insights/company-news/security-alert-stolen-oauth-user-tokens/descrevendo tokens de usuário OAuth roubados emitidos para Heroku e Travis CI. A própria página de incidentes de status da Heroku emhttps://status.heroku.com/incidents/2413e a revisão pública do incidente de abril de 2022 da Heroku emhttps://blog.heroku.com/april-2022-incident-reviewenquadram o assunto do lado da plataforma. O boletim de segurança da Travis CI emhttps://www.travis-ci.com/blog/2022-04-15-security-bulletin/fornece outra faixa de integração afetada. Essas fontes estabelecem os contornos públicos: tokens OAuth conectados a fluxos de trabalho de desenvolvedores, notificação ao cliente, atualizações de investigação e uma sequência de ações protetivas.

O caso é importante porque o OAuth muda a forma da responsabilidade. Uma senha roubada muitas vezes pode ser explicada por meio de uma única conta de usuário. Um token OAuth roubado pode representar autoridade delegada que sobreviveu além do momento em que o usuário pensou sobre consentimento. Pode carregar acesso a repositórios, acesso a fluxos de trabalho automatizados, escopo de API, acesso a metadados, implicações de associação a organizações ou autoridade de implantação. O material do IETF OAuth 2.0 emhttps://datatracker.ietf.org/doc/html/rfc6749e o registro de melhores práticas atuais de segurança OAuth emhttps://datatracker.ietf.org/doc/html/rfc9700não são relatórios de incidentes sobre a Heroku, mas ajudam a definir por que emissão, escopo, armazenamento, rotação, revogação, resistência a replay e confiança do cliente são importantes.

O arquivo de responsabilidade não deve nivelar Heroku, Salesforce, GitHub, Travis CI e clientes em um único ator. A Salesforce possuía a Heroku como negócio e marca. A Heroku controlava o design da integração da plataforma, as comunicações com o cliente, o manuseio de credenciais em sua plataforma e a prova que poderia publicar. O GitHub controlava sua própria investigação, revogação de tokens, evidências de host de código-fonte, controles de aplicativos OAuth e alerta de segurança voltado ao cliente. A Travis CI controlava seu canal de integração afetado e mensagens aos clientes.

Os clientes controlavam suas próprias permissões de repositório, escolhas de implantação, rotação de segredos, revisão de auditoria e resposta às instruções. Usuários downstream de software carregavam risco se o acesso ao código-fonte ou a confiança na implantação produzisse exposição posterior.

Esse mapa de papéis é importante porque plataformas para desenvolvedores criam responsabilidade compartilhada sem sempre fornecer evidências compartilhadas. Os clientes da Heroku podiam ser instruídos a rotacionar credenciais ou inspecionar repositórios, mas não podiam reconstruir independentemente cada caminho de armazenamento de token do lado da Heroku ou ação do invasor do lado do GitHub. Os usuários do GitHub podiam revogar um aplicativo OAuth, mas poderiam não saber qual pipeline de implantação, aplicativo ou equipe da Heroku exigia acesso de substituição.

Um oficial de compras podia perguntar se a plataforma permanecia aceitável, mas a decisão dependia de detalhes técnicos que não eram totalmente públicos. A questão de responsabilidade é, portanto, alocação de evidências: o que cada ator sabia, o que cada ator podia provar e o que os clientes tiveram que fazer enquanto a incerteza persistia?

O registro público também mostra por que incidentes de ferramentas de desenvolvedores pertencem à responsabilidade da cadeia de suprimentos de software, não apenas à responsabilidade de segurança de contas. O acesso ao código-fonte está a montante da segurança de aplicações, segredos, trabalhos de CI/CD, artefatos de build, credenciais de implantação e lançamentos de produtos. A técnica de token de acesso de aplicação do MITRE ATT&CK emhttps://attack.mitre.org/techniques/T1528/e a técnica de material de autenticação alternativo emhttps://attack.mitre.org/techniques/T1550/são vocabulário útil porque distinguem uso indevido de token de adivinhação comum de credenciais. Os materiais de design seguro por padrão da CISA emhttps://www.cisa.gov/securebydesigne a Estrutura de Desenvolvimento Seguro de Software do NIST emhttps://csrc.nist.gov/pubs/sp/800/218/finalajudam a explicar por que a custódia do código-fonte e a confiança no sistema de build devem ser tratadas como controles de produção.

Este artigo não alega acesso a logs privados da Heroku, dados de auditoria de repositório privado do GitHub, registros internos da Travis CI, avisos cliente por cliente, comunicações de aplicação da lei ou materiais do conselho da Salesforce. Ele usa o arquivo público para perguntar se as evidências tornaram o controle prático visível.

Um registro de responsabilidade forte mostraria não apenas que os tokens foram revogados, mas quando a atividade suspeita foi detectada, quais escopos estavam envolvidos, quais clientes precisavam de ação, qual acesso a repositórios foi confirmado ou descartado, quais segredos podem ter sido expostos, quando as credenciais foram rotacionadas e o que mudou para que o mesmo caminho de custódia de token não pudesse se repetir silenciosamente.

Consentimento OAuth se torna custódia após o primeiro clique

O primeiro erro operacional em muitas análises de OAuth é tratar o consentimento como uma decisão única do usuário. Em uma plataforma para desenvolvedores, o consentimento se torna custódia. Uma vez que um usuário autoriza um aplicativo a acessar um repositório, a plataforma, provedor de identidade, host de código-fonte e administrador do cliente herdam obrigações contínuas. O token tem um ciclo de vida. É emitido, armazenado, atualizado, usado, registrado, escopado, revogado, substituído e eventualmente esquecido ou aposentado.

O incidente da Heroku é importante porque o registro público forçou os clientes a pensar sobre esse ciclo de vida após a decisão de confiança já estar incorporada nos fluxos de trabalho de desenvolvimento.

A documentação atual do OAuth do GitHub emhttps://docs.github.com/en/apps/oauth-appse o guia de manutenção de aplicativos OAuth emhttps://docs.github.com/en/apps/oauth-apps/maintaining-oauth-appssão úteis porque mostram o vocabulário de controle em torno de aplicativos OAuth, segredos de cliente, URLs de callback, propriedade e gerenciamento de aplicativos. O guia de log de auditoria empresarial do GitHub emhttps://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-enterprisemostra por que as organizações precisam de evidências de atividade após um evento de integração suspeito. A documentação de integração com GitHub da Heroku emhttps://devcenter.heroku.com/articles/github-integrationmostra a superfície de recurso visível ao cliente. Nenhum desses documentos prova exatamente o que aconteceu em 2022. Eles estabelecem a superfície operacional que os clientes tiveram que proteger.

Custódia significa que a plataforma deve responder a um conjunto diferente de perguntas do que tempo de atividade comum. Onde os tokens OAuth estavam armazenados? Refresh tokens ou access tokens estavam envolvidos? Eles estavam criptografados, segmentados ou isolados por locatário? Qual serviço ou banco de dados podia lê-los? Que monitoramento mostraria uso incomum? Quem podia revogá-los? Que ação do cliente era necessária após a revogação? A Heroku podia implantar a partir do GitHub sem o consentimento renovado do cliente?

Segredos de tempo de build, variáveis de configuração, conteúdos de repositório ou chaves de implantação estavam em risco? Quais dessas respostas eram conhecidas no primeiro aviso e quais ainda estavam sob investigação?

Essas perguntas não são hostis. Elas são a base da confiança. Uma plataforma para desenvolvedores pode ter uma razão válida para armazenar tokens, mas a razão deve ser acompanhada de evidências de proteção. Uma plataforma pode revogar tokens rapidamente, mas a evidência de revogação deve ser acompanhada de instruções ao cliente. Uma plataforma pode exigir rotação de senhas de usuário da Heroku ou chaves de API, mas os clientes precisam saber por que essa rotação é necessária e se a inspeção de repositório também é necessária.

Uma plataforma pode dizer que nenhuma ação do cliente é necessária para um subconjunto de usuários, mas essa declaração deve estar ligada a um limite técnico.

O registro público da Heroku incluiu instruções ao cliente em evolução. Essa evolução não é automaticamente uma falha. A resposta a incidentes frequentemente passa de suspeita para confirmação em estágios. A questão de responsabilidade é se os estágios são visíveis o suficiente para que os clientes possam acompanhar sem adivinhar. Se a primeira mensagem de um cliente diz uma coisa e uma mensagem posterior exige ação mais ampla, a plataforma deve explicar quais evidências mudaram.

Se um cliente é instruído a rotacionar credenciais, a instrução deve especificar quais credenciais, qual prazo, quais contextos de aplicação e quais logs o cliente deve revisar.

A dimensão econômica é real. Equipes de desenvolvimento otimizam para integração rápida porque implantação manual e gerenciamento de credenciais são caros. Aplicativos OAuth reduzem o atrito. Mas quando o caminho de custódia do lado do provedor falha, o custo da conveniência reaparece como trabalho de emergência: revisar repositórios, rotacionar segredos, reconstruir integrações, pesquisar logs, explicar exposição a clientes e responder a auditores. A economia de ferramentas para desenvolvedores pertence, portanto, à lista de tópicos do artigo.

A plataforma que se beneficia da integração fácil tem que investir em custódia, revogação e evidências.

Acesso ao código-fonte não é o mesmo que comprometimento de produção, mas não é inofensivo

O registro público tem que resistir a duas simplificações ruins. A primeira é dizer que tokens OAuth roubados automaticamente significam que aplicações de produção foram comprometidas. A segunda é dizer que o acesso ao código-fonte é inofensivo se nenhuma interrupção de produção ocorreu. Ambas as afirmações são fracas. O código-fonte pode conter lógica de aplicação, informações de dependência, endpoints internos, scripts de implantação, padrões de configuração, fixtures de teste, comentários, segredos antigos, nomes de infraestrutura e suposições de segurança.

Ao mesmo tempo, apenas o acesso ao código-fonte não prova acesso em tempo de execução, roubo de dados ou manipulação de implantação.

O alerta do GitHub e as comunicações do incidente da Heroku são importantes porque colocam o risco de acesso ao código-fonte no arquivo público. Um cliente com repositórios conectados precisava saber se um invasor podia ler repositórios privados, se os repositórios tinham segredos commitados, se credenciais de implantação existiam fora do GitHub, se GitHub Actions, pipelines da Heroku, review apps ou trabalhos de CI expunham materiais adicionais, e se os logs de auditoria em nível de repositório mostravam acesso incomum. Se o cliente usava Travis CI, as mesmas perguntas podiam se estender a variáveis de ambiente de CI e logs de build.

O NIST SP 800-218 emhttps://csrc.nist.gov/pubs/sp/800/218/finalé útil porque trata o desenvolvimento seguro de software como um ciclo de vida, não apenas escrita de código. O NIST SP 800-204D emhttps://csrc.nist.gov/pubs/sp/800/204/d/finalajuda a enquadrar questões de segurança de aplicações nativas da nuvem e identidade de serviço. O NIST SP 800-53 Rev. 5 emhttps://csrc.nist.gov/pubs/sp/800/53/r5/upd1/finalfornece vocabulário de controle para controle de acesso, auditoria, configuração, resposta a incidentes e integridade do sistema. Esses materiais não são descobertas específicas da Heroku. São referências para decidir se um incidente de plataforma para desenvolvedores deve ser revisado como um evento de cadeia de suprimentos de software.

A fronteira chave é a prova. Se uma plataforma pode determinar que um token OAuth foi usado apenas para um determinado repositório ou conjunto de clientes, ela deve explicar a base dessa determinação. Se não pode determinar acesso cliente por cliente devido a limites de logging, deve dizer isso. Se o GitHub pode notificar usuários afetados com base no uso do token ou acesso a repositórios, o registro público deve identificar o que a notificação significa e o que não significa. Se os clientes precisam inspecionar seus próprios logs, o provedor deve declarar quais fontes de log são relevantes.

O risco público também difere por maturidade do cliente. Uma grande empresa pode ter logs de auditoria empresarial do GitHub, varredura centralizada de segredos, análise de composição de software, segregação de CI/CD e equipe de resposta a incidentes. Um cliente menor da Heroku pode ter uma conexão simples com o GitHub, um ou dois mantenedores e retenção limitada de logs. O mesmo evento de token, portanto, cria diferentes cargas. Um registro de responsabilidade maduro não assume que todo cliente pode preencher independentemente as lacunas de evidência do provedor.

Ele dá a equipes pequenas passos práticos e a equipes grandes detalhes técnicos suficientes para automatizar a revisão.

O público downstream é mais amplo do que os proprietários de conta da Heroku. Se o acesso ao código-fonte revela vulnerabilidades ou segredos, usuários downstream do software do cliente podem ser afetados posteriormente, mesmo que o incidente original da plataforma não tenha causado tempo de inatividade imediato. Isso não significa que todo usuário downstream foi prejudicado. Significa que a análise de responsabilidade tem que traçar o caminho do risco: roubo de token, possível acesso a repositório, possível exposição de fonte ou segredo, possível uso indevido de CI/CD, possível acesso à produção e possível dano downstream.

Cada passo precisa de evidência antes de se tornar uma alegação.

O timing da notificação faz parte da superfície de controle

A comunicação de incidentes é frequentemente tratada como uma função legal ou de relações públicas, mas para plataformas para desenvolvedores é controle operacional. Os clientes não podem revogar tokens, rotacionar segredos, reconstruir integrações ou inspecionar repositórios até que saibam o que fazer. Um aviso atrasado, vago ou mutável pode estender o período em que os clientes estão expostos ou inseguros. Um aviso rápido mas incompleto pode criar trabalho desnecessário. O padrão de responsabilidade não é, portanto, simplesmente velocidade. É utilidade de decisão em cada estágio.

A página de incidentes da Heroku emhttps://status.heroku.com/incidents/2413é útil porque as atualizações de status mostram uma sequência em vez de uma única declaração final. O alerta de segurança do GitHub fornece outra linha do tempo. O boletim da Travis CI fornece uma terceira. Um leitor atento não deve colapsar essas linhas do tempo em uma única cronologia perfeita, a menos que as fontes apoiem isso. A questão útil é como o aviso de cada ator mudou a ação do cliente. Os clientes precisavam revogar a autorização do aplicativo? Precisavam rotacionar chaves de API da Heroku? Precisavam rotacionar senhas de usuário da Heroku? Precisavam inspecionar repositórios do GitHub? Precisavam verificar variáveis de ambiente de CI? Precisavam reconstruir hooks de implantação?

A resposta pode ter mudado à medida que os fatos surgiram. Isso é aceitável quando as mudanças são explicadas. Um aviso pode dizer "estamos investigando possível acesso e forneceremos instruções adicionais". Pode dizer "revogamos tokens e os clientes devem reautorizar". Pode dizer "exigimos redefinição de senha porque não podemos descartar acesso a credenciais hash". Pode dizer "não encontramos evidências para uma categoria, mas os clientes devem inspecionar seus próprios logs para estes indicadores". O que enfraquece a responsabilidade não é a incerteza. O que enfraquece a responsabilidade é a incerteza apresentada como conclusão.

A notificação ao cliente também tem um dever de segmentação. Nem todo cliente da Heroku usava integração com GitHub. Nem todo usuário do GitHub autorizou a Heroku. Nem todo usuário da Travis CI tinha o mesmo escopo. Nem todo repositório continha material sensível. Um aviso útil distingue grupos afetados, potencialmente afetados, não afetados e desconhecidos. Se a segmentação exata não for possível, o provedor deve explicar por quê. Os clientes não devem ter que inferir se uma mensagem se aplica a eles a partir de manchetes amplas.

A qualidade da comunicação pode ser medida. O provedor publicou páginas de incidentes duráveis? As mensagens incluíam datas e timestamps? Elas identificavam serviços afetados? Forneciam ações concretas para o cliente? Atualizavam orientações anteriores quando mudavam? Mantinham registros diretos ao cliente e públicos consistentes? Publicavam uma revisão pós-incidente que nomeava melhorias de controle sem divulgar detalhes privados exploráveis? Essas são questões de responsabilidade tanto quanto questões de comunicação.

Na economia de ferramentas para desenvolvedores, comunicação pouco clara transfere custo para os clientes. Cada frase vaga se torna uma reunião, um ticket, uma busca em logs, um email de cliente ou uma exceção de auditoria downstream. Uma plataforma pode ser legalmente cautelosa, mas uma plataforma que vende confiança de desenvolvedores deve tratar o aviso útil para decisão como parte do produto. O incidente da Heroku mostra por que as comunicações de incidentes precisam de disciplina de engenharia de produto: instruções versionadas, públicos segmentados, correções rastreáveis e evidências de conclusão.

Rotação forçada é um remédio apenas se os clientes souberem o que mudou

A rotação forçada de credenciais pode ser necessária e ainda assim incompleta como reparo de confiança. Um cliente pode rotacionar uma chave de API, redefinir uma senha ou reautorizar um aplicativo OAuth, mas o cliente também precisa entender o que mudou no modelo de custódia da plataforma. Se o mesmo caminho de armazenamento, design de escopo, lacuna de monitoramento ou lacuna de evidência do cliente permanecer, a rotação pode restaurar o acesso sem restaurar a confiança. O registro público em torno do incidente de 2022 da Heroku colocou rotação e reautorização no centro da ação do cliente.

A questão de responsabilidade é se essas ações foram acompanhadas por evidências de controle duráveis.

Páginas do Dev Center da Heroku comohttps://devcenter.heroku.com/articles/oauth,https://devcenter.heroku.com/articles/platform-api-reference,https://devcenter.heroku.com/articles/heroku-cliehttps://devcenter.heroku.com/articles/account-securitymostram o ambiente mais amplo de gerenciamento de acesso em torno do uso da plataforma Heroku. A página de autenticação de dois fatores da Heroku emhttps://devcenter.heroku.com/articles/heroku-2fafornece contexto de endurecimento de conta do lado do cliente. Novamente, a documentação atual não é prova do estado interno de 2022. Ajuda os leitores a entender os tipos de credenciais e ações do usuário que podem existir em torno de uma conta Heroku.

A rotação tem três camadas distintas. Primeiro, há a revogação de tokens OAuth comprometidos para que o invasor não possa continuar usando a autorização delegada. Segundo, há a substituição ou reautorização do lado do cliente para que fluxos de trabalho legítimos possam continuar com novos tokens. Terceiro, há a revisão de credenciais adjacentes, incluindo chaves de API, senhas, chaves de implantação, variáveis de CI, segredos de repositório, tokens de acesso pessoal e credenciais de nuvem. Um aviso da plataforma deve deixar claro qual camada é necessária e por quê.

A camada mais difícil é a exposição de segredos no código-fonte. Se um invasor podia ler repositórios, rotacionar apenas o token OAuth pode não ser suficiente. Os clientes podem precisar pesquisar repositórios em busca de segredos commitados e rotacionar qualquer valor exposto. A documentação de varredura de segredos do GitHub emhttps://docs.github.com/en/code-security/secret-scanning/about-secret-scanningfornece vocabulário atual para essa revisão do lado do cliente. A orientação de cadeia de suprimentos de software da CISA emhttps://www.cisa.gov/resources-tools/resources/software-supply-chain-risk-management-sscrme materiais de design seguro por padrão ajudam a explicar por que segredos no código podem transformar um evento de repositório em risco operacional mais amplo.

A rotação forçada também precisa de um sinal de conclusão. Os clientes devem saber se tokens antigos são inválidos, se reautorização é necessária, se integrações desabilitadas permanecerão desabilitadas até ação, se a conclusão da redefinição de senha é rastreada e se credenciais obsoletas ainda são aceitas em algum lugar. Sem um sinal de conclusão, cada cliente tem que fazer sua própria reconciliação. Isso é caro e propenso a erros.

A plataforma também precisa de evidências internas de conclusão. Quais contas de clientes concluíram as etapas necessárias? Quais contas permanecem em estado de exceção? Quais clientes estavam inalcançáveis? Quais integrações foram abandonadas? Quais tokens não puderam ser mapeados para um proprietário atual? Quais controles foram adicionados para evitar retenção silenciosa de token de longa duração? Uma autópsia pública pode não divulgar nomes de clientes, mas pode divulgar a forma da limpeza. Essa é a diferença entre "rotacionamos" e "o estado arriscado não existe mais".

GitHub, Heroku, Travis CI, Salesforce e clientes possuíam cada um evidências diferentes

O mapa de responsabilidade do incidente é multipartes. O GitHub possuía evidências de host de código-fonte, visibilidade de aplicativos OAuth e o alerta de segurança que publicou. A Heroku possuía sua integração de plataforma, comunicação com o cliente, custódia de tokens e programa de credenciais forçadas. A Travis CI possuía sua faixa de integração CI/CD afetada e orientação ao cliente. A Salesforce possuía governança da Heroku, alocação de recursos, escalação de risco e o dever de tornar crível o reparo da plataforma.

Os clientes possuíam higiene de repositório, rotação de segredos, aprovações organizacionais de OAuth e revisão de implantação. Nenhum desses papéis cancela os outros.

Isso é importante porque o dano ao cliente pode resultar de lacunas entre papéis. Se o GitHub sabe que um token foi usado, mas um cliente não sabe qual aplicativo Heroku estava mapeado para ele, a resposta do cliente é mais lenta. Se a Heroku sabe quais contas usaram integração com GitHub, mas não pode dizer se os conteúdos do repositório foram acessados, os clientes devem revisar mais amplamente. Se Travis CI e Heroku compartilham um alerta do GitHub, mas têm instruções diferentes para o cliente, organizações que usam ambos têm que reconciliar ações conflitantes ou sobrepostas.

Se a Salesforce trata a Heroku como uma marca subsidiária enquanto os clientes tratam a Heroku como uma plataforma de produção, a governança tem que preencher a fronteira da marca.

Documentos de responsabilidade compartilhada de nuvem e SaaS frequentemente dizem que as obrigações do provedor e do cliente diferem. O incidente da Heroku mostra que responsabilidade compartilhada também requer evidências compartilhadas. Um cliente não pode aceitar responsavelmente a garantia de um provedor se o provedor não divulga qual parte da cadeia a garantia cobre. Um provedor não pode transferir responsavelmente toda ação para os clientes se os clientes não têm os logs ou recursos de produto necessários para agir. Um host de código-fonte não pode assumir que ferramentas downstream traduzirão seu alerta perfeitamente.

Cada ator tem que tornar suas evidências úteis para o próximo ator na cadeia.

As fontes IETF, NIST, MITRE, CISA, GitHub, Heroku e Travis CI juntas formam um arquivo público limitado. Elas não revelam todos os fatos privados, mas permitem um modelo claro de responsabilidade. Tokens OAuth devem ser escopados estreitamente, armazenados defensavelmente, revogáveis rapidamente, monitorados continuamente e mapeados para propósito de negócio atual. Plataformas para desenvolvedores devem comunicar incidentes com especificidade suficiente para permitir que os clientes ajam. Os clientes devem revisar integrações periodicamente em vez de tratar autorização como permanente.

Hosts de código-fonte devem disponibilizar evidências de auditoria o suficiente para que os clientes possam distinguir exposição possível de acesso confirmado.

O mapa de papéis também alerta contra culpabilização simplista. Se um invasor rouba um token, o invasor é responsável pelo uso indevido. Mas a responsabilidade pergunta quem poderia reduzir a oportunidade, o raio de explosão e a incerteza. O design de armazenamento de token pode reduzir a oportunidade. A minimização de escopo pode reduzir o raio de explosão. A revogação rápida pode reduzir a duração. Bons logs podem reduzir a incerteza. Instruções claras ao cliente podem reduzir trabalho desperdiçado. Evidências de controle pós-incidente podem reduzir recorrência. Essas são escolhas de design, não apenas declarações posteriores.

Evidências verificáveis pelo cliente são a metade ausente da responsabilidade compartilhada

O incidente da Heroku também mostra o limite da linguagem de responsabilidade compartilhada quando as evidências são assimétricas. Uma plataforma pode dizer aos clientes que eles são responsáveis pela higiene de repositório, rotação de segredos e revisão de aplicativos OAuth, mas o cliente ainda depende de evidências do provedor para decidir onde procurar. Se o provedor não pode dizer se um token tinha escopo de leitura de repositório, se foi usado após uma certa data, se estava vinculado a um aplicativo específico ou se logs específicos do cliente existem, então a responsabilidade do cliente se torna um exercício de adivinhação.

Um modelo justo de responsabilidade compartilhada dá aos clientes tanto deveres quanto evidências utilizáveis.

Evidências verificáveis pelo cliente começam com um inventário. Cada cliente deve poder ver quais aplicativos Heroku estavam conectados a quais organizações do GitHub, repositórios, usuários e fluxos de implantação. O inventário deve mostrar status atual, última autorização, escopo, proprietário, requisito de reautorização e se a conexão foi desabilitada pelo provedor. Sem esse mapa, uma equipe de segurança deve reconstruir a integração a partir de tickets antigos, webhooks de repositório, histórico de implantação e contas pessoais de desenvolvedores.

Esse é exatamente o tipo de trabalho de emergência que uma plataforma deve reduzir após um evento de token do lado do provedor.

A segunda camada de evidência é a atividade. Os clientes precisam saber quais logs podem mostrar acesso a repositórios, uso de autorização OAuth, uso de chave de API, atividade de conta Heroku, eventos de implantação, eventos de build e alterações de configuração. Se a evidência relevante existe apenas no GitHub, o provedor deve direcionar os clientes para os registros de auditoria do GitHub. Se a evidência relevante existe apenas na Heroku, o provedor deve expor uma visão específica do cliente ou caminho de suporte.

Se algumas evidências estão indisponíveis porque o logging não foi retido ou não foi coletado, o provedor deve dizer isso claramente. "Nenhuma evidência de uso indevido" é útil para a decisão apenas quando os clientes sabem quais evidências foram revisadas.

A terceira camada é a exposição de segredos. O risco de acesso a repositórios não se limita ao código-fonte como propriedade intelectual. Inclui também segredos commitados, configuração histórica, credenciais de teste, tokens de implantação, chaves de nuvem, strings de conexão de banco de dados e comentários que revelam arquitetura. Os clientes precisam de orientação que ligue o incidente de token à varredura e rotação de segredos. Uma resposta forte da plataforma diria quais categorias são prováveis, quais são possíveis e quais estão fora do caminho conhecido.

Também evitaria implicar que apenas a revogação de token fecha o risco de conteúdo do repositório.

A quarta camada é a garantia de lançamento de software. Se um cliente usa a Heroku para implantações automáticas a partir do GitHub, o cliente precisa saber se o acesso não autorizado ao repositório poderia ter influenciado código implantado, artefatos de build, review apps, pipelines ou histórico de lançamentos. Isso não significa que tal influência ocorreu. Significa que o cliente deve receber informações suficientes para provar ou refutar. Histórico de lançamentos, proveniência de build, timestamps de implantação, assinaturas de commit de repositório, proteções de branch e logs de CI todos se tornam parte do arquivo de responsabilidade.

A quinta camada é a limpeza durável. Um cliente deve poder dizer quando o estado suspeito terminou. Os tokens OAuth antigos foram revogados? As integrações foram reautorizadas com novos tokens? Rotações de senha ou chave de API foram concluídas? Aplicativos abandonados foram desabilitados? Autorizações pessoais órfãs foram removidas? A plataforma impediu que a classe de token antigo permanecesse ativa em qualquer trabalho em segundo plano ou caminho legado? A garantia do provedor é mais forte quando os clientes podem reconciliar seu próprio estado de locatário contra evidências de conclusão do provedor.

Esse modelo de evidência do cliente não exige que um provedor publique logs privados sensíveis na web aberta. Pode ser entregue por meio de painéis de conta, avisos diretos, exportações de suporte, briefings de incidentes empresariais ou pacotes de evidências contratuais. A forma pode variar por nível de cliente e sensibilidade. O princípio não deve variar: quando um provedor pede que os clientes ajam, deve também fornecer as evidências de que os clientes precisam para agir proporcionalmente.

Aquisição e governança devem tratar integrações como acesso permanente

A lição de aquisição é que integrações OAuth são acesso permanente, não tarefas de configuração única. Um questionário de risco de fornecedor que pergunta apenas se o provedor suporta criptografia, autenticação multifator ou metas de tempo de atividade perderá a lição da Heroku. As perguntas mais precisas são sobre inventário de integração, armazenamento de token, minimização de escopo, logs de cliente, revogação de emergência, notificações em nível de locatário, isolamento de sistema de build e prova pós-incidente.

Plataformas para desenvolvedores devem esperar essas perguntas porque seus produtos intencionalmente se posicionam próximos à entrega de software.

A linguagem contratual também deve evitar transferências vagas de responsabilidade. Um provedor pode exigir que os clientes protejam seus repositórios e credenciais, mas deve declarar como os incidentes de integração do lado do provedor serão tratados. O provedor notificará todo cliente que usa a integração afetada? Fornecerá janelas de tempo afetadas? Identificará se o acesso ao código-fonte é confirmado, possível ou não observado? Exigirá reautorização? Exporá eventos de auditoria? Fornecerá um resumo pós-incidente? Apoiará clientes regulamentados que precisam de suas próprias notificações?

Esses não são termos de luxo para grandes empresas. São perguntas operacionais básicas para qualquer cliente cuja cadeia de suprimentos de software depende da plataforma.

A governança dentro da Salesforce e da Heroku também importa. O público não deve assumir que uma marca subsidiária carrega menos responsabilidade porque é focada em desenvolvedores. As aplicações da Heroku podem ser aplicações de produção, ferramentas internas, APIs públicas, protótipos que se tornaram críticos ou sistemas de back-office que lidam com fluxos de trabalho sensíveis. A estrutura de propriedade importa porque a governança determina investimento em logging, custódia de tokens, resposta a incidentes, suporte ao cliente e engenharia de segurança.

Uma empresa-mãe não precisa divulgar toda discussão do conselho para mostrar que um incidente de plataforma para desenvolvedores recebeu atenção séria de controle.

A mesma questão de governança se aplica ao gerenciamento de produto. Uma equipe de produto pode querer integração perfeita com GitHub porque reduz atrito e ajuda os clientes a implantar rapidamente. Uma equipe de segurança pode querer tokens de curta duração, escopos estreitos, logs visíveis ao cliente e reautorização periódica. Uma equipe de suporte pode querer mensagens simples o suficiente para pequenos clientes. Uma equipe de vendas empresariais pode querer evidências contratuais. A responsabilidade aparece onde esses incentivos são reconciliados antes de um incidente, não apenas depois.

Se a plataforma não pode explicar quem possui o risco de custódia de token em operações normais, ela lutará para explicar quem o possui durante uma crise.

Para os clientes, a resposta prática de governança é classificar as integrações por consequência. Uma integração de produtividade pessoal é diferente de uma integração de implantação que pode ler código-fonte de produção. Um aplicativo de repositório somente leitura é diferente de um aplicativo que pode criar implantações ou gerenciar webhooks. Um aplicativo de trial da Heroku é diferente de uma aplicação de produção voltada ao cliente. As organizações devem atribuir revisão, logging e recertificação mais fortes a integrações que podem afetar código de produção ou segredos.

O incidente da Heroku é um lembrete de que "aplicativo conectado" é um objeto de governança, não apenas um recurso de conveniência.

O resultado é um padrão de responsabilidade mais maduro. Plataformas para desenvolvedores devem publicar evidências de incidentes suficientes para que os clientes possam completar suas próprias decisões de risco. Os clientes devem manter inventário de integração suficiente para que as evidências do provedor possam ser usadas rapidamente. Hosts de código-fonte devem manter controles de OAuth e auditoria utilizáveis. Fornecedores de CI/CD devem separar segredos de build de confiança ampla de repositório. Empresas-mãe devem tratar a confiança do desenvolvedor como confiança de produção.

O incidente da Heroku de 2022 se torna mais do que um alerta de segurança histórico quando lido dessa forma. Torna-se um teste de se a cadeia de entrega de software pode identificar acesso permanente antes que invasores forcem todos a olhar.

Como deve ser um reparo durável após um incidente de custódia OAuth

O padrão de reparo durável para um incidente OAuth de plataforma para desenvolvedores tem pelo menos oito partes. Primeiro, o provedor deve publicar uma linha do tempo clara: detecção, notificação do GitHub, investigação da Heroku, notificação ao cliente, revogação de tokens, rotação de credenciais, disponibilidade de reautorização e autópsia. Segundo, deve identificar a superfície de integração afetada sem implicar que todo cliente ou repositório foi igualmente afetado. Terceiro, deve explicar a diferença entre tokens OAuth roubados, senhas de clientes, chaves de API, chaves de implantação, segredos de repositório e variáveis de CI.

Quarto, o provedor deve publicar ações do cliente em uma lista de verificação que distingue passos obrigatórios, recomendados e condicionais. Quinto, deve declarar quais evidências o cliente pode ver e quais evidências apenas o provedor ou host de código-fonte pode ver. Sexto, deve identificar quais controles mudaram: armazenamento de token, criptografia, gerenciamento de segredos, revisão de escopo, monitoramento, detecção de anomalias, acesso de auditoria do cliente ou descontinuação de integração.

Sétimo, deve fornecer um sinal de conclusão, como conclusão de redefinição forçada, conclusão de revogação de token ou imposição de reautorização. Oitavo, deve declarar claramente as incógnitas residuais.

O arquivo público da Heroku contém evidências significativas, mas a lição de responsabilidade é mais ampla que um incidente. Plataformas para desenvolvedores devem projetar para dias de token suspeito antes que eles aconteçam. Isso significa inventário de aplicativos OAuth, mapeamento de proprietário, minimização de escopo, rastreamento de idade de token, fluxos de trabalho automatizados de revogação, modelos de notificação ao cliente, páginas de ação específicas do cliente, exportação de log de auditoria e recertificação periódica de integração. Também significa testar a experiência do cliente de uma reautorização forçada antes de uma crise.

Se os clientes não conseguem entender o caminho de reparo em um dia calmo, não entenderão durante um incidente.

Os clientes também precisam de hábitos duráveis. Devem inventariar aplicativos OAuth, remover integrações não utilizadas, restringir aprovação em toda a organização, exigir revisão para aplicativos de alto escopo, usar varredura de segredos, evitar commit de credenciais, rotacionar segredos de longa duração, preservar logs de auditoria e mapear fluxos de implantação. A documentação do GitHub e da Heroku fornece muitos dos blocos de construção, mas o trabalho de governança pertence a cada organização.

Um incidente de fornecedor se torna mais gerenciável quando os clientes já sabem quais aplicativos estão conectados a quais repositórios e sistemas de produção.

O teste final de responsabilidade não é se a plataforma pode dizer que o incidente está encerrado. É se o encerramento pode ser rastreado até evidências. Os tokens suspeitos foram invalidados? Os clientes impactados foram notificados? As redefinições necessárias foram concluídas? As questões de acesso ao código-fonte foram respondidas no nível que as evidências permitiam? Segredos e credenciais de implantação foram revisados? Os controles do produto foram alterados? As incógnitas residuais foram preservadas? Um "sim" a essas perguntas é mais forte do que uma declaração geral de confiança porque diz aos clientes o que mudou.

O incidente OAuth de 2022 da Heroku pertence, portanto, à série de risco e responsabilidade de Daniel Kade porque torna a confiança do desenvolvedor visível. O incidente transforma um botão de integração familiar em uma questão de custódia. Mostra que plataformas de código-fonte, plataformas de implantação, fornecedores de CI/CD e clientes estão conectados por autoridade delegada que sobrevive ao clique do usuário.

Quando essa autoridade é roubada, a responsabilidade segue o token: quem o emitiu, quem o armazenou, quem podia vê-lo, quem o revogou, quem avisou os usuários, quem provou o reparo e quem pagou o custo enquanto a prova ainda estava incompleta.