Salesforce fez da custódia de token OAuth do Heroku um teste de responsabilidade de plataforma de desenvolvedor

Resumo

• O incidente de integração GitHub do Heroku em 2022 importa porque os 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, aplicativos de clientes e usuários de software downstream.
• O GitHub alertou publicamente que um invasor usou tokens de usuário OAuth roubados emitidos para o Heroku e o Travis CI, enquanto as comunicações de incidente do Heroku exigiam que os clientes seguissem orientações rotativas à medida que a investigação, revogação e redefinições de credenciais evoluíam.
• A questão de responsabilidade não é apenas se o Heroku eventualmente rotacionou chaves ou restaurou integrações. É quem controlava a custódia do token, notificação ao cliente, comportamento do aplicativo GitHub, evidências de acesso ao código-fonte, limites de confiança CI/CD e prova pós-incidente.
• Este artigo trata as fontes 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 de desenvolvedor tem que carregar um livro 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 fez da custódia de token OAuth do Heroku um teste de responsabilidade de plataforma de desenvolvedor porque o Heroku é uma plataforma de desenvolvedor gerenciada cujo valor se baseia na confiança no limite entre código, implantação, identidade e operações. Os clientes usam o Heroku para conectar aplicativos 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 volta para o risco operacional do cliente.

O gatilho público de 2022 tornou-se visível porque o GitHub publicou um alerta de segurança em source: github.blog descrevendo tokens de usuário OAuth roubados emitidos para o Heroku e o Travis CI. A própria página de incidente de status do Heroku em source: status.heroku.com e a revisão pública do incidente de abril de 2022 do Heroku em source: blog.heroku.com enquadram o assunto do lado da plataforma. O boletim de segurança do Travis CI em source: travis-ci.com 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 importa porque o OAuth muda a forma da responsabilidade. Uma senha roubada pode frequentemente 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 um usuário pensou pela última vez 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 OAuth 2.0 do IETF em source: datatracker.ietf.org e o registro de melhores práticas atuais de segurança OAuth em source: datatracker.ietf.org não são relatórios de incidente sobre o Heroku, mas ajudam a definir por que a emissão de tokens, escopo, armazenamento, rotação, revogação, resistência a replay e confiança do cliente importam.

O arquivo de responsabilidade não deve achatar Heroku, Salesforce, GitHub, Travis CI e clientes em um único ator. A Salesforce era proprietária do Heroku como negócio e marca. O 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 podia publicar. O GitHub controlava sua própria investigação, revogação de tokens, evidências de host de origem, controles de aplicativo OAuth e alerta de segurança voltado ao cliente. O Travis CI controlava seu canal de integração afetado e mensagens ao cliente.

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 a instruções. Os usuários de software downstream 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 as plataformas de desenvolvedor criam responsabilidade compartilhada sem sempre dar evidência compartilhada. Os clientes do 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 do Heroku ou ação do invasor do lado do GitHub. Os usuários do GitHub podiam revogar um aplicativo OAuth, mas podiam não saber qual pipeline de implantação, aplicativo ou equipe do 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 todos públicos. A questão de responsabilidade é, portanto, alocação de evidência: o que cada ator sabia, o que cada ator podia provar e o que os clientes tinham que fazer enquanto a incerteza permanecia.

O registro público também mostra por que incidentes de ferramentas de desenvolvedor pertencem à responsabilidade da cadeia de suprimentos de software, não apenas à responsabilidade de segurança de conta. O acesso ao código-fonte está a montante da segurança de aplicativos, segredos, trabalhos CI/CD, artefatos de build, credenciais de implantação e versões de produtos. A técnica de token de acesso a aplicativo do MITRE ATT&CK em source: attack.mitre.org e a técnica de material de autenticação alternativo em source: attack.mitre.org são vocabulário útil porque distinguem o uso indevido de tokens da adivinhação comum de credenciais.

Os materiais de design seguro por design do CISA em source: cisa.gov e o Estrutura de Desenvolvimento de Software Seguro do NIST em source: csrc.nist.gov ajudam a explicar por que a custódia do código-fonte e a confiança no sistema de build têm que ser tratadas como controles de produção.

Este artigo não afirma ter acesso a logs privados do Heroku, dados de auditoria de repositório privado do GitHub, registros internos do Travis CI, avisos cliente por cliente, comunicações de aplicação da lei ou materiais do conselho da Salesforce. Usa o arquivo público para perguntar se a evidência tornou 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.

O consentimento OAuth torna-se custódia após o primeiro clique

O primeiro erro operacional em muitas revisões de OAuth é tratar o consentimento como uma decisão única do usuário. Em uma plataforma de desenvolvedor, o consentimento torna-se custódia. Uma vez que um usuário autoriza um aplicativo a acessar um repositório, a plataforma, o provedor de identidade, o host de código-fonte e o 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 do Heroku importa porque o registro público forçou os clientes a pensar sobre esse ciclo de vida depois que a decisão de confiança já havia sido incorporada nos fluxos de trabalho de desenvolvimento.

A documentação atual do OAuth do GitHub em source: docs.github.com e a orientação de manutenção de aplicativos OAuth em source: docs.github.com são úteis porque mostram o vocabulário de controle em torno de aplicativos OAuth, segredos de cliente, URLs de retorno, propriedade e gerenciamento de aplicativos. A orientação de log de auditoria empresarial do GitHub em source: docs.github.com mostra por que as organizações precisam de evidências de atividades após um evento de integração suspeito. A documentação de integração GitHub do Heroku em source: devcenter.heroku.com mostra 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 da disponibilidade comum. Onde os tokens OAuth foram armazenados? Tokens de atualização ou tokens de acesso estavam envolvidos? Eles foram criptografados, segmentados ou isolados por inquilino? Qual serviço ou banco de dados podia lê-los? Qual monitoramento mostraria uso incomum? Quem podia revogá-los? Qual ação do cliente era necessária após a revogação? O Heroku podia implantar 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. São a base da confiança. Uma plataforma de desenvolvedor pode ter uma razão válida para armazenar tokens, mas a razão tem que ser emparelhada com evidência de proteção. Uma plataforma pode revogar tokens rapidamente, mas a evidência de revogação tem que ser emparelhada com instruções ao cliente. Uma plataforma pode exigir a rotação de senhas de usuário do 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 vinculada a um limite técnico.

O registro público do Heroku incluiu instruções ao cliente em evolução. Essa evolução não é automaticamente uma falha. A resposta a incidentes frequentemente se move de suspeita para confirmação por meio de 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 requer ação mais ampla, a plataforma deve explicar qual evidência mudou.

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

A dimensão econômica é real. Equipes de desenvolvedores 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: revisão de repositórios, rotação de segredos, reconstrução de integrações, busca em logs, explicação de exposição a clientes e resposta a auditores. A economia de ferramentas de desenvolvedor 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ência.

O 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 significam automaticamente que aplicativos de produção foram comprometidos. 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 aplicativo, 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 de incidente do 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 comprometidos, se credenciais de implantação existiam fora do GitHub, se GitHub Actions, pipelines do Heroku, aplicativos de revisão ou trabalhos CI expunham materiais adicionais e se logs de auditoria de 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 CI e logs de build.

O NIST SP 800-218 em source: csrc.nist.gov é ú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 em source: csrc.nist.gov ajuda a enquadrar questões de segurança de aplicativos nativos da nuvem e identidade de serviço. O NIST SP 800-53 Rev. 5 em source: csrc.nist.gov dá vocabulário de controle para controle de acesso, auditoria, configuração, resposta a incidentes e integridade do sistema. Esses materiais não são conclusões específicas do Heroku.

São referências para decidir se um incidente de plataforma de desenvolvedor deve ser revisado como um evento de cadeia de suprimentos de software.

O limite principal é a prova. Se uma plataforma pode determinar que um token OAuth foi usado apenas para um certo repositório ou conjunto de clientes, deve explicar a base dessa determinação. Se não pode determinar acesso cliente por cliente devido a limites de registro, deve dizer isso. Se o GitHub pode notificar usuários afetados com base no uso do token ou acesso a repositório, 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 importam.

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 CI/CD e pessoal de resposta a incidentes. Um cliente menor do 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 cria, portanto, diferentes encargos. Um registro de responsabilidade maduro não assume que todo cliente pode preencher independentemente as lacunas de evidência do provedor.

Dá passos práticos para equipes pequenas e detalhes técnicos suficientes para que equipes grandes automatizem a revisão.

O público downstream é mais amplo que os proprietários de conta do 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 rastrear o caminho de 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 de 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 é 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 de desenvolvedor é controle operacional. Os clientes não podem revogar tokens, rotacionar segredos, reconstruir integrações ou inspecionar repositórios até saberem o que fazer. Um aviso tardio, 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 incidente do Heroku em source: status.heroku.com é ú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 do Travis CI fornece uma terceira. Um leitor cuidadoso não deve colapsar essas linhas do tempo em uma única cronologia perfeita a menos que as fontes a apoiem. 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 do Heroku? Precisavam redefinir senhas de usuário do Heroku?

Precisavam inspecionar repositórios do GitHub? Precisavam verificar variáveis de ambiente 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 hasheadas." Pode dizer "não encontramos evidências para uma categoria, mas os clientes devem inspecionar seus próprios logs para esses 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 do Heroku usava integração GitHub. Nem todo usuário do GitHub autorizou o Heroku. Nem todo usuário do 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 é possível, o provedor deve explicar por que. 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 incidente duráveis? As mensagens incluíam datas e carimbos de data/hora? Elas identificavam serviços afetados? Elas forneciam ações concretas para o cliente? Elas atualizavam orientações anteriores quando mudavam? Elas mantinham registros diretos ao cliente e públicos consistentes? Elas publicaram 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 de desenvolvedor, comunicação pouco clara transfere custo para os clientes. Cada frase vaga se torna uma reunião, um ticket, uma busca em log, 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 desenvolvedor deve tratar aviso útil para decisão como parte do produto. O incidente do 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ência 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 do Heroku em 2022 colocou rotação e reautorização no centro da ação do cliente.

A questão de responsabilidade é se essas ações foram correspondidas por evidência de controle durável.

As páginas do Heroku Dev Center, como source: devcenter.heroku.com, source: devcenter.heroku.com, source: devcenter.heroku.com e source: devcenter.heroku.com, mostram o ambiente mais amplo de gerenciamento de acesso em torno do uso da plataforma Heroku. A página de autenticação de dois fatores do Heroku em source: devcenter.heroku.com fornece 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 cercar 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 ser retomados com novos tokens. Terceiro, há a revisão de credenciais adjacentes, incluindo chaves de API, senhas, chaves de implantação, variáveis CI, segredos de repositório, tokens de acesso pessoal e credenciais em 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 comprometidos e rotacionar qualquer valor exposto. A documentação de varredura de segredos do GitHub em source: docs.github.com fornece vocabulário atual para essa revisão do lado do cliente.

A orientação de cadeia de suprimentos de software do CISA em source: cisa.gov e os materiais de design seguro por design 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 a 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 qualquer lugar. Sem um sinal de conclusão, cada cliente tem que executar sua própria reconciliação. Isso é caro e propenso a erros.

A plataforma também precisa de evidência interna de conclusão. Quais contas de cliente concluíram as etapas necessárias? Quais contas permanecem em estado de exceção? Quais clientes eram 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 tokens 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 evidências diferentes

O mapa de responsabilidade do incidente é multipartidário. O GitHub possuía evidências de host de origem, visibilidade de aplicativo OAuth e o alerta de segurança que publicou. O Heroku possuía sua integração de plataforma, comunicação com o cliente, custódia de tokens e programa de credenciais forçadas. O Travis CI possuía seu canal de integração CI/CD afetado e orientação ao cliente. A Salesforce possuía governança do Heroku, alocação de recursos, escalação de risco e o dever de tornar o reparo da plataforma crível.

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 importa porque o dano ao cliente pode resultar de lacunas entre os 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 o Heroku sabe quais contas usavam integração GitHub, mas não pode dizer se os conteúdos do repositório foram acessados, os clientes devem revisar de forma mais ampla. Se o Travis CI e o 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 o Heroku como uma marca subsidiária enquanto os clientes tratam o Heroku como uma plataforma de produção, a governança tem que preencher o limite da marca.

Documentos de responsabilidade compartilhada em nuvem e SaaS frequentemente dizem que as obrigações do provedor e do cliente diferem. O incidente do Heroku mostra que a responsabilidade compartilhada também requer evidência compartilhada. 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 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 origem não pode assumir que ferramentas downstream traduzirão seu alerta perfeitamente.

Cada ator tem que tornar sua evidência útil 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 de responsabilidade claro. Os tokens OAuth devem ser escopados estreitamente, armazenados defensivamente, revogáveis rapidamente, monitorados continuamente e mapeados para propósito de negócio atual. As plataformas de desenvolvedor devem comunicar incidentes com especificidade suficiente para permitir que os clientes ajam. Os clientes devem revisar integrações periodicamente em vez de tratar a autorização como permanente.

Os hosts de origem devem disponibilizar evidência de auditoria o suficiente para que os clientes possam distinguir exposição possível de acesso confirmado.

O mapa de papéis também adverte contra culpa 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ência de controle pós-incidente pode reduzir recorrências. Essas são escolhas de design, não apenas declarações posteriores.

Evidência verificável pelo cliente é a metade ausente da responsabilidade compartilhada

O incidente do Heroku também mostra o limite da linguagem de responsabilidade compartilhada quando a evidência é assimétrica. Uma plataforma pode dizer aos clientes que eles são responsáveis pela higiene do repositório, rotação de segredos e revisão de aplicativos OAuth, mas o cliente ainda depende da evidência 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ência utilizável.

A evidência verificável pelo cliente começa com um inventário. Cada cliente deve poder ver quais aplicativos Heroku estavam conectados a quais organizações 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ório, uso de autorização OAuth, uso de chave de API, atividade de conta Heroku, eventos de implantação, eventos de build e mudanças 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 no Heroku, o provedor deve expor uma visão específica do cliente ou caminho de suporte.

Se alguma evidência está indisponível porque o registro não foi retido ou não foi coletado, o provedor deve dizer isso claramente. "Nenhuma evidência de uso indevido" é útil para decisão apenas quando os clientes sabem qual evidência foi revisada.

A terceira camada é a exposição de segredos. O risco de acesso a repositório não se limita ao código-fonte como propriedade intelectual. Também inclui segredos comprometidos, configuração histórica, credenciais de teste, tokens de implantação, chaves em nuvem, strings de conexão de banco de dados e comentários que revelam arquitetura. Os clientes precisam de orientação que vincule 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 uma revogação de token por si só fecha o risco de conteúdo de repositório.

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

A quinta camada é a limpeza durável. Um cliente deve poder saber quando o estado suspeito terminou. Os tokens OAuth antigos foram revogados? As integrações foram reautorizadas com novos tokens? As 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 inquilino com a evidência 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ência 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, também deve fornecer a evidência de que os clientes precisam para agir proporcionalmente.

Compras e governança devem tratar integrações como acesso permanente

A lição de compras é que as 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 disponibilidade perderá a lição do Heroku. As perguntas mais precisas são sobre inventário de integração, armazenamento de tokens, minimização de escopo, logs do cliente, revogação de emergência, notificações em nível de inquilino, isolamento de sistema de build e prova pós-incidente.

As plataformas de desenvolvedor devem esperar essas perguntas porque seus produtos intencionalmente se sentam perto da 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 usando 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 questões operacionais básicas para qualquer cliente cuja cadeia de suprimentos de software depende da plataforma.

A governança dentro da Salesforce e do Heroku também importa. O público não deve assumir que uma marca subsidiária carrega menos responsabilidade porque é focada em desenvolvedores. Os aplicativos Heroku podem ser aplicativos 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 o investimento em registro, 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 de desenvolvedor 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 o GitHub porque reduz o 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ência contratual. 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, terá dificuldade em 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 Heroku de teste é diferente de um aplicativo de produção voltado ao cliente. As organizações devem atribuir revisão, registro e recertificação mais fortes a integrações que podem afetar código de produção ou segredos.

O incidente do 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. As plataformas de desenvolvedor devem publicar evidência de incidente suficiente 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 a evidência do provedor possa ser acionada rapidamente. Os hosts de código-fonte devem manter controles OAuth e de auditoria utilizáveis. Os fornecedores de CI/CD devem separar segredos de build da confiança ampla de repositório. As empresas-mãe devem tratar a confiança do desenvolvedor como confiança de produção.

O incidente do Heroku em 2022 torna-se mais 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 os 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 de desenvolvedor tem pelo menos oito partes. Primeiro, o provedor deve publicar uma linha do tempo clara: detecção, notificação ao GitHub, investigação do Heroku, notificação ao cliente, revogação de token, 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 cliente, chaves de API, chaves de implantação, segredos de repositório e variáveis CI.

Quarto, o provedor deve publicar ações do cliente em uma lista de verificação que distingue etapas obrigatórias, recomendadas e condicionais. Quinto, deve declarar qual evidência o cliente pode ver e qual evidência apenas o provedor ou host de origem 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 do Heroku contém evidência significativa, mas a lição de responsabilidade é mais ampla que um incidente. As plataformas de desenvolvedor devem projetar para dias de token suspeito antes que aconteçam. Isso significa inventário de aplicativo OAuth, mapeamento de proprietário, minimização de escopo, rastreamento de idade do 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 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 comprometer credenciais, rotacionar segredos de longa duração, preservar logs de auditoria e mapear fluxos de implantação. A documentação do GitHub e do Heroku fornece muitos dos blocos de construção, mas o trabalho de governança pertence a cada organização.

Um incidente de fornecedor torna-se 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ência. Os tokens suspeitos foram invalidados? Os clientes impactados foram notificados? As redefinições necessárias foram concluídas? As perguntas de acesso ao código-fonte foram respondidas no nível que a evidência permitia? Os segredos e credenciais de implantação foram revisados? Os controles do produto foram alterados? As incógnitas residuais foram preservadas? Um "sim" para essas perguntas é mais forte que uma declaração geral de confiança porque diz aos clientes o que mudou.

O incidente OAuth do Heroku de 2022 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.