¿Cuándo debe perder su confianza una actualización del binario de un agente?

La aprobación de un agente local debe aplicarse al ejecutable que examinaste, dentro del proceso que aprobaste y para el acceso que solicitó en ese momento. Cuando el ejecutable cambia, la aprobación anterior ha caducado en todos los sentidos prácticos, aunque conserve el mismo nombre de archivo, identificador de paquete e icono.

Esto parece estricto hasta que investigas una aprobación concedida a la versión 1.8 y utilizada discretamente por la versión 1.9. Muchas decisiones incorrectas empiezan con una comprobación de identidad demasiado amplia: una ruta, un nombre de producto o un Team ID de firma conocido. Esas comprobaciones pueden aportar evidencias. Ninguna debería mantener por sí sola una confianza privilegiada después de un cambio de código.

La confianza pertenece al ejecutable observado

Un agente local no es la identidad de un editor. Es un programa firmado concreto, cargado desde una ruta determinada, con un proceso padre, argumentos, entorno y conjunto de acciones solicitadas específicos. Un editor puede publicar muchos programas. Un mismo programa puede cambiar sustancialmente entre versiones. Un nombre estable no dice casi nada sobre ninguno de esos hechos.

Esta diferencia importa especialmente cuando el agente puede llamar a API de pago, usar credenciales SSH, modificar un repositorio o enviar datos fuera del equipo. Una aprobación no es un elogio al proveedor. Es permiso para que un proceso realice acciones con consecuencias.

Mantén separadas estas identidades:

• La identidad del archivo es el código firmado y su resumen en el disco.
• La identidad de firma es la autoridad que macOS informa para ese código.
• La procedencia del editor es la evidencia de que el archivo llegó por la ruta de publicación prevista.
• La identidad de ejecución incluye el proceso que lo inició y el acceso que solicita.

Los equipos suelen juntar las cuatro bajo la frase «este es nuestro agente». Así, un reemplazo en la misma ruta hereda un acceso que nunca se ganó. La regla segura es sencilla: el reemplazo de un ejecutable inicia una decisión de confianza nueva.

Un hash detecta un reemplazo, pero no indica quién firmó el reemplazo. Una firma identifica al firmante, pero no demuestra cuál fue el canal de descarga. Una descarga limpia no indica si la versión nueva necesita un acceso más amplio. Necesitas las tres comprobaciones porque cada una detecta un fallo distinto.

No cometas el error contrario de fijar cada byte para siempre. Las compilaciones cambian legítimamente, los certificados se renuevan y las versiones necesitan actualizaciones. El objetivo no es la permanencia. Es que alguien vea el cambio, establezca qué cambió y decida de forma explícita si la autoridad solicitada sigue teniendo sentido.

La firma de código responde a una pregunta más limitada de lo que muchos creen

La firma de código de macOS permite al sistema operativo verificar que el código firmado no ha cambiado desde que el firmante produjo esa firma. En la distribución mediante Developer ID, Gatekeeper también evalúa la identidad del desarrollador y su valoración del elemento. Es una evidencia útil, pero no un veredicto completo sobre la cadena de suministro.

La Nota Técnica TN2206 de Apple, «macOS Code Signing In Depth», separa la identidad del código de las condiciones más amplias bajo las que el sistema acepta el código. Su explicación de los requisitos designados es especialmente relevante: macOS puede usar un requisito para reconocer una versión futura como perteneciente a la misma identidad de código. Esa continuidad ayuda con las actualizaciones normales de aplicaciones. Es demasiado débil como única condición para un agente que puede gastar dinero o usar infraestructura privada.

Una firma válida no responde a estas preguntas:

• ¿El editor tenía la intención de que esta versión exacta llegara a tu equipo?
• ¿La firmó una credencial de publicación del editor que había sido comprometida?
• ¿La versión nueva añadió una capacidad que cambia su riesgo?
• ¿Un instalador, actualizador o script de lanzamiento reemplazó un componente sin cambiar la parte que comprobaste?

Gatekeeper y la notarización reducen la probabilidad de que macOS ejecute software claramente no confiable. No convierten un agente firmado de forma válida en un titular aprobado de tu autoridad operativa. Trata la admisión del sistema operativo y la aprobación de acciones privilegiadas como decisiones separadas.

Lo mismo se aplica a la renovación de un certificado. Un certificado renovado puede ser un trámite administrativo normal. Aun así, cambia las evidencias en las que te basas. Si el Team ID, el identificador y la ruta de publicación prevista siguen siendo coherentes, un operador puede aprobar la actualización después de revisarla. Si la autoridad de firma pasa a otra organización, detente y busca una explicación clara del editor. No aceptes un cambio de identidad inesperado solo porque la aplicación se inicia sin mostrar una advertencia.

La procedencia del editor es independiente de la firma

La procedencia pregunta cómo llegó el binario hasta ti y si esa ruta coincide con la práctica habitual de publicación del editor. La firma de un archivo copiado desde un adjunto desconocido de un chat te dice quién firmó esa copia. No explica por qué la recibiste allí.

Para un agente de producción, guarda un pequeño comprobante de versión cuando lo instales o actualices. Puede ser un archivo de texto en el repositorio que administra el agente, un registro de cambios o una entrada en un registro interno de versiones. El comprobante debe incluir la versión, el origen de instalación, la autoridad de firma observada, el Team ID, el resumen, la fecha de revisión y la persona que lo aceptó. Si el editor proporciona un resumen de la versión, guárdalo también.

El canal de publicación merece una comprobación de sentido común. ¿El actualizador procede de la aplicación esperada? ¿El editor publicó notas de versión para esta versión? ¿Coinciden el nombre del archivo, la firma del paquete y la ruta de destino con el método de instalación habitual? Una actualización inesperada distribuida por un canal nuevo merece la misma sospecha que un firmante inesperado.

No confundas un repositorio público de código fuente con un artefacto de publicación. Un repositorio puede mostrar el historial del código mientras el proceso de publicación compila un binario diferente. A la inversa, un binario firmado puede ser legítimo aunque no puedas reproducir su compilación. Son niveles de garantía distintos. Indica qué nivel tienes en vez de fingir que uno demuestra el otro.

Comparar resúmenes ayuda cuando el editor te proporciona una suma de comprobación autenticada. No ayuda si copias el resumen y el binario de la misma página no confiable. La comparación útil procede de un registro de publicación independiente controlado por el editor, de un registro de un gestor de paquetes confiable o de un origen interno establecido previamente.

El acceso solicitado debe revisarse junto con la actualización

Una actualización binaria puede conservar la misma autoridad de firma y aun así merecer menos acceso que la versión anterior. La razón de la revisión no es solo el miedo al código malicioso. Un comportamiento nuevo puede hacer que un permiso anterior deje de ser razonable.

Pregunta qué acciones externas realizará el proceso después de la actualización. Un agente que antes leía metadatos de incidencias puede ahora crear solicitudes de incorporación de cambios. Uno que usaba un token de prueba desechable puede empezar a ejecutar comandos SSH en un host compartido. Un plugin nuevo, un formato de configuración modificado o un comando predeterminado diferente pueden cambiar el alcance práctico del proceso sin solicitar un derecho nuevo al sistema operativo.

La revisión del acceso solicitado debe cubrir el límite real de las acciones:

• ¿Qué hosts HTTP, ámbitos de cuenta y registros de credenciales usará el proceso?
• ¿A qué destinos SSH y comandos remotos puede llegar?
• ¿Qué directorio de trabajo, hooks del repositorio, argumentos y variables de entorno lo inician?
• ¿Recibe ahora entradas de un origen diferente, como un comentario de una solicitud de incorporación de cambios o un registro de compilación?
• ¿Puede invocar otro ejecutable local que no formara parte de la revisión anterior?

Aquí es donde falla la aprobación permanente y amplia. Una decisión como «permitir este agente» oculta la parte importante: ¿permitirle hacer qué, con la credencial de quién y en respuesta a qué entrada?

En los procesos de agentes, la procedencia de las entradas merece la misma atención. Una actualización que permite a un agente de programación actuar sobre texto no confiable de una incidencia puede convertir el acceso normal al repositorio en una vía para la inyección de instrucciones. La firma de código no inspecciona las instrucciones que recibe el proceso. Solo cubre el programa que las interpreta.

Mantén concretas las pantallas de aprobación y los registros internos. Indica la autoridad del proceso, el destino, la clase de credencial y si la acción cambia el estado remoto. Un operador no puede tomar una decisión sólida ante una alerta que solo diga «El agente solicita acceso».

Termina la sesión anterior antes de que actúe el código nuevo

La regla más limpia es vincular la aprobación a un único proceso en ejecución y terminarla cuando ese proceso salga. Un binario de reemplazo crea un proceso nuevo, por lo que obtiene una aprobación nueva. Así evitas el frágil intento de decidir qué actualización de paquete es lo bastante pequeña como para heredar una concesión anterior.

No permitas que un proceso se actualice en el mismo lugar y continúe usando la autorización que obtuvo antes del reemplazo. Algunos actualizadores hacen exactamente eso: el proceso anterior descarga un archivo, escribe un ejecutable nuevo sobre la ruta anterior y luego inicia una utilidad auxiliar o se vuelve a ejecutar. Si la capa de autorización solo comprueba una ruta o un registro de cliente de larga duración, el código nuevo continúa bajo la decisión anterior.

Un registro práctico de decisión puede tener este aspecto:

process path: /Users/dev/tools/agent/bin/agent
observed digest: 8a4b...e19c
identifier: dev.example.agent
TeamIdentifier: A1B2C3D4E5
parent: interactive shell in approved repository
requested actions: issue API read, test-host SSH command
approval scope: this process only
expires: process exit

No trates el resumen como una entrada permanente de una lista de permitidos. Guárdalo para poder saber que la siguiente aprobación se refiere a un código diferente. Cuando el proceso se reinicie después de una actualización, compara la observación nueva con la anterior y muestra al operador las diferencias importantes.

Un reinicio de la misma versión también puede requerir revisión cuando cambia su contexto de lanzamiento. Un binario iniciado por un shell interactivo dentro de un repositorio comprobado no equivale al mismo binario iniciado sin supervisión por una tarea de compilación con un entorno más amplio. El ejecutable es una parte del sujeto. El contexto del proceso lo completa.

Inspecciona las evidencias de macOS antes de aprobar un reemplazo

Puedes inspeccionar un ejecutable candidato con las herramientas integradas de macOS antes de permitirle realizar una llamada privilegiada. Ejecuta los comandos sobre el ejecutable que se iniciará, no sobre una copia con nombre parecido en Descargas ni sobre un paquete de aplicación externo que supongas que lo contiene.

codesign -d -vvv /Users/dev/tools/agent/bin/agent 2>&1
spctl -a -t exec -vv /Users/dev/tools/agent/bin/agent
shasum -a 256 /Users/dev/tools/agent/bin/agent

La salida habitual de codesign incluye campos parecidos a estos:

Identifier=dev.example.agent
Authority=Developer ID Application: Example Publisher (A1B2C3D4E5)
TeamIdentifier=A1B2C3D4E5
CDHash=8a4b9c0d...

spctl informa de su evaluación y suele mostrar un origen para el software Developer ID aceptado. shasum imprime un resumen SHA-256 completo seguido de la ruta. Guarda la salida relevante junto con el comprobante de versión. El texto exacto varía según la versión de macOS, así que compara los campos de identidad y la evaluación, no los espacios ni el orden de los campos.

En una aplicación empaquetada, inspecciona también el código anidado. Un paquete externo firmado puede contener utilidades auxiliares, frameworks o herramientas de línea de comandos. Si el agente inicia directamente una utilidad auxiliar, inspecciona esa utilidad directamente. El archivo que solicita el acceso es el archivo cuya identidad debes vincular a la decisión.

Una verificación correcta de codesign no significa que un ejecutable esté notarizado ni que sea adecuado para tu uso. Significa que la firma se comprueba según las reglas de verificación del comando. Conviene conservar esa diferencia en las notas de incidentes. De lo contrario, alguien puede leer más tarde «firma válida» como «versión revisada y aprobada», que es una afirmación mucho más amplia.

Una ruta estable facilita aprobar el código equivocado

Imagina un wrapper local en /Users/dev/bin/agent. Un desarrollador lo aprueba una vez porque llama a una API de proyecto de solo lectura. Más tarde, el wrapper ejecuta una actualización automática, descarga una utilidad auxiliar nueva y conserva la misma ruta. El componente de aprobación reconoce la ruta y concede a la utilidad nueva el permiso anterior.

Nada de esta secuencia requiere un atacante malicioso. La versión puede ser auténtica. El problema es que el registro de aprobación dice «la ruta coincide con la ruta permitida», mientras que la decisión real se tomó sobre un programa anterior con un comportamiento más limitado.

El fallo empeora cuando el propio wrapper es un script. Los scripts de shell suelen invocar binarios versionados bajo un enlace simbólico estable, leer configuración de un directorio modificable o elegir una utilidad desde PATH. Comprobar la firma del wrapper dice muy poco sobre el ejecutable final si el wrapper puede redirigir la ejecución después de la comprobación.

Corrige el orden de las operaciones. Resuelve el ejecutable final. Inspecciona su firma y su resumen. Captura el proceso padre y los argumentos. Después, autoriza ese proceso en ejecución. Si un lanzador puede reemplazar o seleccionar otro ejecutable después de la aprobación, vincula la puerta de acciones al proceso que observa en el momento de la conexión y rechaza cualquier discrepancia.

La alternativa habitual es heredar automáticamente la aprobación para cualquier actualización firmada con el mismo Team ID. Los equipos la eligen porque las solicitudes molestan a los desarrolladores y los certificados de publicación suelen mantenerse estables. Es incorrecta para agentes privilegiados porque trata una credencial del editor como un cheque en blanco para cualquier comportamiento futuro. Reduce la fatiga de las solicitudes con aprobaciones limitadas a la sesión, acceso restringido y avisos claros de actualización, no haciendo invisibles las actualizaciones.

Los cambios de editor necesitan un registro explícito de migración

Un cambio de autoridad de firma puede ser legítimo. Las empresas adquieren productos, pasan a otra cuenta de Developer ID o sustituyen un proceso de distribución antiguo. Trata esos sucesos como migraciones, no como actualizaciones rutinarias.

Exige un registro explícito que indique la identidad anterior, la nueva, la versión en la que se produjo el cambio y las evidencias usadas para aceptarlo. Entre las buenas evidencias están un anuncio firmado en el canal de publicación habitual del editor, notas de versión coincidentes en el repositorio esperado y un paquete obtenido por la ruta normal de distribución. Una ventana emergente sin explicación no es una evidencia.

Un Team ID cambiado debe denegarse por defecto hasta que alguien revise la migración. Un certificado cambiado bajo el mismo Team ID puede pasar a una aprobación nueva después de la revisión habitual de procedencia y acceso. Un resumen cambiado con el mismo certificado también necesita una aprobación nueva porque es código nuevo, aunque todos los demás campos coincidan.

No concedas una excepción amplia como «aceptar todas las identidades futuras para este nombre de aplicación». Esa excepción convierte una migración puntual en un agujero permanente. Guarda la identidad nueva solo después de que el revisor acepte una versión concreta. El siguiente cambio debe activar la misma revisión.

Si tu equipo distribuye agentes internos, publica la identidad de firma esperada, el resumen de la versión y el procedimiento de actualización en un lugar que los operadores puedan consultar sin depender del propio agente. Un agente no puede dar fe de forma creíble de su propio reemplazo mientras ese reemplazo sea el objeto de la revisión.

Un protocolo pequeño de aprobación supera a una lista enorme de excepciones

No necesitas un motor de reglas complicado para que las decisiones de actualización sean previsibles. Necesitas un protocolo breve que se aplique cada vez que cambie el ejecutable.

1. Detén el proceso anterior y revoca su sesión activa.
2. Resuelve el ejecutable final que realizará la conexión o la acción.
3. Compara su resumen, identificador, autoridad de firma y Team ID con el comprobante de la versión anterior.
4. Comprueba el canal de publicación esperado y registra el motivo de cualquier cambio de identidad.
5. Revisa los destinos y las credenciales solicitados; después, aprueba la sesión del proceso nuevo o deniégala.

Este protocolo separa una actualización normal de mantenimiento de una anomalía real. Un resumen nuevo con la misma autoridad y una procedencia de publicación normal es un evento de revisión, no una emergencia. Una autoridad desconocida, un instalador inesperado y una solicitud de una credencial SSH de producción deben detener el despliegue hasta que alguien investigue.

La autorización de sesiones de Sallyport puede hacer visible el límite del proceso porque identifica un proceso nuevo del agente antes de permitir su ejecución, mientras que su configuración de aprobación por llamada puede mantener las credenciales sensibles bajo una decisión más estricta. Esto no elimina la necesidad de inspeccionar un agente actualizado, pero evita que una ejecución anterior preste silenciosamente su aprobación a otra posterior.

Mantén el registro lo bastante breve como para que la gente lo mantenga. Las evidencias útiles son el archivo observado, su firmante, su origen, su contexto de lanzamiento y las acciones aprobadas. Si una versión cambia cualquiera de esos elementos, haz que la persona responsable del riesgo vea el cambio antes de que actúe el agente.

Los registros de auditoría deben distinguir al actor del editor

Un registro de auditoría que solo diga «el agente usó una credencial» complica innecesariamente la revisión posterior a un incidente. Registra qué proceso realizó la solicitud, qué autoridad de firma informó macOS, qué sesión la autorizó y qué acción ocurrió realmente. La identidad del editor explica quién firmó el código. El registro del proceso explica quién actuó.

Esta diferencia importa cuando una ejecución del agente sale mal. Necesitas saber si una versión nueva cambió el comportamiento, si un binario antiguo se ejecutó desde una ubicación inesperada, si una persona aprobó una solicitud de acceso distinta de la que creía o si una entrada no confiable dirigió un proceso que por lo demás era el esperado. Un campo del editor por sí solo no puede responder a esas preguntas.

Mantén la integridad separada de la legibilidad. Un registro resistente a manipulaciones puede establecer si se modificaron entradas anteriores. No puede crear después del incidente los hechos que faltan. Captura el resumen del ejecutable y el contexto de la decisión en el momento de la aprobación, cuando todavía puedes observarlos.

Sallyport proyecta sus diarios de sesiones y actividad desde un único registro de auditoría cifrado y encadenado mediante hashes, y sp audit verify puede comprobar esa cadena sin conexión sobre el texto cifrado. Usa ese tipo de evidencia para verificar el registro y combínala con un comprobante de versión que explique por qué el ejecutable recibió acceso en primer lugar.

El primer cambio operativo que haría sería eliminar cualquier regla de aprobación que solo coincida con una ruta, un nombre visible o un editor. Sustitúyela por la aprobación del proceso actual, haz que caduque al salir del proceso y exige una decisión nueva después de reemplazar un binario. Ese límite detecta la ruta de actualización que las listas de permitidos amplias suelen pasar por alto.