He publicado una clave API en GitHub: qué hacer además de borrar el archivo
Borrar la línea no invalida una credencial que alguien pudo copiar. La prioridad es contener su uso, revisar actividad y restaurar la integración de forma controlada.
Si una clave API real se publica en un repositorio, quitarla del archivo no impide que se siga utilizando. Hay que tratarla como potencialmente expuesta, contener su capacidad de acceso y revisar qué ocurrió. La limpieza del código es necesaria, pero no reemplaza la revocación de la credencial.
Confirmar qué se expuso sin volver a compartirlo
Identifica proveedor, cuenta, permisos y aplicación que utiliza la clave. No la pegues en chats, incidencias o capturas para pedir ayuda. Comunica una referencia segura que permita al responsable localizarla en su panel.
Comprueba si era una credencial real, un ejemplo inerte o un valor ya invalidado. Mientras no se confirme, no supongas que la ausencia de una alerta significa ausencia de exposición. También puede haberse incluido en artefactos, registros de construcción o comentarios.
Contener primero la capacidad de uso
La documentación de GitHub sobre secretos recomienda rotar las credenciales afectadas. Sus mecanismos pueden detectar distintos tipos de secretos en el historial y otras superficies, pero la cobertura depende del caso y la configuración.
Acude al proveedor que emitió la clave para revocar o sustituirla con autorización. Si otorga acceso peligroso, no mantengas una credencial expuesta solo para evitar unos minutos de interrupción: evalúa la contención con el responsable del servicio y deja constancia de la decisión.
Revisar uso, permisos y consecuencias
Consulta la actividad disponible desde el momento estimado de exposición y conserva evidencias con acceso restringido. Busca operaciones no reconocidas, cambios de configuración y consumo inesperado, sin afirmar que cada petición extraña es una intrusión confirmada.
El alcance depende de los permisos: una clave de lectura y otra capaz de emitir pagos no tienen las mismas consecuencias. Si podría haberse accedido a datos personales o creado otros accesos, puede ser necesaria ayuda especializada y una evaluación de obligaciones aplicables.
Recuperar la integración con una credencial limitada
Emite el sustituto con los permisos necesarios, configúralo en el mecanismo seguro del despliegue y comprueba el recorrido real. Evita copiarlo directamente al código o a una imagen que vaya a distribuirse.
Valida también workers, tareas programadas y entornos secundarios autorizados. Un proceso antiguo puede conservar la clave revocada y fallar horas después. La guía para renovar una clave antes de retirar la anterior describe la rotación planificada; una filtración requiere priorizar contención, no seguir ese orden a ciegas.
Limpiar el repositorio sin prometer borrado total
Retira el secreto del estado actual y evalúa si es necesario sanear el historial. Coordina cualquier reescritura con colaboradores. No anuncies que ese trabajo borra clones, copias o información ya descargada por terceros.
Revisa además archivos generados y configuración del proceso que originó la publicación. Añadir una exclusión evita algunas repeticiones, pero no corrige por sí sola un historial que ya contiene el valor.
Documentar el cierre y prevenir recurrencias
Conserva referencia de la credencial invalidada, hora, pruebas y revisión de actividad. Activa controles de detección y protección disponibles para tu repositorio y limita permisos por entorno. Ningún detector reconoce todos los secretos posibles.
Podemos ayudar a mantener la aplicación y revisar vulnerabilidades dentro de un alcance acordado. Si hay indicios de compromiso, el trabajo debe tratarse como un posible incidente y no cerrarse con un simple cambio de contraseña.