Salesforce convirtió la custodia de tokens OAuth de Heroku en una prueba de responsabilidad para plataformas de desarrolladores

Resumen

• El incidente de integración con GitHub de Heroku en 2022 es relevante porque los tokens OAuth no son contraseñas comunes; son autoridad delegada que puede conectar repositorios fuente, tuberías de despliegue, sistemas de compilación, aplicaciones de clientes y usuarios finales de software.
• GitHub advirtió públicamente que un atacante usó tokens OAuth de usuario robados emitidos a Heroku y Travis CI, mientras que las comunicaciones de incidentes de Heroku requirieron que los clientes siguieran pautas de rotación a medida que evolucionaban la investigación, la revocación y los restablecimientos de credenciales.
• La cuestión de responsabilidad no es solo si Heroku eventualmente rotó claves o restauró integraciones. Es quién controló la custodia de tokens, la notificación al cliente, el comportamiento de la aplicación de GitHub, la evidencia de acceso al código fuente, los límites de confianza de CI/CD y la prueba posterior al incidente.
• Este artículo trata a Heroku, GitHub, Travis CI, Salesforce, IETF, NIST, CISA y MITRE como vías de evidencia separadas; ninguna fuente pública se trata como un registro forense interno completo.
• La lección duradera es que la conveniencia de la plataforma de desarrolladores debe ir acompañada de un registro de custodia: qué token de integración existe, por qué existe, qué alcance tiene, dónde se almacena, quién puede revocarlo y qué evidencia reciben los clientes cuando el token se vuelve sospechoso.

Por qué este caso pertenece a un archivo de riesgo y responsabilidad

Salesforce convirtió la custodia de tokens OAuth de Heroku en una prueba de responsabilidad para plataformas de desarrolladores, porque Heroku es una plataforma de desarrollo gestionada cuyo valor se basa en la confianza en los límites entre código, despliegue, identidad y operaciones. Los clientes usan Heroku para conectar aplicaciones a repositorios fuente, desplegar código, automatizar flujos de compilación, gestionar equipos, añadir complementos, adjuntar servicios de datos y operar cargas de trabajo de producción. Una integración de Heroku con GitHub no es, por tanto, una conveniencia cosmética.

Puede convertirse en un puente desde el sistema de código fuente del cliente hasta una plataforma de despliegue y desde una plataforma de despliegue de vuelta al riesgo operativo del cliente.

El desencadenante público de 2022 fue visible porque GitHub publicó una alerta de seguridad enhttps://github.blog/news-insights/company-news/security-alert-stolen-oauth-user-tokens/describiendo tokens OAuth de usuario robados emitidos a Heroku y Travis CI. La propia página de incidentes de estado de Heroku enhttps://status.heroku.com/incidents/2413y la revisión pública del incidente de abril de 2022 de Heroku enhttps://blog.heroku.com/april-2022-incident-reviewenmarcan el asunto desde el lado de la plataforma. El boletín de seguridad de Travis CI enhttps://www.travis-ci.com/blog/2022-04-15-security-bulletin/proporciona otra vía de integración afectada. Esas fuentes establecen los contornos públicos: tokens OAuth conectados a flujos de trabajo de desarrolladores, notificación al cliente, actualizaciones de investigación y una secuencia de acciones protectoras.

El caso importa porque OAuth cambia la forma de la responsabilidad. Una contraseña robada a menudo puede explicarse a través de una sola cuenta de usuario. Un token OAuth robado puede representar autoridad delegada que sobrevivió más allá del momento en que un usuario pensó por última vez en el consentimiento. Puede conllevar acceso al repositorio, acceso automatizado al flujo de trabajo, alcance de API, acceso a metadatos, implicaciones para la pertenencia a la organización o autoridad de despliegue. El material de IETF OAuth 2.0 enhttps://datatracker.ietf.org/doc/html/rfc6749y el registro de mejores prácticas de seguridad de OAuth enhttps://datatracker.ietf.org/doc/html/rfc9700no son informes de incidentes sobre Heroku, pero ayudan a definir por qué la emisión, el alcance, el almacenamiento, la rotación, la revocación, la resistencia a la repetición y la confianza del cliente de los tokens son importantes.

El archivo de responsabilidad no debe aplanar a Heroku, Salesforce, GitHub, Travis CI y los clientes en un solo actor. Salesforce era propietaria de Heroku como negocio y marca. Heroku controlaba el diseño de la integración de la plataforma, las comunicaciones con el cliente, el manejo de credenciales en su plataforma y la prueba que podía publicar. GitHub controlaba su propia investigación, la revocación de tokens, la evidencia del host fuente, los controles de la aplicación OAuth y la alerta de seguridad dirigida al cliente. Travis CI controlaba su canal de integración afectado y los mensajes al cliente.

Los clientes controlaban sus propios permisos de repositorio, elecciones de despliegue, rotación de secretos, revisión de auditoría y respuesta a las instrucciones. Los usuarios finales de software asumían el riesgo si el acceso al código fuente o la confianza en el despliegue producían una exposición posterior.

Ese mapa de roles es importante porque las plataformas de desarrolladores crean responsabilidad compartida sin proporcionar siempre evidencia compartida. A los clientes de Heroku se les podía decir que rotaran credenciales o inspeccionaran repositorios, pero no podían reconstruir de forma independiente todas las rutas de almacenamiento de tokens del lado de Heroku o las acciones del atacante del lado de GitHub. Los usuarios de GitHub podían revocar una aplicación OAuth, pero quizás no sabían qué tubería de despliegue, aplicación o equipo de Heroku requería acceso de reemplazo.

Un responsable de adquisiciones podía preguntar si la plataforma seguía siendo aceptable, pero la decisión dependía de detalles técnicos que no eran todos públicos. Por tanto, la cuestión responsable es la asignación de evidencia: ¿qué sabía cada actor, qué podía probar cada actor y qué tenían que hacer los clientes mientras persistía la incertidumbre?

El registro público también muestra por qué los incidentes de herramientas de desarrolladores pertenecen a la responsabilidad de la cadena de suministro de software, no solo a la responsabilidad de la seguridad de cuentas. El acceso al código fuente es anterior a la seguridad de las aplicaciones, los secretos, los trabajos de CI/CD, los artefactos de compilación, las credenciales de despliegue y los lanzamientos de productos. La técnica de token de acceso a la aplicación de MITRE ATT&CK enhttps://attack.mitre.org/techniques/T1528/y la técnica de material de autenticación alternativo enhttps://attack.mitre.org/techniques/T1550/son vocabulario útil porque distinguen el uso indebido de tokens de la adivinación de credenciales ordinaria. Los materiales de diseño seguro de CISA enhttps://www.cisa.gov/securebydesigny el Marco de Desarrollo de Software Seguro de NIST enhttps://csrc.nist.gov/pubs/sp/800/218/finalayudan a explicar por qué la custodia del código fuente y la confianza en el sistema de compilación deben tratarse como controles de producción.

Este artículo no afirma tener acceso a registros privados de Heroku, datos de auditoría de repositorios privados de GitHub, registros internos de Travis CI, avisos cliente por cliente, comunicaciones con las fuerzas del orden o materiales de la junta directiva de Salesforce. Utiliza el archivo público para preguntar si la evidencia hacía visible el control práctico.

Un registro de responsabilidad sólido mostraría no solo que los tokens fueron revocados, sino cuándo se detectó la actividad sospechosa, qué alcances estaban involucrados, qué clientes necesitaban acción, qué acceso al repositorio fue confirmado o descartado, qué secretos podrían haber estado expuestos, cuándo se rotaron las credenciales y qué cambió para que la misma ruta de custodia de tokens no pudiera repetirse en silencio.

El consentimiento OAuth se convierte en custodia después del primer clic

El primer error operativo en muchas revisiones de OAuth es tratar el consentimiento como una decisión única del usuario. En una plataforma de desarrolladores, el consentimiento se convierte en custodia. Una vez que un usuario autoriza a una aplicación a acceder a un repositorio, la plataforma, el proveedor de identidad, el host del código fuente y el administrador del cliente heredan obligaciones continuas. El token tiene un ciclo de vida. Se emite, almacena, actualiza, utiliza, registra, limita en alcance, revoca, reemplaza y finalmente se olvida o retira.

El incidente de Heroku importa porque el registro público obligó a los clientes a pensar en ese ciclo de vida después de que la decisión de confianza ya se hubiera integrado en los flujos de trabajo de desarrollo.

La documentación actual de OAuth de GitHub enhttps://docs.github.com/en/apps/oauth-appsy la guía de mantenimiento de OAuth enhttps://docs.github.com/en/apps/oauth-apps/maintaining-oauth-appsson útiles porque muestran el vocabulario de control en torno a las aplicaciones OAuth, los secretos de cliente, las URL de devolución de llamada, la propiedad y la gestión de aplicaciones. La guía de registros de auditoría empresarial de GitHub enhttps://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-enterprisemuestra por qué las organizaciones necesitan evidencia de actividad después de un evento de integración sospechoso. La documentación de integración con GitHub de Heroku enhttps://devcenter.heroku.com/articles/github-integrationmuestra la superficie de funcionalidad visible para el cliente. Ninguno de esos documentos prueba exactamente lo que ocurrió en 2022. Establecen la superficie operativa que los clientes debían asegurar.

Custodia significa que la plataforma debe responder a un conjunto diferente de preguntas que el tiempo de actividad normal. ¿Dónde se almacenaban los tokens OAuth? ¿Estaban involucrados tokens de actualización o de acceso? ¿Estaban cifrados, segmentados o aislados por inquilino? ¿Qué servicio o base de datos podía leerlos? ¿Qué monitoreo mostraría un uso inusual? ¿Quién podía revocarlos? ¿Qué acción del cliente era necesaria después de la revocación? ¿Podía Heroku desplegar desde GitHub sin el consentimiento renovado del cliente?

¿Estaban en riesgo los secretos de tiempo de compilación, las variables de configuración, los contenidos del repositorio o las claves de despliegue? ¿Cuáles de esas respuestas se conocían en el primer aviso y cuáles estaban aún bajo investigación?

Esas preguntas no son hostiles. Son la base de la confianza. Una plataforma de desarrolladores puede tener una razón válida para almacenar tokens, pero la razón debe ir acompañada de evidencia de protección. Una plataforma puede revocar tokens rápidamente, pero la evidencia de revocación debe ir acompañada de instrucciones para el cliente. Una plataforma puede exigir la rotación de contraseñas de usuario o claves API de Heroku, pero los clientes necesitan saber por qué esa rotación es necesaria y si también se requiere la inspección del repositorio.

Una plataforma puede decir que no se necesita ninguna acción del cliente para un subconjunto de usuarios, pero esa afirmación debe estar vinculada a un límite técnico.

El registro público de Heroku incluía instrucciones al cliente en evolución. Esa evolución no es automáticamente un fracaso. La respuesta a incidentes a menudo pasa de la sospecha a la confirmación a través de etapas. El problema de responsabilidad es si las etapas son lo suficientemente visibles para que los clientes puedan seguirlas sin adivinar. Si el primer mensaje de un cliente dice una cosa y un mensaje posterior requiere una acción más amplia, la plataforma debe explicar qué evidencia cambió.

Si se dice al cliente que rote credenciales, la instrucción debe especificar qué credenciales, qué plazo, qué contextos de aplicación y qué registros debe revisar el cliente.

La dimensión económica es real. Los equipos de desarrollo optimizan para una integración rápida porque el despliegue manual y la gestión de credenciales son costosos. Las aplicaciones OAuth reducen la fricción. Pero cuando la ruta de custodia del lado del proveedor falla, el costo de la conveniencia reaparece como trabajo de emergencia: revisar repositorios, rotar secretos, reconstruir integraciones, buscar registros, explicar la exposición a los clientes y responder a los auditores. La economía de las herramientas de desarrollador pertenece, por tanto, a la lista de temas del artículo.

La plataforma que se beneficia de una integración fácil tiene que invertir en custodia, revocación y evidencia.

El acceso al código fuente no es lo mismo que el compromiso de producción, pero no es inofensivo

El registro público debe resistir dos simplificaciones erróneas. La primera es decir que los tokens OAuth robados significan automáticamente que las aplicaciones de producción se vieron comprometidas. La segunda es decir que el acceso al código fuente es inofensivo si no se produjo ninguna interrupción de la producción. Ambas afirmaciones son débiles. El código fuente puede contener lógica de aplicación, información de dependencias, endpoints internos, scripts de despliegue, patrones de configuración, accesorios de prueba, comentarios, secretos antiguos, nombres de infraestructura y suposiciones de seguridad.

Al mismo tiempo, el acceso al código fuente por sí solo no prueba el acceso en tiempo de ejecución, el robo de datos o la manipulación del despliegue.

La alerta de GitHub y las comunicaciones de incidentes de Heroku son importantes porque ponen el riesgo de acceso al código fuente en el archivo público. Un cliente con repositorios conectados necesitaba saber si un atacante podía leer repositorios privados, si los repositorios tenían secretos confirmados, si existían credenciales de despliegue fuera de GitHub, si GitHub Actions, las tuberías de Heroku, las aplicaciones de revisión o los trabajos de CI exponían materiales adicionales, y si los registros de auditoría a nivel de repositorio mostraban acceso inusual.

Si el cliente usaba Travis CI, las mismas preguntas podían extenderse a las variables de entorno de CI y los registros de compilación.

NIST SP 800-218 enhttps://csrc.nist.gov/pubs/sp/800/218/finales útil porque trata el desarrollo seguro de software como un ciclo de vida, no solo como escritura de código. NIST SP 800-204D enhttps://csrc.nist.gov/pubs/sp/800/204/d/finalayuda a enmarcar las preguntas de seguridad de aplicaciones nativas de la nube e identidad de servicio. NIST SP 800-53 Rev. 5 enhttps://csrc.nist.gov/pubs/sp/800/53/r5/upd1/finalproporciona vocabulario de control para control de acceso, auditoría, configuración, respuesta a incidentes e integridad del sistema. Esos materiales no son hallazgos específicos de Heroku. Son puntos de referencia para decidir si un incidente de plataforma de desarrolladores debe revisarse como un evento de la cadena de suministro de software.

El límite clave es la prueba. Si una plataforma puede determinar que un token OAuth se usó solo para un determinado repositorio o conjunto de clientes, debe explicar la base de esa determinación. Si no puede determinar el acceso cliente por cliente debido a límites de registro, debe decirlo. Si GitHub puede notificar a los usuarios afectados basándose en el uso del token o el acceso al repositorio, el registro público debe identificar qué significa la notificación y qué no significa. Si los clientes necesitan inspeccionar sus propios registros, el proveedor debe indicar qué fuentes de registro son importantes.

El riesgo público también difiere según la madurez del cliente. Una gran empresa puede tener registros de auditoría empresarial de GitHub, escaneo centralizado de secretos, análisis de composición de software, segregación de CI/CD y personal de respuesta a incidentes. Un cliente más pequeño de Heroku puede tener una conexión simple a GitHub, uno o dos mantenedores y una retención de registros limitada. Por tanto, el mismo evento de token crea cargas diferentes. Un registro de responsabilidad maduro no asume que cada cliente puede llenar de forma independiente los vacíos de evidencia del proveedor.

Proporciona pasos prácticos para equipos pequeños y suficiente detalle técnico para que los equipos grandes automaticen la revisión.

La audiencia posterior es más amplia que los propietarios de cuentas de Heroku. Si el acceso al código fuente revela vulnerabilidades o secretos, los usuarios posteriores del software del cliente pueden verse afectados más tarde, incluso si el incidente de la plataforma original no causó un tiempo de inactividad inmediato. Eso no significa que todos los usuarios posteriores resultaran perjudicados.

Significa que el análisis de responsabilidad debe rastrear la ruta del riesgo: robo de token, posible acceso al repositorio, posible exposición de fuente o secreto, posible uso indebido de CI/CD, posible acceso a producción y posible daño posterior. Cada paso necesita evidencia antes de convertirse en una afirmación.

El momento de la notificación es parte de la superficie de control

La comunicación de incidentes a menudo se trata como una función legal o de relaciones públicas, pero para las plataformas de desarrolladores es un control operativo. Los clientes no pueden revocar tokens, rotar secretos, reconstruir integraciones o inspeccionar repositorios hasta que sepan qué hacer. Un aviso retrasado, vago o cambiante puede extender el período en que los clientes están expuestos o inseguros. Un aviso rápido pero incompleto puede crear trabajo innecesario. Por tanto, el estándar de responsabilidad no es simplemente la velocidad. Es la utilidad de la decisión en cada etapa.

La página de incidentes de Heroku enhttps://status.heroku.com/incidents/2413es útil porque las actualizaciones de estado muestran una secuencia en lugar de una única declaración final. La alerta de seguridad de GitHub proporciona otra línea de tiempo. El boletín de Travis CI proporciona una tercera. Un lector cuidadoso no debe colapsar esas líneas de tiempo en una cronología perfecta a menos que las fuentes lo respalden. La pregunta útil es cómo el aviso de cada actor cambió la acción del cliente. ¿Necesitaban los clientes revocar la autorización de la aplicación? ¿Necesitaban rotar las claves API de Heroku? ¿Necesitaban rotar las contraseñas de usuario de Heroku? ¿Necesitaban inspeccionar los repositorios de GitHub? ¿Necesitaban verificar las variables de entorno de CI? ¿Necesitaban reconstruir los enlaces de despliegue?

La respuesta puede haber cambiado a medida que surgieron los hechos. Eso es aceptable cuando los cambios se explican. Un aviso puede decir "estamos investigando un posible acceso y proporcionaremos instrucciones adicionales". Puede decir "hemos revocado tokens y los clientes deben reautorizar". Puede decir "requerimos restablecimiento de contraseña porque no podemos descartar el acceso a credenciales hash". Puede decir "no encontramos evidencia para una categoría, pero los clientes deben inspeccionar sus propios registros en busca de estos indicadores".

Lo que debilita la responsabilidad no es la incertidumbre. Lo que debilita la responsabilidad es la incertidumbre presentada como cierre.

La notificación al cliente también tiene un deber de segmentación. No todos los clientes de Heroku usaban la integración con GitHub. No todos los usuarios de GitHub autorizaron a Heroku. No todos los usuarios de Travis CI tenían el mismo alcance. No todos los repositorios contenían material sensible. Un aviso útil distingue entre grupos afectados, potencialmente afectados, no afectados y desconocidos. Si la segmentación exacta no es posible, el proveedor debe explicar por qué. Los clientes no deben tener que inferir si un mensaje les aplica a partir de titulares generales.

La calidad de la comunicación se puede medir. ¿Publicó el proveedor páginas de incidentes duraderas? ¿Incluían los mensajes fechas y marcas de tiempo? ¿Identificaban servicios afectados? ¿Proporcionaban acciones concretas para el cliente? ¿Actualizaban orientaciones anteriores cuando cambiaban? ¿Mantenían consistentes los registros directos al cliente y públicos? ¿Publicaron una revisión posterior al incidente que nombraba mejoras de control sin divulgar detalles privados explotables? Esas son preguntas de responsabilidad tanto como de comunicación.

En la economía de las herramientas de desarrollador, una comunicación poco clara transfiere el costo al cliente. Cada frase vaga se convierte en una reunión, un ticket, una búsqueda en registros, un correo electrónico al cliente o una excepción de auditoría posterior. Una plataforma puede ser legalmente cautelosa, pero una plataforma que vende confianza de desarrollador debe tratar el aviso útil para la decisión como parte del producto.

El incidente de Heroku muestra por qué las comunicaciones de incidentes necesitan disciplina de ingeniería de producto: instrucciones versionadas, audiencias segmentadas, correcciones trazables y evidencia de finalización.

La rotación forzada es un remedio solo si los clientes saben qué cambió

La rotación forzada de credenciales puede ser necesaria y seguir siendo incompleta como reparación de confianza. Un cliente puede rotar una clave API, restablecer una contraseña o reautorizar una aplicación OAuth, pero el cliente también necesita entender qué cambió en el modelo de custodia de la plataforma. Si la misma ruta de almacenamiento, diseño de alcance, brecha de monitoreo o brecha de evidencia del cliente permanece, la rotación puede restaurar el acceso sin restaurar la confianza. El registro público en torno al incidente de 2022 de Heroku colocó la rotación y la reautorización en el centro de la acción del cliente.

La cuestión de responsabilidad es si esas acciones fueron respaldadas por evidencia de control duradera.

Las páginas de Heroku Dev Center comohttps://devcenter.heroku.com/articles/oauth,https://devcenter.heroku.com/articles/platform-api-reference,https://devcenter.heroku.com/articles/heroku-cliyhttps://devcenter.heroku.com/articles/account-securitymuestran el entorno más amplio de gestión de acceso en torno al uso de la plataforma Heroku. La página de autenticación de dos factores de Heroku enhttps://devcenter.heroku.com/articles/heroku-2faproporciona contexto de endurecimiento de cuentas del lado del cliente. De nuevo, la documentación actual no es prueba del estado interno de 2022. Ayuda a los lectores a entender los tipos de credenciales y acciones de usuario que pueden rodear una cuenta de Heroku.

La rotación tiene tres capas distintas. Primero, está la revocación de tokens OAuth comprometidos para que el atacante no pueda continuar usando la autorización delegada. Segundo, está el reemplazo o reautorización del lado del cliente para que los flujos de trabajo legítimos puedan reanudarse con nuevos tokens. Tercero, está la revisión de credenciales adyacentes, incluidas claves API, contraseñas, claves de despliegue, variables de CI, secretos de repositorio, tokens de acceso personal y credenciales en la nube. Un aviso de la plataforma debe dejar claro qué capa se requiere y por qué.

La capa más difícil es la exposición de secretos en el código fuente. Si un atacante podía leer repositorios, rotar solo el token OAuth puede no ser suficiente. Los clientes pueden necesitar buscar secretos confirmados en los repositorios y rotar cualquier valor expuesto. La documentación de escaneo de secretos de GitHub enhttps://docs.github.com/en/code-security/secret-scanning/about-secret-scanningproporciona vocabulario actual para esa revisión del lado del cliente. La guía de cadena de suministro de software de CISA enhttps://www.cisa.gov/resources-tools/resources/software-supply-chain-risk-management-sscrmy los materiales de diseño seguro ayudan a explicar por qué los secretos en el código pueden convertir un evento de repositorio en un riesgo operativo más amplio.

La rotación forzada también necesita una señal de finalización. Los clientes deben saber si los tokens antiguos son inválidos, si se requiere reautorización, si las integraciones deshabilitadas permanecerán deshabilitadas hasta que se actúe, si la finalización del restablecimiento de contraseña se rastrea y si las credenciales obsoletas aún se aceptan en algún lugar. Sin una señal de finalización, cada cliente tiene que ejecutar su propia conciliación. Eso es costoso y propenso a errores.

La plataforma también necesita evidencia de finalización interna. ¿Qué cuentas de cliente completaron los pasos requeridos? ¿Qué cuentas permanecen en estado de excepción? ¿A qué clientes no se pudo contactar? ¿Qué integraciones fueron abandonadas? ¿Qué tokens no pudieron asignarse a un propietario actual? ¿Qué controles se agregaron para evitar la retención silenciosa de tokens de larga duración? Una autopsia pública puede no revelar nombres de clientes, pero puede revelar la forma de la limpieza. Esa es la diferencia entre "rotamos" y "el estado riesgoso ya no existe".

GitHub, Heroku, Travis CI, Salesforce y los clientes poseían cada uno evidencia diferente

El mapa de responsabilidad del incidente es multipartito. GitHub poseía evidencia del host fuente, visibilidad de la aplicación OAuth y la alerta de seguridad que publicó. Heroku poseía su integración de plataforma, comunicación con el cliente, custodia de tokens y programa de credenciales forzadas. Travis CI poseía su canal de integración CI/CD afectado y orientación al cliente. Salesforce poseía la gobernanza de Heroku, asignación de recursos, escalado de riesgos y el deber de hacer creíble la reparación de la plataforma.

Los clientes poseían la higiene del repositorio, la rotación de secretos, las aprobaciones organizativas de OAuth y la revisión del despliegue. Ninguno de esos roles cancela a los demás.

Esto importa porque el daño al cliente puede resultar de las brechas entre roles. Si GitHub sabe que se usó un token pero el cliente no sabe qué aplicación de Heroku se le asignó, la respuesta del cliente es más lenta. Si Heroku sabe qué cuentas usaron la integración con GitHub pero no puede decir si se accedió a los contenidos del repositorio, los clientes deben revisar de manera más amplia. Si Travis CI y Heroku comparten una alerta de GitHub pero tienen instrucciones diferentes para el cliente, las organizaciones que usan ambos deben conciliar acciones conflictivas o superpuestas.

Si Salesforce trata a Heroku como una marca subsidiaria mientras los clientes tratan a Heroku como una plataforma de producción, la gobernanza debe tender un puente sobre el límite de la marca.

Los documentos de responsabilidad compartida en la nube y SaaS a menudo dicen que las obligaciones del proveedor y del cliente difieren. El incidente de Heroku muestra que la responsabilidad compartida también requiere evidencia compartida. Un cliente no puede aceptar responsablemente la garantía de un proveedor si el proveedor no revela qué parte de la cadena cubre la garantía. Un proveedor no puede trasladar responsablemente toda la acción a los clientes si a los clientes les faltan los registros o las funciones de producto necesarias para actuar.

Un host fuente no puede asumir que las herramientas posteriores traducirán su alerta perfectamente. Cada actor debe hacer que su evidencia sea útil para el siguiente actor en la cadena.

Las fuentes de IETF, NIST, MITRE, CISA, GitHub, Heroku y Travis CI juntas forman un archivo público acotado. No revelan todos los hechos privados, pero permiten un modelo de responsabilidad claro. Los tokens OAuth deben tener un alcance limitado, almacenarse de manera defendible, revocarse rápidamente, monitorearse continuamente y asignarse al propósito comercial actual. Las plataformas de desarrolladores deben comunicar incidentes con la suficiente especificidad para que los clientes puedan actuar. Los clientes deben revisar las integraciones periódicamente en lugar de tratar la autorización como permanente.

Los hosts fuente deben poner a disposición evidencia de auditoría suficiente para que los clientes puedan distinguir entre exposición posible y acceso confirmado.

El mapa de roles también advierte contra la culpa simplista. Si un atacante roba un token, el atacante es responsable del uso indebido. Pero la responsabilidad pregunta quién podría reducir la oportunidad, el radio de explosión y la incertidumbre. El diseño de almacenamiento de tokens puede reducir la oportunidad. La minimización del alcance puede reducir el radio de explosión. La revocación rápida puede reducir la duración. Los buenos registros pueden reducir la incertidumbre. Las instrucciones claras al cliente pueden reducir el trabajo desperdiciado. La evidencia de control posterior al incidente puede reducir la recurrencia.

Esas son elecciones de diseño, no solo declaraciones posteriores a los hechos.

La evidencia verificable por el cliente es la mitad faltante de la responsabilidad compartida

El incidente de Heroku también muestra el límite del lenguaje de responsabilidad compartida cuando la evidencia es asimétrica. Una plataforma puede decir a los clientes que son responsables de la higiene del repositorio, la rotación de secretos y la revisión de aplicaciones OAuth, pero el cliente aún depende de la evidencia del proveedor para decidir dónde buscar.

Si el proveedor no puede decir si un token tenía alcance de lectura del repositorio, si se usó después de cierta fecha, si estaba vinculado a una aplicación en particular, o si existen registros específicos del cliente, entonces la responsabilidad del cliente se convierte en un ejercicio de adivinación. Un modelo de responsabilidad compartida justo proporciona a los clientes tanto deberes como evidencia utilizable.

La evidencia verificable por el cliente comienza con un inventario. Cada cliente debería poder ver qué aplicaciones de Heroku estaban conectadas a qué organizaciones, repositorios, usuarios y flujos de despliegue de GitHub. El inventario debe mostrar el estado actual, la última autorización, el alcance, el propietario, el requisito de reautorización y si la conexión fue deshabilitada por el proveedor. Sin ese mapa, un equipo de seguridad debe reconstruir la integración a partir de tickets antiguos, webhooks de repositorio, historial de despliegue y cuentas personales de desarrolladores.

Eso es exactamente el tipo de trabajo de emergencia que una plataforma debería reducir después de un evento de token del lado del proveedor.

La segunda capa de evidencia es la actividad. Los clientes necesitan saber qué registros pueden mostrar acceso al repositorio, uso de autorización OAuth, uso de clave API, actividad de cuenta de Heroku, eventos de despliegue, eventos de compilación y cambios de configuración. Si la evidencia relevante existe solo en GitHub, el proveedor debe dirigir a los clientes a los registros de auditoría de GitHub. Si la evidencia relevante existe solo en Heroku, el proveedor debe exponer una vista específica del cliente o una ruta de soporte.

Si alguna evidencia no está disponible porque el registro no se retuvo o no se recopiló, el proveedor debe decirlo claramente. "Sin evidencia de uso indebido" es útil para la decisión solo cuando los clientes saben qué evidencia se revisó.

La tercera capa es la exposición de secretos. El riesgo de acceso al repositorio no se limita al código fuente como propiedad intelectual. También incluye secretos confirmados, configuración histórica, credenciales de prueba, tokens de despliegue, claves en la nube, cadenas de conexión de bases de datos y comentarios que revelan arquitectura. Los clientes necesitan orientación que vincule el incidente de token con el escaneo y la rotación de secretos. Una respuesta sólida de la plataforma diría qué categorías son probables, qué categorías son posibles y qué categorías están fuera de la ruta conocida.

También evitaría implicar que una revocación de token por sí sola cierra el riesgo de contenido del repositorio.

La cuarta capa es la garantía de lanzamiento de software. Si un cliente usa Heroku para despliegues automáticos desde GitHub, el cliente necesita saber si el acceso no autorizado al repositorio podría haber influido en el código desplegado, los artefactos de compilación, las aplicaciones de revisión, las tuberías o el historial de lanzamientos. Eso no significa que tal influencia ocurriera. Significa que el cliente debe recibir suficiente información para probarla o refutarla.

El historial de lanzamientos, la procedencia de la compilación, las marcas de tiempo de despliegue, las firmas de commits del repositorio, las protecciones de rama y los registros de CI se convierten en parte del archivo de responsabilidad.

La quinta capa es la limpieza duradera. Un cliente debería poder saber cuándo terminó el estado sospechoso. ¿Se revocaron los tokens OAuth antiguos? ¿Se reautorizaron las integraciones con nuevos tokens? ¿Se completaron las rotaciones de contraseñas o claves API? ¿Se deshabilitaron las aplicaciones abandonadas? ¿Se eliminaron las autorizaciones personales huérfanas? ¿La plataforma evitó que la clase de token antigua permaneciera activa en algún trabajo en segundo plano o ruta heredada? La garantía del proveedor es más fuerte cuando los clientes pueden conciliar su propio estado de inquilino con la evidencia de finalización del proveedor.

Este modelo de evidencia para el cliente no requiere que un proveedor publique registros privados sensibles en la web abierta. Puede entregarse a través de paneles de cuenta, avisos directos, exportaciones de soporte, informes de incidentes empresariales o paquetes de evidencia contractual. La forma puede variar según el nivel del cliente y la sensibilidad. El principio no debe variar: cuando un proveedor pide a los clientes que actúen, también debe proporcionar la evidencia que los clientes necesitan para actuar proporcionalmente.

La adquisición y la gobernanza deben tratar las integraciones como acceso permanente

La lección de adquisición es que las integraciones OAuth son acceso permanente, no tareas de configuración únicas. Un cuestionario de riesgo de proveedor que solo pregunta si el proveedor admite cifrado, autenticación multifactor o objetivos de tiempo de actividad perderá la lección de Heroku. Las preguntas más precisas son sobre el inventario de integración, el almacenamiento de tokens, la minimización del alcance, los registros del cliente, la revocación de emergencia, las notificaciones a nivel de inquilino, el aislamiento del sistema de compilación y la prueba posterior al incidente.

Las plataformas de desarrolladores deben esperar esas preguntas porque sus productos están intencionalmente cerca de la entrega de software.

El lenguaje contractual también debe evitar transferencias de responsabilidad vagas. Un proveedor puede exigir a los clientes que protejan sus repositorios y credenciales, pero debe indicar cómo se manejarán los incidentes de integración del lado del proveedor. ¿El proveedor notificará a cada cliente que use la integración afectada? ¿Proporcionará ventanas de tiempo afectadas? ¿Identificará si se confirmó, es posible o no se observó acceso al código fuente? ¿Exigirá reautorización? ¿Expondrá eventos de auditoría? ¿Proporcionará un resumen posterior al incidente? ¿Apoyará a los clientes regulados que necesitan sus propias notificaciones?

Estos no son términos de lujo para grandes empresas. Son preguntas operativas básicas para cualquier cliente cuya cadena de suministro de software dependa de la plataforma.

La gobernanza dentro de Salesforce y Heroku también importa. El público no debe asumir que una marca subsidiaria conlleva menos responsabilidad porque está centrada en desarrolladores. Las aplicaciones de Heroku pueden ser aplicaciones de producción, herramientas internas, API públicas, prototipos que se volvieron críticos o sistemas internos que manejan flujos de trabajo sensibles. La estructura de propiedad importa porque la gobernanza determina la inversión en registro, custodia de tokens, respuesta a incidentes, soporte al cliente e ingeniería de seguridad.

Una empresa matriz no necesita divulgar cada discusión de la junta directiva para mostrar que un incidente de plataforma de desarrolladores recibió atención de control seria.

La misma cuestión de gobernanza se aplica a la gestión de productos. Un equipo de producto puede querer una integración perfecta con GitHub porque reduce la fricción y ayuda a los clientes a desplegar rápidamente. Un equipo de seguridad puede querer tokens de corta duración, alcances limitados, registros visibles para el cliente y reautorización periódica. Un equipo de soporte puede querer mensajes lo suficientemente simples para clientes pequeños. Un equipo de ventas empresariales puede querer evidencia contractual. La responsabilidad aparece donde esos incentivos se reconcilian antes de un incidente, no solo después.

Si la plataforma no puede explicar quién posee el riesgo de custodia de tokens en operaciones normales, tendrá dificultades para explicar quién lo posee durante una crisis.

Para los clientes, la respuesta práctica de gobernanza es clasificar las integraciones por consecuencia. Una integración de productividad personal es diferente de una integración de despliegue que puede leer código fuente de producción. Una aplicación de repositorio de solo lectura es diferente de una aplicación que puede crear despliegues o gestionar webhooks. Una aplicación de prueba de Heroku es diferente de una aplicación de producción orientada al cliente. Las organizaciones deben asignar una revisión, registro y recertificación más fuertes a las integraciones que pueden afectar el código de producción o los secretos.

El incidente de Heroku es un recordatorio de que "aplicación conectada" es un objeto de gobernanza, no solo una característica de conveniencia.

El resultado es un estándar de responsabilidad más maduro. Las plataformas de desarrolladores deben publicar suficiente evidencia de incidentes para que los clientes puedan completar sus propias decisiones de riesgo. Los clientes deben mantener suficiente inventario de integración para que la evidencia del proveedor pueda ser procesada rápidamente. Los hosts de código fuente deben mantener controles OAuth y de auditoría utilizables. Los proveedores de CI/CD deben separar los secretos de compilación de la confianza amplia del repositorio. Las empresas matrices deben tratar la confianza del desarrollador como confianza de producción.

El incidente de Heroku de 2022 se vuelve más que una alerta de seguridad histórica cuando se lee de esta manera. Se convierte en una prueba de si la cadena de entrega de software puede identificar el acceso permanente antes de que los atacantes obliguen a todos a mirar.

Cómo debería ser una reparación duradera después de un incidente de custodia OAuth

El estándar de reparación duradera para un incidente OAuth de plataforma de desarrolladores tiene al menos ocho partes. Primero, el proveedor debe publicar una línea de tiempo clara: detección, notificación de GitHub, investigación de Heroku, notificación al cliente, revocación de tokens, rotación de credenciales, disponibilidad de reautorización y autopsia. Segundo, debe identificar la superficie de integración afectada sin implicar que cada cliente o repositorio se vio igualmente afectado.

Tercero, debe explicar la diferencia entre tokens OAuth robados, contraseñas de cliente, claves API, claves de despliegue, secretos de repositorio y variables de CI.

Cuarto, el proveedor debe publicar las acciones del cliente en una lista de verificación que distinga pasos requeridos, recomendados y condicionales. Quinto, debe indicar qué evidencia puede ver el cliente y qué evidencia solo puede ver el proveedor o el host fuente. Sexto, debe identificar qué controles cambiaron: almacenamiento de tokens, cifrado, gestión de secretos, revisión de alcance, monitoreo, detección de anomalías, acceso de auditoría del cliente o desaprobación de integración.

Séptimo, debe proporcionar una señal de finalización, como finalización de restablecimiento forzado, finalización de revocación de tokens o aplicación de reautorización. Octavo, debe declarar claramente las incógnitas residuales.

El archivo público de Heroku contiene evidencia significativa, pero la lección de responsabilidad es más amplia que un solo incidente. Las plataformas de desarrolladores deben diseñar para días de token sospechoso antes de que ocurran. Eso significa inventario de aplicaciones OAuth, mapeo de propietarios, minimización de alcance, seguimiento de antigüedad de tokens, flujos de trabajo automatizados de revocación, plantillas de notificación al cliente, páginas de acción específicas para el cliente, exportación de registros de auditoría y recertificación periódica de integraciones.

También significa probar la experiencia del cliente de una reautorización forzada antes de una crisis. Si los clientes no pueden entender la ruta de reparación en un día tranquilo, no la entenderán durante un incidente.

Los clientes también necesitan hábitos duraderos. Deben inventariar las aplicaciones OAuth, eliminar integraciones no utilizadas, restringir la aprobación a nivel de organización, requerir revisión para aplicaciones de alto alcance, usar escaneo de secretos, evitar confirmar credenciales, rotar secretos de larga duración, conservar registros de auditoría y mapear flujos de despliegue. La documentación de GitHub y Heroku proporciona muchos de los componentes básicos, pero el trabajo de gobernanza pertenece a cada organización.

Un incidente de proveedor se vuelve más manejable cuando los clientes ya saben qué aplicaciones están conectadas a qué repositorios y sistemas de producción.

La prueba final de responsabilidad no es si la plataforma puede decir que el incidente está cerrado. Es si el cierre puede rastrearse hasta la evidencia. ¿Se invalidaron los tokens sospechosos? ¿Se notificó a los clientes afectados? ¿Se completaron los restablecimientos requeridos? ¿Se respondieron las preguntas de acceso al código fuente al nivel que la evidencia permitía? ¿Se revisaron los secretos y las credenciales de despliegue? ¿Se cambiaron los controles del producto? ¿Se preservaron las incógnitas residuales?

Un "sí" a esas preguntas es más fuerte que una declaración general de confianza porque dice a los clientes qué cambió.

Por tanto, el incidente OAuth de Heroku de 2022 pertenece a la serie de riesgo y responsabilidad de Daniel Kade porque hace visible la confianza del desarrollador. El incidente convierte un botón de integración familiar en una cuestión de custodia. Muestra que las plataformas de código fuente, las plataformas de despliegue, los proveedores de CI/CD y los clientes están conectados por autoridad delegada que sobrevive al clic del usuario.

Cuando esa autoridad es robada, la responsabilidad sigue al token: quién lo emitió, quién lo almacenó, quién podía verlo, quién lo revocó, quién advirtió a los usuarios, quién probó la reparación y quién pagó el costo mientras la prueba aún estaba incompleta.