Salesforce a fait de la garde des tokens OAuth de Heroku un test de responsabilité de plateforme développeur

Résumé

• L'incident d'intégration GitHub de Heroku en 2022 est important car les tokens OAuth ne sont pas des mots de passe ordinaires; ils constituent une autorité déléguée qui peut connecter des dépôts source, des pipelines de déploiement, des systèmes de build, des applications clientes et des utilisateurs de logiciels en aval.
• GitHub a averti publiquement qu'un attaquant avait utilisé des tokens OAuth utilisateur volés émis vers Heroku et Travis CI, tandis que les communications d'incident de Heroku exigeaient des clients qu'ils suivent des consignes de rotation au fur et à mesure que l'enquête, la révocation et les réinitialisations de justificatifs évoluaient.
• La question de responsabilité n'est pas seulement de savoir si Heroku a finalement renouvelé les clés ou restauré les intégrations. Il s'agit de savoir qui contrôlait la garde des tokens, l'avis aux clients, le comportement de l'application GitHub, les preuves d'accès au code source, les limites de confiance CI/CD et les preuves post-incident.
• Cet article traite les sources Heroku, GitHub, Travis CI, Salesforce, IETF, NIST, CISA et MITRE comme des voies de preuve distinctes; aucune source publique n'est traitée comme un enregistrement médico-légal interne complet.
• La leçon durable est que la commodité de la plateforme développeur doit comporter un registre de garde: quel token d'intégration existe, pourquoi il existe, quelle portée il a, où il est stocké, qui peut le révoquer et quelles preuves les clients reçoivent lorsque le token devient suspect.

Pourquoi ce cas appartient à un dossier de risque et de responsabilité

Salesforce a fait de la garde des tokens OAuth de Heroku un test de responsabilité de plateforme développeur car Heroku est une plateforme développeur gérée dont la valeur repose sur la confiance à la frontière entre code, déploiement, identité et opérations. Les clients utilisent Heroku pour connecter des applications à des dépôts source, déployer du code, automatiser les flux de build, gérer des équipes, des services complémentaires, attacher des services de données et opérer des charges de travail de production. Une intégration Heroku-à-GitHub n'est donc pas une commodité cosmétique.

Elle peut devenir un pont entre le système de code source d'un client et une plateforme de déploiement, et de la plateforme de déploiement vers le risque opérationnel du client.

Le déclencheur public de 2022 était visible car GitHub a publié une alerte de sécurité àhttps://github.blog/news-insights/company-news/security-alert-stolen-oauth-user-tokens/décrivant des tokens OAuth utilisateur volés émis vers Heroku et Travis CI. La propre page d'incident de statut de Heroku àhttps://status.heroku.com/incidents/2413et la revue publique d'incident d'avril 2022 de Heroku àhttps://blog.heroku.com/april-2022-incident-reviewencadrent la question du côté de la plateforme. Le bulletin de sécurité de Travis CI àhttps://www.travis-ci.com/blog/2022-04-15-security-bulletin/fournit une autre voie d'intégration affectée. Ces sources établissent les contours publics: tokens OAuth connectés aux workflows développeur, notification client, mises à jour d'enquête et une séquence d'actions de protection.

L'affaire est importante car OAuth change la forme de la responsabilité. Un mot de passe volé peut souvent être expliqué par un seul compte utilisateur. Un token OAuth volé peut représenter une autorité déléguée qui a survécu au-delà du moment où un utilisateur a pensé au consentement. Il peut porter un accès au dépôt, un accès aux workflows automatisés, une portée API, un accès aux métadonnées, des implications d'appartenance à une organisation ou une autorité de déploiement. Les documents IETF OAuth 2.0 àhttps://datatracker.ietf.org/doc/html/rfc6749et l'enregistrement des meilleures pratiques actuelles de sécurité OAuth àhttps://datatracker.ietf.org/doc/html/rfc9700ne sont pas des rapports d'incident sur Heroku, mais ils aident à définir pourquoi l'émission de token, la portée, le stockage, la rotation, la révocation, la résistance à la relecture et la confiance client sont importants.

Le dossier de responsabilité ne devrait pas aplatir Heroku, Salesforce, GitHub, Travis CI et les clients en un seul acteur. Salesforce possédait Heroku en tant qu'entreprise et marque. Heroku contrôlait la conception de l'intégration de la plateforme, les communications avec les clients, la gestion des justificatifs dans sa plateforme et les preuves qu'il pouvait publier. GitHub contrôlait sa propre enquête, la révocation des tokens, les preuves d'hôte source, les contrôles d'application OAuth et l'alerte de sécurité client. Travis CI contrôlait son canal d'intégration affecté et ses messages clients.

Les clients contrôlaient leurs propres autorisations de dépôt, choix de déploiement, rotation des secrets, revue d'audit et réponse aux instructions. Les utilisateurs de logiciels en aval portaient le risque si l'accès au code source ou la confiance de déploiement produisaient une exposition ultérieure.

Cette carte des rôles est importante car les plateformes développeur créent une responsabilité partagée sans toujours donner des preuves partagées. Les clients de Heroku pouvaient être invités à renouveler leurs justificatifs ou à inspecter leurs dépôts, mais ils ne pouvaient pas reconstruire indépendamment chaque chemin de stockage de token côté Heroku ou action d'attaquant côté GitHub. Les utilisateurs de GitHub pouvaient révoquer une application OAuth, mais ils ne savaient pas peut-être quel pipeline de déploiement Heroku, application ou équipe nécessitait un accès de remplacement.

Un responsable des achats pouvait demander si la plateforme restait acceptable, mais la décision dépendait de détails techniques qui n'étaient pas tous publics. La question de responsabilité est donc l'allocation des preuves: que savait chaque acteur, que pouvait prouver chaque acteur, et que devaient faire les clients pendant que l'incertitude subsistait?

Le dossier public montre également pourquoi les incidents d'outils développeur appartiennent à la responsabilité de la chaîne d'approvisionnement logicielle, pas seulement à la responsabilité de sécurité des comptes. L'accès au code source est en amont de la sécurité des applications, des secrets, des jobs CI/CD, des artefacts de build, des justificatifs de déploiement et des versions de produits. La technique d'access-token d'application MITRE ATT&CK àhttps://attack.mitre.org/techniques/T1528/et la technique de matériel d'authentification alternatif àhttps://attack.mitre.org/techniques/T1550/sont un vocabulaire utile car ils distinguent l'utilisation abusive de token de la simple devinette de justificatif. Les documents 'secure-by-design' de CISA àhttps://www.cisa.gov/securebydesignet le cadre de développement logiciel sécurisé de NIST àhttps://csrc.nist.gov/pubs/sp/800/218/finalaident à expliquer pourquoi la garde du code source et la confiance du système de build doivent être traitées comme des contrôles de production.

Cet article ne prétend pas avoir accès aux logs privés de Heroku, aux données d'audit de dépôt privé de GitHub, aux enregistrements internes de Travis CI, aux avis client par client, aux communications avec les forces de l'ordre ou aux documents du conseil d'administration de Salesforce. Il utilise le dossier public pour demander si les preuves rendaient le contrôle pratique visible.

Un dossier de responsabilité solide montrerait non seulement que les tokens ont été révoqués, mais quand l'activité suspecte a été détectée, quelles portées étaient impliquées, quels clients nécessitaient une action, quel accès au dépôt a été confirmé ou écarté, quels secrets ont pu être exposés, quand les justificatifs ont été renouvelés et ce qui a changé pour que le même chemin de garde de token ne puisse pas se répéter silencieusement.

Le consentement OAuth devient une garde après le premier clic

La première erreur opérationnelle dans de nombreuses revues OAuth est de traiter le consentement comme une décision utilisateur unique. Dans une plateforme développeur, le consentement devient une garde. Une fois qu'un utilisateur autorise une application à accéder à un dépôt, la plateforme, le fournisseur d'identité, l'hôte de code source et l'administrateur client héritent tous d'obligations continues. Le token a un cycle de vie. Il est émis, stocké, rafraîchi, utilisé, journalisé, limité en portée, révoqué, remplacé et finalement oublié ou retiré.

L'incident Heroku est important car le dossier public a forcé les clients à réfléchir à ce cycle de vie après que la décision de confiance avait déjà été intégrée dans les workflows de développement.

La documentation OAuth actuelle de GitHub àhttps://docs.github.com/en/apps/oauth-appset les conseils de maintenance d'application OAuth àhttps://docs.github.com/en/apps/oauth-apps/maintaining-oauth-appssont utiles car ils montrent le vocabulaire de contrôle autour des applications OAuth, des secrets client, des URL de callback, de la propriété et de la gestion des applications. Les conseils de journal d'audit d'entreprise de GitHub à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-enterprisemontrent pourquoi les organisations ont besoin de preuves d'activité après un événement d'intégration suspecté. La documentation d'intégration GitHub de Heroku àhttps://devcenter.heroku.com/articles/github-integrationmontre la surface fonctionnelle visible par le client. Aucun de ces documents ne prouve exactement ce qui s'est passé en 2022. Ils établissent la surface opérationnelle que les clients devaient sécuriser.

La garde signifie que la plateforme doit répondre à un ensemble de questions différent de la simple disponibilité. Où étaient stockés les tokens OAuth? Des refresh tokens ou des access tokens étaient-ils impliqués? Étaient-ils chiffrés, segmentés ou isolés par locataire? Quel service ou base de données pouvait les lire? Quelle surveillance montrerait une utilisation inhabituelle? Qui pouvait les révoquer? Quelle action client était nécessaire après la révocation? Heroku pouvait-il déployer depuis GitHub sans le consentement renouvelé du client?

Les secrets de build, les variables de configuration, le contenu des dépôts ou les clés de déploiement étaient-ils en risque? Lesquelles de ces réponses étaient connues au premier avis, et lesquelles étaient encore en cours d'investigation?

Ces questions ne sont pas hostiles. Elles sont la base de la confiance. Une plateforme développeur peut avoir une raison valable de stocker des tokens, mais la raison doit être associée à des preuves de protection. Une plateforme peut révoquer des tokens rapidement, mais la preuve de révocation doit être associée à des instructions client. Une plateforme peut exiger le renouvellement des mots de passe ou des clés API Heroku, mais les clients doivent savoir pourquoi ce renouvellement est nécessaire et si l'inspection du dépôt est également requise.

Une plateforme peut dire qu'aucune action client n'est nécessaire pour un sous-ensemble d'utilisateurs, mais cette déclaration doit être liée à une frontière technique.

Le dossier public de Heroku comprenait des instructions client évolutives. Cette évolution n'est pas automatiquement un échec. La réponse aux incidents passe souvent de la suspicion à la confirmation par étapes. La question de responsabilité est de savoir si les étapes sont suffisamment visibles pour que les clients puissent suivre sans deviner. Si le premier message d'un client dit une chose et un message ultérieur nécessite une action plus large, la plateforme devrait expliquer quelles preuves ont changé.

Si on dit à un client de renouveler ses justificatifs, l'instruction devrait spécifier quels justificatifs, quelle échéance, quels contextes d'application et quels logs les clients devraient examiner.

La dimension économique est réelle. Les équipes de développement optimisent pour une intégration rapide car le déploiement manuel et la gestion des justificatifs sont coûteux. Les applications OAuth réduisent les frictions. Mais lorsque le chemin de garde côté fournisseur échoue, le coût de la commodité réapparaît comme un travail d'urgence: révision des dépôts, renouvellement des secrets, reconstruction des intégrations, recherche dans les logs, explication de l'exposition aux clients et réponse aux auditeurs. L'économie des outils développeur appartient donc à la liste de sujets de l'article.

La plateforme qui bénéficie d'une intégration facile doit investir dans la garde, la révocation et les preuves.

L'accès au code source n'est pas la même chose qu'une compromission de production, mais il n'est pas inoffensif

Le dossier public doit résister à deux mauvaises simplifications. La première est de dire que les tokens OAuth volés signifient automatiquement que les applications de production ont été compromises. La seconde est de dire que l'accès au code source est inoffensif si aucune interruption de production ne s'est produite. Les deux affirmations sont faibles. Le code source peut contenir de la logique applicative, des informations de dépendance, des points d'accès internes, des scripts de déploiement, des motifs de configuration, des montages de test, des commentaires, d'anciens secrets, des noms d'infrastructure et des hypothèses de sécurité.

En même temps, l'accès au code source seul ne prouve pas un accès au runtime, un vol de données ou une manipulation du déploiement.

L'alerte de GitHub et les communications d'incident de Heroku sont importantes car elles mettent le risque d'accès au code source dans le dossier public. Un client avec des dépôts connectés devait savoir si un attaquant pouvait lire des dépôts privés, si les dépôts contenaient des secrets commités, si des justificatifs de déploiement existaient en dehors de GitHub, si GitHub Actions, les pipelines Heroku, les applications de révision ou les jobs CI exposaient des éléments supplémentaires, et si les journaux d'audit au niveau du dépôt montraient un accès inhabituel.

Si le client utilisait Travis CI, les mêmes questions pouvaient s'étendre aux variables d'environnement CI et aux logs de build.

Le NIST SP 800-218 àhttps://csrc.nist.gov/pubs/sp/800/218/finalest utile car il traite le développement logiciel sécurisé comme un cycle de vie, pas seulement l'écriture de code. Le NIST SP 800-204D àhttps://csrc.nist.gov/pubs/sp/800/204/d/finalaide à encadrer les questions de sécurité des applications cloud natives et d'identité de service. Le NIST SP 800-53 Rev. 5 àhttps://csrc.nist.gov/pubs/sp/800/53/r5/upd1/finalfournit un vocabulaire de contrôle pour le contrôle d'accès, l'audit, la configuration, la réponse aux incidents et l'intégrité du système. Ces documents ne sont pas des résultats spécifiques à Heroku. Ce sont des références pour décider si un incident de plateforme développeur devrait être examiné comme un événement de chaîne d'approvisionnement logicielle.

La frontière clé est la preuve. Si une plateforme peut déterminer qu'un token OAuth a été utilisé uniquement pour un certain dépôt ou ensemble de clients, elle devrait expliquer la base de cette détermination. Si elle ne peut pas déterminer l'accès client par client en raison de limites de journalisation, elle devrait le dire. Si GitHub peut notifier les utilisateurs affectés en fonction de l'utilisation du token ou de l'accès au dépôt, le dossier public devrait identifier ce que la notification signifie et ce qu'elle ne signifie pas.

Si les clients doivent inspecter leurs propres logs, le fournisseur devrait indiquer quelles sources de logs sont importantes.

Le risque public diffère également selon la maturité du client. Une grande entreprise peut avoir des journaux d'audit d'entreprise GitHub, une analyse centralisée des secrets, une analyse de composition logicielle, une ségrégation CI/CD et une équipe de réponse aux incidents. Un plus petit client Heroku peut avoir une simple connexion GitHub, un ou deux mainteneurs et une rétention de logs limitée. Le même événement de token crée donc des charges différentes. Un dossier de responsabilité mature ne suppose pas que chaque client peut combler indépendamment les lacunes de preuve du fournisseur.

Il donne aux petites équipes des étapes pratiques et aux grandes équipes suffisamment de détails techniques pour automatiser la revue.

Le public en aval est plus large que les propriétaires de compte Heroku. Si l'accès au code source révèle des vulnérabilités ou des secrets, les utilisateurs en aval du logiciel du client peuvent être affectés plus tard, même si l'incident de plateforme initial n'a pas causé de temps d'arrêt immédiat. Cela ne signifie pas que chaque utilisateur en aval a été lésé. Cela signifie que l'analyse de responsabilité doit tracer le chemin de risque: vol de token, accès possible au dépôt, possible exposition de source ou de secret, possible utilisation abusive CI/CD, possible accès à la production et possible préjudice en aval.

Chaque étape nécessite des preuves avant de devenir une affirmation.

Le timing de la notification fait partie de la surface de contrôle

La communication d'incident est souvent traitée comme une fonction juridique ou de relations publiques, mais pour les plateformes développeur, c'est un contrôle opérationnel. Les clients ne peuvent pas révoquer des tokens, renouveler des secrets, reconstruire des intégrations ou inspecter des dépôts tant qu'ils ne savent pas quoi faire. Un avis retardé, vague ou changeant peut prolonger la période pendant laquelle les clients sont exposés ou incertains. Un avis rapide mais incomplet peut créer un travail inutile. La norme de responsabilité n'est donc pas simplement la rapidité. C'est l'utilité de décision à chaque étape.

La page d'incident de Heroku àhttps://status.heroku.com/incidents/2413est utile car les mises à jour de statut montrent une séquence plutôt qu'une seule déclaration finale. L'alerte de sécurité de GitHub fournit une autre voie de chronologie. Le bulletin de Travis CI en fournit une troisième. Un lecteur attentif ne devrait pas fusionner ces chronologies en une chronologie parfaite à moins que les sources ne le soutiennent. La question utile est de savoir comment l'avis de chaque acteur a changé l'action du client. Les clients devaient-ils révoquer l'autorisation de l'application? Devaient-ils renouveler les clés API Heroku? Devaient-ils renouveler les mots de passe Heroku? Devaient-ils inspecter les dépôts GitHub? Devaient-ils vérifier les variables d'environnement CI? Devaient-ils reconstruire les hooks de déploiement?

La réponse a pu changer à mesure que les faits émergeaient. C'est acceptable lorsque les changements sont expliqués. Un avis peut dire 'nous enquêtons sur un accès possible et fournirons des instructions supplémentaires.' Il peut dire 'nous avons révoqué les tokens et les clients doivent réautoriser.' Il peut dire 'nous exigeons une réinitialisation de mot de passe car nous ne pouvons pas exclure un accès aux justificatifs hachés.' Il peut dire 'nous n'avons trouvé aucune preuve pour une catégorie, mais les clients devraient inspecter leurs propres logs pour ces indicateurs.' Ce qui affaiblit la responsabilité n'est pas l'incertitude.

Ce qui affaiblit la responsabilité est l'incertitude présentée comme une clôture.

La notification client a également un devoir de segmentation. Tous les clients Heroku n'utilisaient pas l'intégration GitHub. Tous les utilisateurs GitHub n'ont pas autorisé Heroku. Tous les utilisateurs Travis CI n'avaient pas la même portée. Tous les dépôts ne contenaient pas de matériel sensible. Un avis utile distingue les groupes affectés, potentiellement affectés, non affectés et inconnus. Si une segmentation exacte n'est pas possible, le fournisseur devrait expliquer pourquoi. Les clients ne devraient pas avoir à déduire si un message s'applique à eux à partir de gros titres généraux.

La qualité de la communication peut être mesurée. Le fournisseur a-t-il publié des pages d'incident durables? Les messages incluaient-ils des dates et horodatages? Ont-ils identifié les services affectés? Ont-ils fourni des actions concrètes pour les clients? Ont-ils mis à jour les conseils antérieurs lorsqu'ils ont changé? Ont-ils maintenu la cohérence entre les dossiers clients directs et publics? Ont-ils publié une revue post-incident qui nommait les améliorations de contrôle sans divulguer de détail privé exploitable? Ce sont des questions de responsabilité autant que des questions de communication.

Dans l'économie des outils développeur, une communication peu claire transfère le coût aux clients. Chaque phrase vague devient une réunion, un ticket, une recherche de logs, un email client ou une exception d'audit en aval. Une plateforme peut être juridiquement prudente, mais une plateforme qui vend la confiance des développeurs devrait traiter l'avis utile à la décision comme faisant partie du produit. L'incident Heroku montre pourquoi les communications d'incident ont besoin d'une discipline d'ingénierie produit: instructions versionnées, audiences ciblées, corrections traçables et preuves d'achèvement.

Le renouvellement forcé n'est un remède que si les clients savent ce qui a changé

Le renouvellement forcé des justificatifs peut être nécessaire et encore incomplet comme réparation de la confiance. Un client peut renouveler une clé API, réinitialiser un mot de passe ou réautoriser une application OAuth, mais le client doit également comprendre ce qui a changé dans le modèle de garde de la plateforme. Si le même chemin de stockage, la même conception de portée, la même lacune de surveillance ou la même lacune de preuve client subsistent, le renouvellement peut restaurer l'accès sans restaurer la confiance.

Le dossier public autour de l'incident de Heroku en 2022 a placé le renouvellement et la réautorisation au centre de l'action client. La question de responsabilité est de savoir si ces actions ont été assorties de preuves de contrôle durables.

Les pages du centre de développement Heroku telles quehttps://devcenter.heroku.com/articles/oauth,https://devcenter.heroku.com/articles/platform-api-reference,https://devcenter.heroku.com/articles/heroku-cliethttps://devcenter.heroku.com/articles/account-securitymontrent l'environnement plus large de gestion des accès autour de l'utilisation de la plateforme Heroku. La page d'authentification à deux facteurs Heroku àhttps://devcenter.heroku.com/articles/heroku-2fafournit un contexte de durcissement de compte côté client. Encore une fois, la documentation actuelle n'est pas une preuve de l'état interne de 2022. Elle aide les lecteurs à comprendre les types de justificatifs et d'actions utilisateur qui peuvent entourer un compte Heroku.

Le renouvellement a trois couches distinctes. Premièrement, il y a la révocation des tokens OAuth compromis afin que l'attaquant ne puisse pas continuer à utiliser l'autorisation déléguée. Deuxièmement, il y a le remplacement ou la réautorisation côté client pour que les workflows légitimes puissent reprendre avec de nouveaux tokens. Troisièmement, il y a la revue des justificatifs adjacents, y compris les clés API, les mots de passe, les clés de déploiement, les variables CI, les secrets de dépôt, les tokens d'accès personnel et les justificatifs cloud. Un avis de plateforme devrait indiquer clairement quelle couche est requise et pourquoi.

La couche la plus difficile est l'exposition des secrets dans le code source. Si un attaquant pouvait lire les dépôts, le simple renouvellement du token OAuth peut ne pas suffire. Les clients peuvent avoir besoin de rechercher dans les dépôts des secrets commités et de renouveler toute valeur exposée. La documentation de scan de secrets de GitHub àhttps://docs.github.com/en/code-security/secret-scanning/about-secret-scanningfournit le vocabulaire actuel pour cette revue côté client. Les conseils sur la chaîne d'approvisionnement logicielle de CISA àhttps://www.cisa.gov/resources-tools/resources/software-supply-chain-risk-management-sscrmet les documents 'secure-by-design' aident à expliquer pourquoi les secrets dans le code peuvent transformer un événement de dépôt en un risque opérationnel plus large.

Le renouvellement forcé a également besoin d'un signal d'achèvement. Les clients devraient savoir si les anciens tokens sont invalides, si une réautorisation est requise, si les intégrations désactivées resteront désactivées jusqu'à action, si l'achèvement de la réinitialisation du mot de passe est suivi et si des justificatifs obsolètes sont toujours acceptés quelque part. Sans signal d'achèvement, chaque client doit effectuer sa propre réconciliation. C'est coûteux et sujet aux erreurs.

La plateforme a également besoin de preuves internes d'achèvement. Quels comptes clients ont terminé les étapes requises? Quels comptes restent en état d'exception? Quels clients étaient injoignables? Quelles intégrations ont été abandonnées? Quels tokens n'ont pas pu être attribués à un propriétaire actuel? Quels contrôles ont été ajoutés pour empêcher la rétention silencieuse de tokens à longue durée de vie? Un post-mortem public peut ne pas divulguer les noms des clients, mais il peut divulguer la forme du nettoyage. C'est la différence entre 'nous avons renouvelé' et 'l'état risqué n'existe plus.'

GitHub, Heroku, Travis CI, Salesforce et les clients possédaient chacun des preuves différentes

La carte de responsabilité de l'incident est multipartite. GitHub détenait les preuves d'hôte source, la visibilité des applications OAuth et l'alerte de sécurité qu'il a publiée. Heroku détenait son intégration de plateforme, la communication client, la garde des tokens et le programme de renouvellement forcé. Travis CI détenait sa voie d'intégration CI/CD affectée et les conseils clients. Salesforce détenait la gouvernance de Heroku, l'allocation des ressources, l'escalade des risques et le devoir de rendre crédible la réparation de la plateforme.

Les clients détenaient l'hygiène des dépôts, le renouvellement des secrets, les approvals OAuth organisationnelles et la revue de déploiement. Aucun de ces rôles n'annule les autres.

Cela est important car un préjudice client peut résulter des lacunes entre les rôles. Si GitHub sait qu'un token a été utilisé mais qu'un client ne sait pas quelle application Heroku y correspondait, la réponse du client est plus lente. Si Heroku sait quels comptes utilisaient l'intégration GitHub mais ne peut pas dire si le contenu des dépôts a été accédé, les clients doivent examiner plus largement. Si Travis CI et Heroku partagent une alerte GitHub mais ont des instructions client différentes, les organisations utilisant les deux doivent concilier des actions conflictuelles ou qui se chevauchent.

Si Salesforce traite Heroku comme une marque filiale alors que les clients traitent Heroku comme une plateforme de production, la gouvernance doit combler la frontière de marque.

Les documents de responsabilité partagée du cloud et des SaaS disent souvent que les obligations du fournisseur et du client diffèrent. L'incident Heroku montre que la responsabilité partagée nécessite également des preuves partagées. Un client ne peut pas accepter de manière responsable l'assurance d'un fournisseur si le fournisseur ne divulgue pas quelle partie de la chaîne l'assurance couvre. Un fournisseur ne peut pas de manière responsable reporter toute action sur les clients si les clients manquent des logs ou des fonctionnalités produits nécessaires pour agir.

Un hôte source ne peut pas supposer que les outils en aval traduiront parfaitement son alerte. Chaque acteur doit rendre ses preuves utiles à l'acteur suivant dans la chaîne.

Les sources IETF, NIST, MITRE, CISA, GitHub, Heroku et Travis CI forment ensemble un dossier public délimité. Elles ne révèlent pas tous les faits privés, mais elles permettent un modèle de responsabilité clair. Les tokens OAuth devraient être limités en portée de manière étroite, stockés de manière défendable, révocables rapidement, surveillés en continu et mappés à un objectif commercial actuel. Les plateformes développeur devraient communiquer les incidents avec suffisamment de spécificité pour permettre aux clients d'agir. Les clients devraient examiner les intégrations périodiquement au lieu de traiter l'autorisation comme permanente.

Les hôtes source devraient rendre les preuves d'audit suffisamment disponibles pour que les clients puissent distinguer une exposition possible d'un accès confirmé.

La carte des rôles met également en garde contre un blâme simpliste. Si un attaquant vole un token, l'attaquant est responsable de l'utilisation abusive. Mais la responsabilité demande qui pourrait réduire l'opportunité, le rayon d'explosion et l'incertitude. La conception du stockage des tokens peut réduire l'opportunité. La minimisation de la portée peut réduire le rayon d'explosion. Une révocation rapide peut réduire la durée. De bons logs peuvent réduire l'incertitude. Des instructions claires pour les clients peuvent réduire le travail gaspillé. Les preuves de contrôle post-incident peuvent réduire la récurrence.

Ce sont des choix de conception, pas seulement des déclarations après coup.

Les preuves vérifiables par le client sont la moitié manquante de la responsabilité partagée

L'incident Heroku montre également la limite du langage de responsabilité partagée lorsque les preuves sont asymétriques. Une plateforme peut dire aux clients qu'ils sont responsables de l'hygiène des dépôts, du renouvellement des secrets et de la revue des applications OAuth, mais le client dépend toujours des preuves du fournisseur pour décider où chercher.

Si le fournisseur ne peut pas dire si un token avait une portée de lecture de dépôt, s'il a été utilisé après une certaine date, s'il était lié à une application particulière ou si des logs spécifiques au client existent, alors la responsabilité du client devient un exercice de devinette. Un modèle de responsabilité partagée équitable donne aux clients à la fois des devoirs et des preuves utilisables.

Les preuves vérifiables par le client commencent par un inventaire. Chaque client devrait pouvoir voir quelles applications Heroku étaient connectées à quelles organisations GitHub, dépôts, utilisateurs et flux de déploiement. L'inventaire devrait montrer le statut actuel, la dernière autorisation, la portée, le propriétaire, l'exigence de réautorisation et si la connexion a été désactivée par le fournisseur. Sans cette carte, une équipe de sécurité doit reconstruire l'intégration à partir d'anciens tickets, de webhooks de dépôt, de l'historique de déploiement et de comptes développeur personnels.

C'est exactement le genre de travail d'urgence qu'une plateforme devrait réduire après un événement de token côté fournisseur.

La deuxième couche de preuve est l'activité. Les clients doivent savoir quels logs peuvent montrer l'accès au dépôt, l'utilisation de l'autorisation OAuth, l'utilisation de la clé API, l'activité du compte Heroku, les événements de déploiement, les événements de build et les changements de configuration. Si les preuves pertinentes n'existent que sur GitHub, le fournisseur devrait orienter les clients vers les enregistrements d'audit GitHub. Si les preuves pertinentes n'existent que sur Heroku, le fournisseur devrait exposer une vue spécifique au client ou un chemin de support.

Si certaines preuves ne sont pas disponibles parce que la journalisation n'a pas été conservée ou collectée, le fournisseur devrait le dire clairement. 'Aucune preuve d'utilisation abusive' n'est utile pour la décision que lorsque les clients savent quelles preuves ont été examinées.

La troisième couche est l'exposition des secrets. Le risque d'accès au dépôt ne se limite pas au code source en tant que propriété intellectuelle. Il inclut également les secrets commités, la configuration historique, les justificatifs de test, les tokens de déploiement, les clés cloud, les chaînes de connexion de base de données et les commentaires qui révèlent l'architecture. Les clients ont besoin de conseils qui relient l'incident de token au scan de secrets et au renouvellement.

Une réponse forte de la plateforme dirait quelles catégories sont probables, quelles catégories sont possibles et quelles catégories sont en dehors du chemin connu. Elle éviterait également d'impliquer qu'une simple révocation de token ferme le risque de contenu de dépôt.

La quatrième couche est l'assurance des versions logicielles. Si un client utilise Heroku pour des déploiements automatiques depuis GitHub, le client doit savoir si un accès non autorisé au dépôt a pu influencer le code déployé, les artefacts de build, les applications de révision, les pipelines ou l'historique des versions. Cela ne signifie pas qu'une telle influence a eu lieu. Cela signifie que le client devrait recevoir suffisamment d'informations pour le prouver ou le réfuter.

L'historique des versions, la provenance du build, les horodatages de déploiement, les signatures de commit de dépôt, les protections de branche et les logs CI deviennent tous partie du dossier de responsabilité.

La cinquième couche est le nettoyage durable. Un client devrait pouvoir dire quand l'état suspect a pris fin. Les anciens tokens OAuth ont-ils été révoqués? Les intégrations ont-elles été réautorisées avec de nouveaux tokens? Les rotations de mots de passe ou de clés API ont-elles été terminées? Les applications abandonnées ont-elles été désactivées? Les autorisations personnelles orphelines ont-elles été supprimées? La plateforme a-t-elle empêché l'ancienne classe de token de rester active dans un job d'arrière-plan ou un chemin hérité?

L'assurance du fournisseur est la plus forte lorsque les clients peuvent concilier leur propre état de locataire avec les preuves d'achèvement du fournisseur.

Ce modèle de preuves pour le client n'exige pas qu'un fournisseur publie des logs privés sensibles sur le web ouvert. Il peut être fourni via des tableaux de bord de compte, des avis directs, des exports de support, des briefings d'incident entreprise ou des packs de preuves contractuels. La forme peut varier selon le niveau de client et la sensibilité. Le principe ne devrait pas varier: lorsqu'un fournisseur demande aux clients d'agir, il devrait également fournir les preuves dont les clients ont besoin pour agir proportionnellement.

L'approvisionnement et la gouvernance devraient traiter les intégrations comme un accès permanent

La leçon d'approvisionnement est que les intégrations OAuth sont un accès permanent, pas des tâches de configuration ponctuelles. Un questionnaire de risque fournisseur qui demande seulement si le fournisseur prend en charge le chiffrement, l'authentification multifacteur ou les objectifs de disponibilité manquera la leçon de Heroku. Les questions plus précises concernent l'inventaire des intégrations, le stockage des tokens, la minimisation de la portée, les logs clients, la révocation d'urgence, les notifications au niveau du locataire, l'isolation du système de build et les preuves post-incident.

Les plateformes développeur devraient s'attendre à ces questions car leurs produits se situent intentionnellement près de la livraison logicielle.

Le langage contractuel devrait également éviter les transferts de responsabilité vagues. Un fournisseur peut exiger des clients qu'ils protègent leurs dépôts et justificatifs, mais il devrait indiquer comment les incidents d'intégration côté fournisseur seront traités. Le fournisseur notifiera-t-il chaque client utilisant l'intégration affectée? Fournira-t-il des fenêtres de temps affectées? Identifiera-t-il si l'accès au code source est confirmé, possible ou non observé? Exigera-t-il une réautorisation? Exposera-t-il des événements d'audit? Fournira-t-il un résumé post-incident?

Soutiendra-t-il les clients réglementés qui ont besoin de leurs propres notifications? Ce ne sont pas des termes de luxe pour les grandes entreprises. Ce sont des questions opérationnelles de base pour tout client dont la chaîne d'approvisionnement logicielle dépend de la plateforme.

La gouvernance au sein de Salesforce et Heroku importe également. Le public ne devrait pas supposer qu'une marque filiale porte moins de responsabilité parce qu'elle est axée développeur. Les applications Heroku peuvent être des applications de production, des outils internes, des API publiques, des prototypes devenus critiques ou des systèmes back-office qui traitent des workflows sensibles. La structure de propriété importe car la gouvernance détermine l'investissement dans la journalisation, la garde des tokens, la réponse aux incidents, le support client et l'ingénierie de sécurité.

Une société mère n'a pas besoin de divulguer chaque discussion du conseil d'administration pour montrer qu'un incident de plateforme développeur a reçu une attention de contrôle sérieuse.

La même question de gouvernance s'applique à la gestion de produit. Une équipe produit peut vouloir une intégration GitHub transparente car elle réduit les frictions et aide les clients à déployer rapidement. Une équipe de sécurité peut vouloir des tokens de courte durée, des portées étroites, des logs visibles par le client et une réautorisation périodique. Une équipe de support peut vouloir des messages assez simples pour les petits clients. Une équipe de vente entreprise peut vouloir des preuves contractuelles. La responsabilité apparaît là où ces incitations sont reconciliées avant un incident, pas seulement après.

Si la plateforme ne peut pas expliquer qui possède le risque de garde des tokens en fonctionnement normal, elle aura du mal à expliquer qui le possède pendant une crise.

Pour les clients, la réponse de gouvernance pratique est de classer les intégrations par conséquence. Une intégration de productivité personnelle est différente d'une intégration de déploiement qui peut lire le code source de production. Une application de dépôt en lecture seule est différente d'une application qui peut créer des déploiements ou gérer des webhooks. Une application Heroku d'essai est différente d'une application de production orientée client. Les organisations devraient attribuer une revue, une journalisation et une recertification plus fortes aux intégrations qui peuvent affecter le code de production ou les secrets.

L'incident Heroku rappelle que 'application connectée' est un objet de gouvernance, pas seulement une fonctionnalité de commodité.

Le résultat est une norme de responsabilité plus mature. Les plateformes développeur devraient publier suffisamment de preuves d'incident pour que les clients puissent prendre leurs propres décisions de risque. Les clients devraient maintenir un inventaire d'intégration suffisant pour que les preuves du fournisseur puissent être exploitées rapidement. Les hôtes de code source devraient maintenir les contrôles OAuth et d'audit utilisables. Les fournisseurs CI/CD devraient séparer les secrets de build de la confiance large du dépôt. Les sociétés mères devraient traiter la confiance développeur comme une confiance de production.

L'incident Heroku de 2022 devient plus qu'une alerte de sécurité historique lorsqu'il est lu ainsi. Il devient un test de savoir si la chaîne de livraison logicielle peut identifier l'accès permanent avant que les attaquants ne forcent tout le monde à regarder.

À quoi devrait ressembler une réparation durable après un incident de garde OAuth

La norme de réparation durable pour un incident OAuth de plateforme développeur comporte au moins huit parties. Premièrement, le fournisseur devrait publier une chronologie claire: détection, notification GitHub, enquête Heroku, notification client, révocation de token, rotation de justificatifs, disponibilité de réautorisation et post-mortem. Deuxièmement, il devrait identifier la surface d'intégration affectée sans impliquer que chaque client ou dépôt a été également affecté.

Troisièmement, il devrait expliquer la différence entre les tokens OAuth volés, les mots de passe clients, les clés API, les clés de déploiement, les secrets de dépôt et les variables CI.

Quatrièmement, le fournisseur devrait publier les actions clients dans une liste de contrôle qui distingue les étapes requises, recommandées et conditionnelles. Cinquièmement, il devrait indiquer quelles preuves le client peut voir et quelles preuves seul le fournisseur ou l'hôte source peut voir. Sixièmement, il devrait identifier quels contrôles ont changé: stockage de token, chiffrement, gestion des secrets, revue de portée, surveillance, détection d'anomalies, accès d'audit client ou dépréciation d'intégration.

Septièmement, il devrait fournir un signal d'achèvement, comme l'achèvement de la réinitialisation forcée, l'achèvement de la révocation de token ou l'application de la réautorisation. Huitièmement, il devrait indiquer clairement les inconnues résiduelles.

Le fichier public de Heroku contient des preuves significatives, mais la leçon de responsabilité est plus large qu'un seul incident. Les plateformes développeur devraient concevoir pour les jours de tokens suspects avant qu'ils ne se produisent. Cela signifie un inventaire des applications OAuth, un mappage des propriétaires, une minimisation de la portée, un suivi de l'âge des tokens, des workflows de révocation automatisés, des modèles de notification client, des pages d'action spécifiques au client, une exportation des journaux d'audit et une recertification périodique des intégrations.

Cela signifie également tester l'expérience client d'une réautorisation forcée avant une crise. Si les clients ne peuvent pas comprendre le chemin de réparation un jour calme, ils ne le comprendront pas pendant un incident.

Les clients ont également besoin d'habitudes durables. Ils devraient inventorier les applications OAuth, supprimer les intégrations inutilisées, restreindre l'approbation à l'échelle de l'organisation, exiger une revue pour les applications à portée élevée, utiliser le scan de secrets, éviter de commettre des justificatifs, renouveler les secrets à longue durée de vie, conserver les journaux d'audit et cartographier les flux de déploiement. La documentation de GitHub et Heroku fournit de nombreux éléments de base, mais le travail de gouvernance appartient à chaque organisation.

Un incident fournisseur devient plus gérable lorsque les clients savent déjà quelles applications sont connectées à quels dépôts et systèmes de production.

Le test final de responsabilité n'est pas de savoir si la plateforme peut dire que l'incident est clos. Il s'agit de savoir si la clôture peut être retracée jusqu'aux preuves. Les tokens suspects ont-ils été invalidés? Les clients impactés ont-ils été notifiés? Les réinitialisations requises ont-elles été terminées? Les questions d'accès au code source ont-elles été répondues au niveau permis par les preuves? Les secrets et les justificatifs de déploiement ont-ils été examinés? Les contrôles produits ont-ils été modifiés? Les inconnues résiduelles ont-elles été préservées?

Un 'oui' à ces questions est plus fort qu'une déclaration générale de confiance car il dit aux clients ce qui a changé.

L'incident OAuth de Heroku en 2022 appartient donc à la série risque et responsabilité de Daniel Kade parce qu'il rend la confiance développeur visible. L'incident transforme un bouton d'intégration familier en une question de garde. Il montre que les plateformes de code source, les plateformes de déploiement, les fournisseurs CI/CD et les clients sont connectés par une autorité déléguée qui survit au clic de l'utilisateur.

Lorsque cette autorité est volée, la responsabilité suit le token: qui l'a émis, qui l'a stocké, qui a pu le voir, qui l'a révoqué, qui a averti les utilisateurs, qui a prouvé la réparation et qui a payé le coût alors que la preuve était encore incomplète.