Cómo verificar una aplicación de macOS descargada antes del primer inicio

Una aplicación de seguridad obtiene acceso inusual por diseño. Puede leer el tráfico de red, añadir una extensión del sistema, instalar un asistente con privilegios, inspeccionar archivos o solicitar permisos de grabación de pantalla y accesibilidad. Tratar su primer inicio como una instalación normal es un error evitable.

Una revisión adecuada no exige aplicar ingeniería inversa a todo el producto. Exige comprobar que obtuviste el artefacto correcto, que la identidad de su editor es la que esperabas, que su contenido sigue coincidiendo con la versión firmada y que macOS lo acepta con sus protecciones habituales. Hazlo antes de que la aplicación reciba permisos, credenciales o una contraseña de administrador.

Esta revisión es deliberadamente repetitiva. Esa es su fortaleza. Un ritual único basado en la advertencia que macOS decida mostrar es fácil de eludir. Un registro breve de las mismas comprobaciones para cada nueva aplicación de seguridad es más difícil de engañar y más sencillo de entregar a otro ingeniero.

El nombre del archivo no es el editor

Un archivo llamado Acme Security.app no te dice casi nada. Un icono copiado, un nombre de producto conocido y una página de descarga cuidada son fáciles de imitar. La identidad que necesitas establecer es la que contiene la firma. Después debes compararla con información obtenida por separado del editor.

Empieza por el origen. Da preferencia a la propia página de versiones del editor o a una ubicación de versiones que el editor indique en su documentación. Evita los agregadores de descargas, los espejos de archivos y los enlaces compartidos en un chat cuando puedas obtener la versión original. Si un compañero te envía el archivo, pregúntale dónde lo obtuvo en lugar de considerar su posesión como prueba de procedencia.

Aquí hay dos preguntas distintas:

• ¿Llegó este archivo desde el lugar que pretendía usar?
• ¿Coincide el editor que firmó este ejecutable con el editor en el que pretendía confiar?

A menudo se mezclan ambas preguntas. Así, una página de descarga de un proveedor comprometida puede superar una revisión superficial, y una aplicación con un Developer ID válido de Apple puede ganarse la confianza solo porque su nombre se parece al de un proveedor conocido.

Crea una expectativa antes de inspeccionar el archivo. Registra el nombre del producto, la versión, el tipo de archivo esperado, el nombre del editor y cualquier Team Identifier o dato del certificado de firma publicado. Si el proveedor nunca ha publicado un identificador estable, usa varias señales independientes: su documentación, su repositorio de código, una versión anterior en la que ya confíes y una respuesta de soporte de un contacto conocido. El nombre del sujeto del certificado por sí solo no basta si no tienes un motivo previo para asociarlo con el proveedor.

En una aplicación que afirma proteger otro software, espero que el editor facilite esta información. Un proveedor que te pide desactivar Gatekeeper, ejecutar un pipe de curl en un shell o ignorar una discrepancia sin una explicación precisa ya ha suspendido la revisión de instalación.

Verifica el artefacto descargado antes de abrirlo

Comprueba el contenedor descargado antes de arrastrar una aplicación a Applications o ejecutar un instalador. El contenedor determina qué comandos son relevantes y qué puede ocurrir después.

Un .dmg es una imagen de disco. Montarla muestra su contenido, pero no debería iniciar por sí sola la aplicación incluida. Un .pkg es un paquete de instalación y puede modificar el sistema cuando autorizas a Installer. Un .zip es un archivo comprimido que normalmente se expande en un paquete de aplicación u otro contenedor. Un .app independiente ya es un paquete de aplicación.

Conserva intacta la descarga original hasta que termine la revisión. Finder suele expandir automáticamente los archivos ZIP, lo cual resulta práctico, pero facilita perder de vista el artefacto exacto cuyo hash publicó el proveedor. Si el editor proporciona un checksum SHA-256 del ZIP, verifica el ZIP antes de extraerlo. Si proporciona un checksum de la imagen de disco, verifica la imagen antes de montarla.

En Terminal, usa una ruta entre comillas. Al arrastrar un archivo desde Finder hasta Terminal, la ruta se inserta de forma segura.

shasum -a 256 \"$HOME/Downloads/VendorSecurity.dmg\"

La salida tiene este formato:

9fd1...e84c  /Users/you/Downloads/VendorSecurity.dmg

Compara los 64 caracteres hexadecimales con el valor del editor. No compares solo los primeros caracteres y des por terminada la comprobación.

Un checksum solo es una prueba sólida cuando obtienes el resumen esperado por una vía distinta de la del archivo descargado. La mejor disposición sencilla es un instalador de la página de versiones del proveedor y un checksum en una nota de versión firmada, una versión de un repositorio de código o una página de seguridad mantenida por separado. Un hash impreso junto al botón de descarga todavía detecta una corrupción accidental, pero no te protege si un atacante controla esa página y el archivo.

Si el proveedor no publica ningún checksum, no inventes certezas. Continúa con las comprobaciones de firma y notarización y concede más importancia a la verificación del editor. Si la aplicación tiene consecuencias importantes para tu entorno, pide al proveedor un resumen firmado o un manifiesto de versión. Es una petición razonable.

Para una imagen de disco, también puedes pedir a macOS que valide su estructura interna:

hdiutil verify \"$HOME/Downloads/VendorSecurity.dmg\"

Una verificación correcta indica que la estructura de la imagen y sus bloques de checksum son coherentes internamente. No identifica al editor ni sustituye al resumen SHA-256 proporcionado por el proveedor.

Una firma válida demuestra integridad, no criterio

La firma de código responde a una pregunta concreta y útil: ¿ha cambiado el paquete firmado desde que su firmante lo aprobó? También muestra la cadena de firma y el Team Identifier. No te dice si la aplicación está bien diseñada, si el editor merece tu confianza ni si el acceso que solicita es razonable.

Después de montar la imagen de disco o expandir el archivo, inspecciona directamente el paquete de la aplicación. Este comando verifica la firma del código y comprueba el código firmado anidado dentro del paquete:

codesign --verify --deep --strict --verbose=4 \"/Volumes/Vendor Security/Vendor Security.app\"

Si todo va bien, suele producir poca salida. El resultado está en el estado de salida de Terminal, así que volver silenciosamente al prompt después de este comando es normal. Si falla, codesign identifica un archivo modificado, una firma no válida o un componente anidado que no supera la validación.

Después muestra los datos de firma:

codesign -dvvv \"/Volumes/Vendor Security/Vendor Security.app\" 2\u003e\u00261 | \\\n  egrep \"^(Identifier|TeamIdentifier|Authority|Timestamp)=\"

La salida debería parecerse aproximadamente a esta:

Identifier=com.vendor.security
TeamIdentifier=ABCDE12345
Authority=Developer ID Application: Vendor, Inc. (ABCDE12345)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Jan 16, 2026 at 14:32:09

El nombre real del proveedor, el identificador del paquete y el Team Identifier deben coincidir con lo que esperabas. Anota el Team Identifier. Es mucho más estable y preciso que el icono o el nombre visible de una aplicación, y te proporciona algo concreto que comparar cuando el proveedor publique una actualización.

No interpretes demasiado la palabra Authority. Una firma Developer ID significa que Apple emitió el certificado a un desarrollador registrado y que el código se valida mediante esa cadena. No significa que Apple recomiende el producto. La propia documentación de Apple deja clara la distinción relacionada: la notarización es una comprobación automatizada de malware y firma, no una revisión de la aplicación.

La guía de Apple sobre firma de código también advierte a los desarrolladores que no utilicen codesign --deep para firmar software complejo, porque aplica las opciones de forma demasiado amplia. Esa advertencia se refiere a la creación de firmas. Para un usuario que realiza una comprobación, --deep resulta útil porque pide a codesign que valide el código anidado. Aun así, no inspecciona cada script ni archivo de configuración en busca de intenciones maliciosas.

Si la aplicación contiene un asistente, una herramienta de línea de comandos o una extensión, la verificación del paquete es la primera revisión, no la última palabra. La revisión del primer inicio, más adelante en este artículo, es donde comparas esos componentes con lo que la aplicación dice necesitar.

La evaluación de Gatekeeper comprueba la versión que macOS ejecutará

Ejecuta una evaluación de Gatekeeper sobre la aplicación incluso cuando la firma parezca correcta. spctl evalúa el elemento según la política del sistema que importa en el momento de la ejecución. Se acerca más a la pregunta: «¿Aceptará este Mac esta aplicación con las protecciones habituales?»

Usa:

spctl --assess --type execute --verbose=4 \\\n  \"/Volumes/Vendor Security/Vendor Security.app\"

Un resultado correcto suele incluir líneas como estas:

/Volumes/Vendor Security/Vendor Security.app: accepted
source=Notarized Developer ID
origin=Vendor, Inc. (ABCDE12345)

La redacción exacta varía según la versión de macOS. Lo que buscas es una evaluación aceptada, un origen Developer ID notarizado cuando se trate de una descarga directa y un editor que reconozcas.

Esta comprobación detecta un error que un checksum no puede detectar: podrías haber descargado un archivo sin modificar del editor equivocado. También detecta otro error que una inspección del certificado por sí sola puede pasar por alto: una aplicación firmada correctamente puede no cumplir la política actual de Gatekeeper.

Apple describe Gatekeeper como un sistema que comprueba si el software descargado tiene un desarrollador identificado, está notarizado y ha sido alterado. Es una red de seguridad útil, pero sigue siendo una evaluación de política realizada por el sistema operativo. Debe apoyar tu decisión, no sustituirla cuando valores si el editor y los privilegios solicitados tienen sentido.

No suprimas una evaluación fallida eliminando atributos o usando una excepción de Finder antes de entender el motivo. Conserva el texto del fallo en tus notas de revisión. Un certificado revocado, una firma caducada o malformada, un resultado de notarización ausente y una restricción administrada por la organización requieren respuestas distintas. Tratar todas las advertencias como una molestia genérica es la forma en que las excepciones se convierten en el procedimiento normal de instalación.

Un ticket adjunto ayuda, pero no es toda la comprobación de notarización

La notarización y el stapling están relacionados, pero son cosas distintas. La notarización significa que el servicio de notarización de Apple procesó el software enviado y emitió un ticket después de sus comprobaciones automatizadas. El stapling adjunta ese ticket a una aplicación, imagen de disco o paquete de instalación. Gatekeeper también puede localizar un ticket en línea.

Si tienes instaladas las herramientas de línea de comandos de Xcode, comprueba si hay un ticket adjunto:

xcrun stapler validate \"/Volumes/Vendor Security/Vendor Security.app\"

Una validación correcta confirma que el ticket está físicamente adjunto a ese paquete. Es útil para un portátil que podría iniciar la aplicación por primera vez sin conexión de red.

No rechaces una aplicación solo porque este comando indique que no hay ningún ticket adjunto. Apple documenta que Gatekeeper puede encontrar un ticket de notarización en línea, incluso si el usuario descargó la aplicación antes de que terminara la notarización. Un archivo ZIP tampoco puede contener por sí mismo un ticket adjunto. El editor debe adjuntar el ticket a los elementos que contiene y después crear un archivo nuevo.

Usa las comprobaciones en este orden:

1. Verifica el resumen SHA-256 cuando exista un resumen publicado de forma independiente.
2. Verifica la firma de la aplicación e inspecciona su Team Identifier.
3. Ejecuta la evaluación de Gatekeeper.
4. Valida un ticket adjunto si la herramienta está disponible y el primer inicio sin conexión es importante.

Mantén el Mac conectado a Internet durante el primer inicio normal, salvo que el editor documente expresamente un proceso de despliegue sin conexión. Así Gatekeeper podrá realizar sus consultas habituales en línea, incluidas las comprobaciones del estado del certificado. No interpretes un ticket adjunto como una promesa de que la aplicación siempre seguirá siendo aceptable si su identidad de firma se revoca más adelante.

La notarización tiene límites que conviene expresar claramente. No es una auditoría completa del comportamiento de la aplicación. No confirma que el servicio en la nube de una aplicación gestione los datos de forma segura, que su sistema de actualizaciones sea sólido ni que una nueva versión solicite solo permisos razonables. Indica que el artefacto enviado superó el proceso automatizado de Apple y proporciona a Gatekeeper un ticket con el que trabajar.

La cuarentena aporta información sobre el origen, así que déjala intacta

El atributo extendido com.apple.quarantine registra que macOS recibió un elemento a través de un canal que lo marcó como descargado o transferido. Ayuda a Gatekeeper a saber que se trata de un primer inicio que merece una comprobación. No es una etiqueta de malware.

Inspecciona los atributos con:

xattr -l \"/Volumes/Vendor Security/Vendor Security.app\"

En un elemento descargado, puede aparecer una salida que contenga:

com.apple.quarantine: 0083;...;Safari;...

Las marcas y el formato de la fecha son detalles de implementación. La conclusión útil es que el elemento conserva información sobre su procedencia como descarga. Una aplicación no es sospechosa solo por tener este atributo. La mayoría de las descargas realizadas desde un navegador deberían conservarlo.

La ausencia de cuarentena tampoco hace segura una aplicación. Los archivos pueden perder atributos extendidos al pasar por herramientas de archivado, recursos compartidos de red, medios extraíbles o una copia realizada por un compañero. Apple también indica que macOS comprueba si el software contiene contenido malicioso conocido en el primer inicio, independientemente de cómo haya llegado. En la práctica, conservar la procedencia proporciona más contexto a Gatekeeper y a tu proceso de revisión.

La solución habitual para una aplicación que no se abre es esta:

xattr -dr com.apple.quarantine \"/Applications/Vendor Security.app\"

No conviertas ese comando en parte del procedimiento normal de instalación. Elimina una señal de control porque no te gusta el resultado de ese control. No repara una firma dañada, no establece la identidad del editor ni hace más segura una aplicación sin notarizar. Si las instrucciones publicadas por un proveedor exigen ese comando, detente y averigua por qué no puede distribuir una versión que Gatekeeper acepte.

Un Mac administrado puede aplicar reglas más estrictas mediante la gestión de dispositivos. En ese caso, una excepción podría no estar disponible o estar prohibida por un buen motivo. Pide al administrador la vía establecida por la política en lugar de tratar la restricción como un acertijo técnico.

Los paquetes necesitan su propia inspección antes de que Installer pida una contraseña

Un .pkg merece más cautela que un paquete de aplicación porque Apple's Installer puede escribir fuera de tu carpeta de usuario después de que lo autorices. Los productos de seguridad a veces necesitan paquetes para instalar un asistente con privilegios, una extensión del sistema, un filtro de red o componentes de apoyo. Puede ser legítimo. Aun así, es una acción importante.

Comprueba la información de firma de un paquete antes de hacer doble clic:

pkgutil --check-signature \"$HOME/Downloads/VendorSecurity.pkg\"

Un resultado típico identifica si el paquete está firmado, el certificado Developer ID Installer y la cadena de certificados. Compara el nombre del proveedor y el Team Identifier, cuando esté disponible, con la identidad que registraste para la aplicación o con el material de instalación publicado por el proveedor.

Después pide a Gatekeeper que evalúe el paquete como instalador:

spctl --assess --type install --verbose=4 \\\n  \"$HOME/Downloads/VendorSecurity.pkg\"

No sustituyas la evaluación de un paquete por la evaluación de una aplicación. Son artefactos distintos, a menudo firmados con tipos de certificado diferentes y con consecuencias distintas cuando se abren.

Antes de introducir una contraseña de administrador, identifica qué afirma añadir el instalador. Un buen proveedor explica si instala un asistente con privilegios, una extensión del sistema, un elemento de inicio de sesión, un perfil de configuración o un componente de red. Una expresión vaga como «acceso necesario al sistema» no basta para un software que solicita controlar partes relevantes de la seguridad del Mac.

Si el paquete también instala una aplicación, inspecciona la aplicación instalada antes de iniciarla. Un paquete firmado puede contener legítimamente un paquete de aplicación, y la firma del paquete no elimina la necesidad de verificar la firma de ejecución de esa aplicación.

El primer inicio es una revisión de aprobación, no una carrera para pulsar Permitir

Cuando el artefacto supere las comprobaciones, mueve la aplicación a su ubicación prevista e iníciala normalmente mientras estás presente. Conserva la descarga original y los resultados registrados hasta que la aplicación termine su configuración inicial. No empieces concediendo todos los permisos porque la aplicación se llame producto de seguridad.

Lee cada aviso de macOS como una declaración de lo que la aplicación quiere hacer. Las solicitudes habituales incluyen Notificaciones, Acceso total al disco, Accesibilidad, Grabación de pantalla, filtrado de red, una extensión del sistema o un asistente aprobado por un administrador. Cada solicitud debe tener una relación concreta con la función del producto.

Por ejemplo, una aplicación que inspecciona la red puede solicitar razonablemente una extensión de red. Un sistema de control de acciones con credenciales puede necesitar permiso para administrar su propia bóveda y conectarse a servicios concretos, pero no debería necesitar grabación universal de pantalla para hacerlo. Un analizador de discos puede necesitar Acceso total al disco, pero debe explicar qué lee y qué permanece local. La categoría del producto no le da carta blanca.

Usa esta breve revisión del primer inicio:

• Relaciona cada aviso con una función documentada que realmente vayas a utilizar.
• Detente cuando una solicitud sea inesperada y revisa la documentación del proveedor antes de aprobarla.
• No proporciones credenciales de administrador hasta conocer el nombre y la finalidad del componente que se instalará.
• Después de la configuración, comprueba en Ajustes del Sistema si se han activado nuevos elementos de inicio de sesión, perfiles, extensiones o elementos en segundo plano.
• Registra la versión de la aplicación, el Team Identifier, el hash de la descarga y las decisiones sobre permisos junto con la versión aprobada.

Los puntos segundo y tercero importan porque la aprobación más costosa a menudo no es un permiso de la aplicación. Es un componente aprobado por un administrador que permanece después de cerrar la aplicación y puede actuar con más acceso que la propia aplicación.

Para un despliegue en equipo, incorpora esta revisión a un documento sencillo de incorporación. Incluye el origen, la fecha, el hash del archivo, la identidad de firma, el resultado de Gatekeeper, el resultado de la notarización, los componentes instalados, los permisos aprobados y el nombre del revisor. Ese registro agiliza mucho la revisión de una actualización posterior. También revela un cambio inesperado de identidad de firma antes de que llegue a todos los portátiles de los desarrolladores.

No confundas una instalación limpia con un modelo operativo fiable

Una firma limpia, una evaluación aceptada por Gatekeeper y un conjunto razonable de permisos son un buen punto de partida. No demuestran que la aplicación tomará decisiones seguras después de iniciarse. Aún necesitas evaluar dónde almacena los secretos, cómo autentica las actualizaciones, qué envía fuera del Mac y si un proceso comprometido puede abusar de sus privilegios.

En las herramientas de seguridad orientadas a agentes, exige un límite que resista incluso un error del agente. El agente no debería recibir credenciales reutilizables solo porque necesita realizar una acción. Debería solicitar la acción a través de un punto de control local que pueda requerir aprobación humana y conservar un registro de auditoría.

Ese es también el estándar de instalación que aplico a Sallyport: primero verifico la versión firmada y después evalúo su límite real. Sallyport conserva las credenciales en su bóveda cifrada y ejecuta por sí mismo las acciones HTTP o SSH aprobadas, en lugar de pasar los secretos a un proceso de agente.

El hábito útil es sencillo: no permitas que una aplicación obtenga una autoridad amplia solo por llevar la etiqueta de software de seguridad. Haz que muestre la identidad de su editor, su contenido sin modificar, su estado en Gatekeeper y el acceso exacto que solicita. Si no supera esa revisión, no debería recibir los permisos que hacen potente a una aplicación de seguridad.