# Vérifier une application macOS téléchargée avant son premier lancement

Une application de sécurité obtient par conception des accès inhabituels. Elle peut lire le trafic réseau, ajouter une extension système, installer un composant auxiliaire privilégié, inspecter des fichiers ou demander les autorisations d’enregistrement de l’écran et d’accessibilité. Traiter son premier lancement comme celui de n’importe quelle application est une erreur facile à éviter.

Un contrôle sérieux ne demande pas de rétroconcevoir tout le produit. Il faut vérifier que vous avez obtenu l’artefact voulu, que l’identité de son éditeur correspond à vos attentes, que son contenu correspond toujours à la version signée et que macOS l’accepte avec ses protections habituelles. Faites-le avant d’accorder à l’application des autorisations, des identifiants ou un mot de passe administrateur.

Ce contrôle est volontairement répétitif. C’est ce qui fait sa force. Un rituel unique fondé sur l’avertissement affiché par macOS est facile à contourner. Un relevé court des mêmes vérifications pour chaque nouvelle application de sécurité est plus difficile à tromper et plus facile à transmettre à un autre ingénieur.

## Le nom du fichier n’est pas l’éditeur

Un fichier nommé `Acme Security.app` ne vous apprend presque rien. Une icône copiée, un nom de produit familier et une page de téléchargement soignée sont faciles à imiter. L’identité à établir est celle qui est inscrite dans la signature. Comparez-la ensuite avec des informations obtenues séparément auprès de l’éditeur.

Commencez par la source. Privilégiez la propre page de publication de l’éditeur ou l’emplacement de téléchargement indiqué dans sa documentation. Évitez les agrégateurs, les miroirs de fichiers et les liens transmis dans une conversation lorsque vous pouvez obtenir la version originale. Si un collègue vous envoie le fichier, demandez-lui où il l’a obtenu au lieu de considérer sa possession comme une preuve de provenance.

Deux questions distinctes se posent :

- Ce fichier provient-il de l’endroit que je voulais utiliser ?
- L’éditeur qui a signé cet exécutable est-il bien celui auquel je voulais faire confiance ?

On confond souvent ces deux questions. C’est ainsi qu’une page de téléchargement compromise peut passer un contrôle superficiel, ou qu’une application possédant un Developer ID Apple valide peut être jugée fiable uniquement parce que son nom ressemble à celui d’un éditeur connu.

Formez vos attentes avant d’inspecter le fichier. Notez le nom du produit, la version, le type de fichier attendu, le nom de l’éditeur et, s’ils sont publiés, le Team Identifier ou les détails du certificat de signature. Si l’éditeur n’a jamais publié d’identifiant stable, utilisez plusieurs signaux indépendants : sa documentation, son dépôt source, une version précédente à laquelle vous faites déjà confiance et une réponse d’assistance provenant d’un contact connu. Le sujet d’un certificat ne suffit pas si rien ne vous permet auparavant de l’associer à l’éditeur.

Pour une application qui prétend protéger d’autres logiciels, j’attends de l’éditeur qu’il facilite cette vérification. Un fournisseur qui vous demande de désactiver Gatekeeper, d’exécuter un pipe curl dans un shell ou d’ignorer une incohérence sans explication précise a déjà échoué au contrôle d’installation.

## Vérifiez l’artefact livré avant de l’ouvrir

Vérifiez le conteneur téléchargé avant de déplacer une application dans Applications ou de lancer un installateur. Le conteneur détermine les commandes pertinentes et ce qui peut se produire ensuite.

Un `.dmg` est une image disque. Son montage expose son contenu, mais ne devrait pas lancer automatiquement l’application qu’elle contient. Un `.pkg` est un paquet d’installation et peut modifier le système lorsque vous autorisez Installer. Un `.zip` est une archive qui se décompresse généralement en bundle d’application ou en un autre conteneur. Un `.app` nu est déjà un bundle d’application.

Conservez le téléchargement original sans le modifier jusqu’à la fin du contrôle. Le Finder décompresse souvent automatiquement les fichiers ZIP. C’est pratique, mais il devient plus difficile de suivre l’artefact exact dont l’éditeur a publié le hachage. Si l’éditeur fournit une somme SHA-256 pour le ZIP, vérifiez le ZIP avant extraction. S’il fournit une somme pour l’image disque, vérifiez l’image disque avant de la monter.

Dans Terminal, utilisez un chemin entièrement entre guillemets. Faire glisser un fichier du Finder vers Terminal insère ce chemin de manière sûre.

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

La sortie ressemble à ceci :

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

Comparez les 64 caractères hexadécimaux avec la valeur de l’éditeur. Ne comparez pas seulement les premiers caractères.

Une somme de contrôle n’est une preuve solide que si vous obtenez la valeur attendue par un autre moyen que le fichier téléchargé. Le meilleur dispositif simple consiste à utiliser un installateur provenant de la page de publication de l’éditeur et une somme publiée dans une note de version signée, une publication du dépôt source ou une page de sécurité gérée séparément. Une somme affichée juste à côté du bouton de téléchargement détecte toujours une corruption accidentelle, mais elle ne vous protège pas si un attaquant contrôle à la fois cette page et le fichier.

Si l’éditeur ne publie aucune somme, ne faites pas semblant d’être certain. Poursuivez avec les vérifications de signature et de notarisation et accordez davantage d’importance à la vérification de l’éditeur. Si l’application est critique pour votre environnement, demandez à l’éditeur une somme signée ou un manifeste de version. C’est une demande raisonnable.

Pour une image disque, vous pouvez aussi demander à macOS de valider sa structure interne :

```sh
hdiutil verify "$HOME/Downloads/VendorSecurity.dmg"
```

Une vérification réussie indique que la structure de l’image et ses blocs de somme sont cohérents entre eux. Elle n’identifie pas l’éditeur et ne remplace pas une somme SHA-256 fournie par l’éditeur.

## Une signature valide prouve l’intégrité, pas la pertinence

La signature du code répond à une question précise et utile : le bundle signé a-t-il changé depuis que son signataire l’a approuvé ? Elle expose aussi la chaîne de signature et le Team Identifier. Elle ne vous dit pas si l’application est bien conçue, si l’éditeur mérite votre confiance ou si les accès demandés sont raisonnables.

Après avoir monté l’image disque ou décompressé l’archive, inspectez directement le bundle de l’application. Cette commande vérifie la signature du code et les éléments signés imbriqués dans le bundle :

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

En cas de succès, la commande produit souvent peu de sortie. Le résultat se trouve dans le code de retour de Terminal. Un retour silencieux à l’invite après cette commande est donc normal. En cas d’échec, `codesign` indique un fichier modifié, une signature invalide ou un composant imbriqué qui ne peut pas être validé.

Affichez ensuite les détails de signature :

```sh
codesign -dvvv "/Volumes/Vendor Security/Vendor Security.app" 2>&1 | \
  egrep "^(Identifier|TeamIdentifier|Authority|Timestamp)="
```

La sortie ressemble approximativement à ceci :

```text
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
```

Le nom réel de l’éditeur, l’identifiant du bundle et le Team Identifier doivent correspondre à vos attentes. Notez le Team Identifier. Il est bien plus stable et discriminant qu’une icône ou qu’un nom d’affichage et vous donne une valeur concrète à comparer lorsque l’éditeur publie une mise à jour.

Ne donnez pas trop d’importance au mot `Authority`. Une signature Developer ID signifie qu’Apple a délivré le certificat à un développeur enregistré et que le code est valide pour cette chaîne. Cela ne signifie pas qu’Apple recommande le produit. La documentation d’Apple est claire sur cette distinction : la notarisation est une vérification automatisée des logiciels malveillants et de la signature, pas une App Review.

Les recommandations d’Apple sur la signature du code déconseillent également aux développeurs d’utiliser `codesign --deep` pour signer des logiciels complexes, car cette option applique les paramètres trop largement. Cet avertissement concerne la création des signatures. Pour un utilisateur qui vérifie une application, `--deep` est utile parce qu’il demande à `codesign` de valider le code imbriqué. Il n’inspecte toujours pas chaque script ou fichier de configuration pour y rechercher une intention malveillante.

Si l’application contient un composant auxiliaire, un outil en ligne de commande ou une extension, la vérification du bundle est une première étape, pas une conclusion. Le contrôle du premier lancement, plus loin dans cet article, permet de comparer ces composants avec les besoins annoncés par l’application.

## L’évaluation Gatekeeper vérifie la version que macOS exécutera

Évaluez l’application avec Gatekeeper même lorsque la signature semble correcte. `spctl` évalue l’élément selon la politique système qui compte au moment de l’exécution. La question est alors plus proche de : « Ce Mac acceptera-t-il cette application avec ses protections habituelles ? »

Utilisez :

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

Un résultat sain contient souvent des lignes comme celles-ci :

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

Les termes exacts varient selon la version de macOS. Vous voulez obtenir une évaluation acceptée, une source Developer ID notariée pour un téléchargement direct et une origine que vous reconnaissez.

Cette vérification détecte une erreur qu’une somme de contrôle ne peut pas détecter : vous avez peut-être téléchargé un fichier intact provenant du mauvais éditeur. Elle détecte aussi une autre erreur que l’inspection du certificat peut manquer : une application correctement signée peut ne pas respecter la politique Gatekeeper actuelle.

Apple décrit Gatekeeper comme un mécanisme qui vérifie les logiciels téléchargés à la recherche d’un développeur identifié, d’une notarisation et de modifications. C’est un filet de sécurité utile, mais cela reste une évaluation de la politique par le système d’exploitation. Elle doit éclairer votre décision, pas remplacer votre jugement sur l’éditeur et sur la pertinence des privilèges demandés.

Ne contournez pas une évaluation échouée en supprimant des attributs ou en utilisant une exception du Finder avant d’en comprendre la cause. Conservez le texte de l’échec dans vos notes. Un certificat révoqué, une signature expirée ou malformée, une notarisation manquante et une restriction gérée par l’organisation appellent des réponses différentes. Traiter tous les avertissements comme une gêne générique transforme les exceptions en procédure d’installation normale.

## Un ticket agrafé est utile, mais ne suffit pas pour vérifier la notarisation

La notarisation et l’agrafage sont liés, mais différents. La notarisation signifie que le service de notarisation d’Apple a traité le logiciel soumis et délivré un ticket après ses vérifications automatisées. L’agrafage attache ce ticket à une application, une image disque ou un paquet d’installation. Gatekeeper peut aussi rechercher un ticket en ligne.

Si les outils de ligne de commande Xcode sont installés, vérifiez si un ticket est attaché :

```sh
xcrun stapler validate "/Volumes/Vendor Security/Vendor Security.app"
```

Une validation réussie confirme que le ticket est physiquement attaché au bundle. C’est utile pour un ordinateur portable susceptible de lancer l’application sans connexion réseau.

Ne rejetez pas une application uniquement parce que cette commande indique qu’aucun ticket n’est agrafé. Apple précise que Gatekeeper peut trouver un ticket de notarisation en ligne, notamment pour un utilisateur qui a téléchargé l’application avant la fin de la notarisation. Une archive ZIP ne peut pas non plus porter elle-même un ticket agrafé. L’éditeur doit agrafer les éléments qu’elle contient, puis créer une nouvelle archive.

Utilisez les vérifications dans le bon ordre :

1. Vérifiez la somme SHA-256 lorsqu’une somme publiée indépendamment existe.
2. Vérifiez la signature de l’application et inspectez son Team Identifier.
3. Effectuez l’évaluation Gatekeeper.
4. Validez un ticket agrafé si l’outil est disponible et si un premier lancement hors ligne est important.

Gardez le Mac connecté pour le premier lancement normal, sauf si l’éditeur documente explicitement une procédure de déploiement hors ligne. Gatekeeper pourra ainsi effectuer ses recherches en ligne habituelles, notamment les vérifications de statut du certificat. Ne considérez pas un ticket agrafé comme la garantie que l’application restera toujours acceptable si son identité de signature est révoquée par la suite.

La notarisation a des limites qu’il faut énoncer clairement. Elle ne constitue pas un audit complet du comportement d’une application. Elle ne confirme pas que son service cloud traite les données de manière sûre, que son système de mise à jour est fiable ou qu’une nouvelle version ne demandera que des autorisations raisonnables. Elle indique que l’artefact soumis a passé le processus automatisé d’Apple et fournit à Gatekeeper un ticket utilisable.

## La quarantaine fournit des informations sur la provenance, laissez-la en place

L’attribut étendu `com.apple.quarantine` indique que macOS a reçu un élément par un canal qui l’a marqué comme téléchargé ou transféré. Il aide Gatekeeper à comprendre qu’il s’agit d’un premier lancement à contrôler. Ce n’est pas une étiquette de logiciel malveillant.

Inspectez les attributs avec :

```sh
xattr -l "/Volumes/Vendor Security/Vendor Security.app"
```

Pour un élément téléchargé, vous pouvez voir une sortie contenant :

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

Les indicateurs et le format de l’horodatage sont des détails d’implémentation. La conclusion utile est que l’élément conserve sa provenance de téléchargement. Une application qui possède cet attribut n’est pas suspecte pour cette seule raison. La plupart des téléchargements effectués dans un navigateur devraient le posséder.

L’absence de quarantaine ne rend pas non plus une application sûre. Les fichiers peuvent perdre leurs attributs étendus lorsqu’ils passent par des outils d’archivage, des partages réseau, des supports amovibles ou une copie effectuée par un collègue. Apple indique également que macOS vérifie la présence de contenu malveillant connu au premier lancement, quelle que soit la manière dont le fichier est arrivé. En pratique, préserver la provenance donne tout de même davantage de contexte à Gatekeeper et à votre procédure de contrôle.

La solution souvent proposée pour une application qui ne s’ouvre pas est la suivante :

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

N’en faites pas une étape normale d’installation. Vous supprimez un signal de contrôle parce que le résultat du contrôle vous déplaît. Cela ne répare pas une signature rompue, n’établit pas l’identité de l’éditeur et ne rend pas plus sûre une application non notariée. Si les instructions publiées par un éditeur exigent cette commande, arrêtez-vous et cherchez pourquoi il ne peut pas fournir une version acceptée par Gatekeeper.

Un Mac géré peut appliquer des règles plus strictes par l’intermédiaire de la gestion des appareils. Dans ce cas, une exception peut être indisponible ou interdite pour une bonne raison. Demandez à l’administrateur quelle procédure est prévue par la politique au lieu de traiter cette restriction comme un problème technique à résoudre.

## Les paquets doivent être inspectés avant de donner un mot de passe à Installer

Un `.pkg` mérite davantage de méfiance qu’un bundle d’application, car Installer peut écrire en dehors de votre dossier utilisateur après votre autorisation. Les produits de sécurité ont parfois besoin d’un paquet pour installer un composant auxiliaire privilégié, une extension système, un filtre réseau ou des composants complémentaires. Cela peut être légitime. L’action reste importante.

Vérifiez les informations de signature d’un paquet avant de double-cliquer dessus :

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

Un résultat habituel indique le statut signé du paquet, le certificat Developer ID Installer et la chaîne de certificats. Comparez le nom de l’éditeur et, lorsqu’il est disponible, le Team Identifier avec l’identité que vous avez relevée pour l’application ou avec les documents d’installation publiés par l’éditeur.

Demandez ensuite à Gatekeeper d’évaluer le paquet comme un installateur :

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

Ne remplacez pas l’évaluation d’un paquet par celle d’une application. Il s’agit d’artefacts différents, souvent signés avec des types de certificats différents, et leur ouverture n’a pas les mêmes conséquences.

Avant de saisir un mot de passe administrateur, identifiez ce que l’installateur prétend ajouter. Un éditeur sérieux explique s’il installe un composant auxiliaire privilégié, une extension système, un élément d’ouverture de session, un profil de configuration ou un composant réseau. Des termes vagues comme « accès système requis » ne suffisent pas pour un logiciel qui demande à contrôler des éléments sensibles du Mac.

Si le paquet installe aussi une application, inspectez l’application installée avant de la lancer. Un paquet signé peut légitimement contenir un bundle d’application, mais sa signature ne vous dispense pas de vérifier la signature d’exécution de ce bundle.

## Le premier lancement est un contrôle d’approbation, pas une course vers le bouton Autoriser

Une fois les vérifications terminées, déplacez l’application à l’emplacement prévu et lancez-la normalement en restant présent. Conservez le téléchargement original et les résultats consignés jusqu’à la fin de la configuration initiale. Ne commencez pas par accepter toutes les demandes parce que l’application est présentée comme un produit de sécurité.

Lisez chaque demande de macOS comme une description de ce que l’application veut faire. Les demandes courantes concernent les notifications, l’accès complet au disque, l’accessibilité, l’enregistrement de l’écran, le filtrage réseau, une extension système ou un composant auxiliaire approuvé par un administrateur. Chaque demande doit avoir un lien concret avec la fonction du produit.

Par exemple, une application d’inspection réseau peut raisonnablement demander une extension réseau. Une passerelle d’actions sur les identifiants peut avoir besoin de gérer son propre coffre et de se connecter à des services nommés, mais elle ne devrait pas avoir besoin d’un enregistrement universel de l’écran pour cela. Un analyseur de disque peut avoir besoin de l’accès complet au disque, mais il doit expliquer ce qu’il lit et ce qui reste local. La catégorie du produit ne constitue pas une autorisation générale.

Utilisez cette courte procédure pour le premier lancement :

- Associez chaque demande à une fonction documentée que vous prévoyez réellement d’utiliser.
- Arrêtez-vous lorsqu’une demande vous surprend, puis consultez la documentation de l’éditeur avant de l’approuver.
- Refusez les identifiants administrateur tant que vous ne connaissez pas le nom et la fonction du composant installé.
- Après la configuration, vérifiez dans Réglages Système les nouveaux éléments d’ouverture de session, profils, extensions ou éléments d’arrière-plan.
- Notez la version de l’application, le Team Identifier, le hachage du téléchargement et les décisions relatives aux autorisations dans le dossier de version.

Les troisième et quatrième points comptent, car l’approbation la plus risquée n’est souvent pas une autorisation d’application. Il s’agit d’un composant approuvé par un administrateur qui reste actif au-delà de la fenêtre de l’application et peut disposer de davantage d’accès que l’application elle-même.

Pour un déploiement en équipe, intégrez ce contrôle à un document d’entrée simple. Incluez la source, la date, le hachage du fichier, l’identité de signature, le résultat Gatekeeper, le résultat de notarisation, les composants installés, les autorisations approuvées et le nom du vérificateur. Ce relevé accélère considérablement le contrôle d’une mise à jour. Il permet aussi de repérer une modification surprenante de l’identité de signature avant qu’elle n’atteigne tous les ordinateurs des développeurs.

## Ne confondez pas une installation propre avec un modèle d’exploitation fiable

Une signature propre, une évaluation Gatekeeper acceptée et un ensemble d’autorisations raisonnable constituent un bon point de départ. Cela ne prouve pas que l’application prendra de bonnes décisions après son lancement. Vous devez encore examiner où elle stocke les secrets, comment elle authentifie les mises à jour, ce qu’elle envoie hors du Mac et si un processus compromis peut exploiter ses privilèges.

Pour les outils de sécurité destinés à être utilisés par des agents, exigez une limite qui résiste aux erreurs de l’agent. L’agent ne devrait pas recevoir d’identifiants réutilisables simplement parce qu’il doit effectuer une action. Il devrait demander l’action via un point de contrôle local capable d’exiger une approbation humaine et de conserver une trace d’audit.

C’est également la norme d’installation que j’applique à Sallyport : vérifier d’abord la version signée, puis évaluer sa limite réelle. Sallyport conserve les identifiants dans son coffre chiffré et exécute lui-même les actions HTTP ou SSH approuvées, au lieu de transmettre les secrets à un processus d’agent.

L’habitude utile est simple : ne laissez pas une application obtenir une autorité étendue simplement parce qu’elle est présentée comme un logiciel de sécurité. Demandez-lui de montrer l’identité de son éditeur, l’intégrité de son contenu, son statut Gatekeeper et les accès précis dont elle a besoin. Si elle ne résiste pas à ce contrôle, elle ne devrait pas recevoir les autorisations qui rendent une application de sécurité puissante.