# Verificação de aplicativos macOS baixados antes da primeira inicialização

Um aplicativo de segurança recebe acesso incomum por definição. Ele pode ler o tráfego de rede, adicionar uma extensão do sistema, instalar um auxiliar privilegiado, inspecionar arquivos ou pedir permissões de gravação de tela e acessibilidade. Tratar a primeira inicialização como uma instalação comum de aplicativo é um erro evitável.

Uma revisão adequada não exige fazer engenharia reversa de todo o produto. É preciso confirmar que você obteve o artefato correto, que a identidade do editor é a esperada, que o conteúdo continua igual ao da versão assinada e que o macOS o aceita dentro das proteções normais. Faça isso antes de o aplicativo receber permissões, credenciais ou uma senha de administrador.

Esta revisão é deliberadamente repetitiva. Essa é a sua força. Um ritual feito uma única vez, baseado no aviso que o macOS por acaso exibir, é fácil de contornar. Um registro curto com as mesmas verificações para cada novo aplicativo de segurança é mais difícil de enganar e mais fácil de entregar a outro engenheiro.

## O nome do arquivo não é o editor

Um arquivo chamado `Acme Security.app` diz quase nada. Um ícone copiado, um nome de produto conhecido e uma página de download bem acabada são fáceis de imitar. A identidade que você precisa estabelecer é a identidade registrada na assinatura. Depois, compare-a com informações obtidas separadamente do editor.

Comece pela fonte. Prefira a própria página de lançamento do editor ou um local de distribuição indicado por ele na documentação. Evite agregadores de download, espelhos de arquivos e links enviados por uma conversa quando puder obter a versão original. Se um colega enviar o arquivo, pergunte onde ele o obteve, em vez de tratar a posse dele como prova de procedência.

Há duas perguntas diferentes aqui:

- Este arquivo veio do local que eu pretendia usar?
- O editor que assinou este executável é o editor em quem eu pretendia confiar?

As pessoas costumam juntar essas perguntas em uma só. É assim que uma página de download comprometida de um fornecedor ainda pode passar por uma revisão superficial e que um aplicativo com um Developer ID válido da Apple pode ganhar confiança apenas porque seu nome lembra o de um fornecedor conhecido.

Crie uma expectativa antes de inspecionar o arquivo. Registre o nome do produto, a versão, o tipo de arquivo esperado, o nome do editor e qualquer Team Identifier ou detalhe do certificado de assinatura publicado. Se o fornecedor nunca tiver publicado um identificador estável, use vários sinais independentes: a documentação, o repositório de código, uma versão anterior em que você já confia e uma resposta de suporte de um contato conhecido. O nome no certificado, sozinho, não basta quando você não tem um motivo anterior para associá-lo ao fornecedor.

Para um aplicativo que afirma proteger outros softwares, espero que o editor facilite esse processo. Um fornecedor que pede para você desativar o Gatekeeper, executar um curl enviado diretamente para um shell ou ignorar uma divergência sem uma explicação precisa já falhou na revisão de instalação.

## Verifique o artefato de distribuição antes de abri-lo

Verifique o contêiner baixado antes de arrastar um aplicativo para Applications ou executar um instalador. O contêiner determina quais comandos importam e o que pode acontecer em seguida.

Um `.dmg` é uma imagem de disco. Montá-la expõe seu conteúdo, mas não deve iniciar o aplicativo contido. Um `.pkg` é um pacote de instalação e pode fazer alterações no sistema depois que você autorizar o Installer. Um `.zip` é um arquivo compactado que normalmente é expandido para um pacote de aplicativo ou outro contêiner. Um `.app` avulso já é um pacote de aplicativo.

Mantenha o download original intacto até o fim da revisão. O Finder costuma expandir arquivos ZIP automaticamente, o que é conveniente, mas facilita perder de vista o artefato exato cujo hash o fornecedor publicou. Se o editor fornecer um checksum SHA-256 para o ZIP, verifique o ZIP antes da extração. Se fornecer um checksum para a imagem de disco, verifique a imagem antes de montá-la.

No Terminal, use um caminho totalmente entre aspas. Arrastar um arquivo do Finder para o Terminal insere o caminho com segurança.

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

A saída terá este formato:

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

Compare os 64 caracteres hexadecimais completos com o valor do editor. Não compare apenas os primeiros caracteres e considere a tarefa concluída.

Um checksum é uma evidência forte apenas quando você obtém o resumo esperado por um caminho diferente do arquivo baixado. A melhor configuração simples é um instalador da página de lançamento do fornecedor e um checksum em uma nota de lançamento assinada, em uma versão de um repositório de código ou em uma página de segurança mantida separadamente. Um hash impresso imediatamente ao lado do botão de download ainda detecta corrupção acidental, mas não protege você se um invasor controlar a página e o arquivo.

Se o fornecedor não publicar um checksum, não invente uma certeza. Continue com as verificações de assinatura e notarização e dê mais peso à verificação do editor. Se o aplicativo for importante para o seu ambiente, peça ao fornecedor um resumo assinado ou um manifesto de lançamento. É um pedido razoável.

Para uma imagem de disco, você também pode pedir ao macOS que valide sua estrutura interna:

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

Uma verificação bem-sucedida informa que a estrutura da imagem e os blocos de checksum são internamente consistentes. Ela não identifica o editor e não substitui um resumo SHA-256 fornecido pelo fornecedor.

## Uma assinatura válida prova integridade, não bom senso

A assinatura de código responde a uma pergunta específica e útil: o pacote assinado foi alterado desde que o assinante o aprovou? Ela também expõe a cadeia de assinatura e o Team Identifier. Não informa se o aplicativo foi bem projetado, se o editor merece sua confiança ou se o acesso solicitado faz sentido.

Depois de montar a imagem de disco ou expandir o arquivo, inspecione diretamente o pacote do aplicativo. Este comando verifica a assinatura do código e confere o código assinado aninhado no pacote:

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

Uma execução bem-sucedida costuma produzir pouca saída. O status de saída do Terminal é o resultado, então voltar silenciosamente ao prompt depois desse comando é normal. Em caso de falha, `codesign` identifica um arquivo alterado, uma assinatura inválida ou um componente aninhado que não passa na validação.

Depois, mostre os detalhes da assinatura:

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

Espere uma saída aproximadamente assim:

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

O nome real do fornecedor, o identificador do pacote e o Team Identifier devem corresponder ao esperado. Anote o Team Identifier. Ele é muito mais estável e específico do que um ícone ou nome de exibição e oferece algo concreto para comparar quando o fornecedor lançar uma atualização.

Não dê importância excessiva à palavra `Authority`. Uma assinatura Developer ID significa que a Apple emitiu o certificado para um desenvolvedor registrado e que o código é validado por essa cadeia. Não significa que a Apple recomenda o produto. A própria documentação da Apple deixa clara a distinção relacionada: a notarização é uma verificação automatizada de malware e assinatura, não uma análise do produto pela App Review.

A orientação de assinatura de código da Apple também alerta os desenvolvedores para não usarem `codesign --deep` ao assinar softwares complexos, porque o comando aplica opções de forma ampla. Esse aviso diz respeito à criação de assinaturas. Para um usuário que realiza uma verificação, `--deep` é útil porque pede ao `codesign` que valide o código aninhado. Ainda assim, ele não inspeciona cada script ou arquivo de configuração em busca de intenções maliciosas.

Se o aplicativo contiver um auxiliar, uma ferramenta de linha de comando ou uma extensão, a verificação do pacote é a primeira etapa, não a palavra final. A revisão da primeira inicialização, mais adiante neste artigo, é quando você compara esses componentes com o que o aplicativo afirma precisar.

## A avaliação do Gatekeeper verifica a versão que o macOS executará

Execute uma avaliação do Gatekeeper para o aplicativo mesmo quando a assinatura parecer correta. O `spctl` avalia o item de acordo com a política do sistema relevante no momento da execução. Ele se aproxima da pergunta: «Este Mac aceitará este aplicativo sob as proteções normais?»

Use:

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

Um resultado saudável costuma incluir linhas como estas:

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

A redação exata varia conforme a versão do macOS. O que você quer é uma avaliação aceita, uma origem Developer ID notarizada quando se trata de um download direto e uma origem que você reconheça.

Essa verificação detecta um erro que um checksum não detecta: você pode ter baixado um arquivo sem alterações do editor errado. Ela também detecta outro erro que a inspeção do certificado pode não revelar: um aplicativo assinado corretamente pode não atender à política atual do Gatekeeper.

A Apple descreve o Gatekeeper como uma ferramenta que verifica se o software baixado tem um desenvolvedor identificado, notarização e alterações. É uma rede de segurança útil, mas continua sendo uma avaliação de política feita pelo sistema operacional. Ela deve apoiar sua decisão, não substituí-la quando você avalia se o editor e os privilégios solicitados fazem sentido.

Não suprima uma avaliação malsucedida removendo atributos ou usando uma exceção no Finder antes de entender o motivo. Preserve o texto da falha nas anotações da revisão. Um certificado revogado, uma assinatura expirada ou malformada, um resultado de notarização ausente e uma restrição administrada pela organização exigem respostas diferentes. Tratar todo aviso como um incômodo genérico é o caminho para transformar exceções em um processo normal de instalação.

## Um tíquete anexado ajuda, mas não é toda a verificação de notarização

Notarização e anexação estão relacionadas, mas são diferentes. Notarização significa que o serviço de notários da Apple processou o software enviado e emitiu um tíquete após suas verificações automatizadas. A anexação coloca esse tíquete em um aplicativo, imagem de disco ou pacote de instalação. O Gatekeeper também pode localizar um tíquete online.

Se você tiver as Xcode Command Line Tools instaladas, verifique se há um tíquete anexado:

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

Uma validação bem-sucedida confirma que o tíquete está fisicamente anexado ao pacote. Isso é útil em um notebook que possa iniciar o aplicativo pela primeira vez sem conexão de rede.

Não rejeite um aplicativo apenas porque esse comando informa que não há tíquete anexado. A Apple documenta que o Gatekeeper pode encontrar um tíquete de notarização online, inclusive para um usuário que baixou o aplicativo antes da conclusão da notarização. Um arquivo ZIP também não pode carregar um tíquete anexado por si só. O editor precisa anexar o tíquete aos itens dentro dele e criar um novo arquivo.

Use as verificações na ordem correta:

1. Verifique o resumo SHA-256 quando existir um resumo publicado de forma independente.
2. Verifique a assinatura do aplicativo e inspecione seu Team Identifier.
3. Execute a avaliação do Gatekeeper.
4. Valide um tíquete anexado se a ferramenta estiver disponível e se a primeira inicialização offline for importante.

Mantenha o Mac conectado à internet durante a primeira inicialização normal, a menos que o editor documente explicitamente um processo de implantação offline. Isso permite que o Gatekeeper faça suas consultas online normais, incluindo verificações do status do certificado. Não interprete um tíquete anexado como uma promessa de que o aplicativo continuará sendo aceito se sua identidade de assinatura for revogada mais tarde.

A notarização tem limites que vale a pena declarar claramente. Ela não é uma auditoria completa do comportamento do aplicativo. Não confirma que o serviço em nuvem trata os dados com segurança, que o sistema de atualização é confiável ou que uma nova versão solicitará apenas permissões razoáveis. Ela informa que o artefato enviado passou pelo processo automatizado da Apple e fornece ao Gatekeeper um tíquete para usar.

## A quarentena é uma evidência de procedência, portanto deixe-a no lugar

O atributo estendido `com.apple.quarantine` registra que o macOS recebeu um item por um canal que o marcou como baixado ou transferido. Ele ajuda o Gatekeeper a saber que se trata de uma primeira execução que merece verificação. Não é um rótulo de malware.

Inspecione os atributos com:

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

Para um item baixado, você pode ver uma saída contendo:

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

As flags e o formato do registro de data e hora são detalhes de implementação. A conclusão útil é que o item mantém sua procedência de download. Um aplicativo com esse atributo não é suspeito apenas por tê-lo. A maioria dos downloads feitos por navegadores deve apresentar esse atributo.

A ausência da quarentena também não torna um aplicativo seguro. Os arquivos podem perder atributos estendidos quando passam por ferramentas de compactação, compartilhamentos de rede, mídias removíveis ou uma cópia feita por um colega. A Apple também afirma que o macOS verifica a existência de conteúdo malicioso conhecido na primeira abertura, independentemente de como o arquivo chegou ao computador. Na prática, preservar a procedência ainda oferece mais contexto ao Gatekeeper e ao seu processo de revisão.

A solução popular para um aplicativo que não abre é esta:

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

Não inclua isso em um procedimento normal de instalação. O comando remove um sinal de controle porque você não gostou do resultado desse controle. Ele não corrige uma assinatura quebrada, não estabelece a identidade do editor e não torna mais seguro um aplicativo não notarizado. Se as instruções publicadas pelo fornecedor exigirem esse comando, pare e descubra por que ele não consegue distribuir uma versão aceita pelo Gatekeeper.

Um Mac gerenciado pode aplicar regras mais rígidas por meio do gerenciamento de dispositivos. Nesse caso, uma exceção pode estar indisponível ou proibida por um bom motivo. Peça ao administrador o caminho definido pela política, em vez de tratar a restrição como um quebra-cabeça técnico.

## Pacotes exigem inspeção própria antes de o Installer receber uma senha

Um `.pkg` merece mais desconfiança do que um pacote de aplicativo porque o Installer da Apple pode gravar fora da sua pasta de usuário depois que você o autoriza. Produtos de segurança às vezes precisam de pacotes para instalar um auxiliar privilegiado, uma extensão do sistema, um filtro de rede ou componentes de suporte. Isso pode ser legítimo. Ainda assim, é uma ação de impacto significativo.

Verifique as informações de assinatura de um pacote antes de clicar duas vezes nele:

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

Um resultado típico identifica o status de assinatura do pacote, o certificado Developer ID Installer e a cadeia de certificados. Compare o nome do fornecedor e, quando disponível, o Team Identifier com a identidade registrada para o aplicativo ou com o material de instalação publicado pelo fornecedor.

Depois, peça ao Gatekeeper que avalie o pacote como instalador:

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

Não substitua a avaliação de um pacote pela avaliação de um aplicativo. São artefatos diferentes, assinados com tipos de certificado diferentes em muitas versões, e têm consequências distintas quando abertos.

Antes de digitar uma senha de administrador, identifique o que o instalador afirma adicionar. Um fornecedor decente explica se instala um auxiliar privilegiado, uma extensão do sistema, um item de login, um perfil de configuração ou um componente de rede. Uma expressão vaga como «acesso necessário ao sistema» é insuficiente para um software que pede controle sobre partes relevantes da segurança do Mac.

Se o pacote também instalar um aplicativo, inspecione o aplicativo instalado antes de iniciá-lo. Um pacote assinado pode conter legitimamente um pacote de aplicativo, e a assinatura do pacote não elimina a necessidade de verificar a assinatura de execução desse aplicativo.

## A primeira inicialização é uma revisão de aprovação, não uma corrida para clicar em Allow

Depois que o artefato passar pelas verificações, mova o aplicativo para o local pretendido e inicie-o normalmente enquanto estiver presente. Mantenha o download original e as saídas registradas até que o aplicativo conclua a configuração inicial. Não comece concedendo todas as permissões porque o aplicativo é chamado de produto de segurança.

Leia cada aviso do macOS como uma declaração do que o aplicativo quer fazer. As solicitações comuns incluem Notificações, Acesso total ao disco, Acessibilidade, Gravação de tela, filtragem de rede, uma extensão do sistema ou um auxiliar aprovado por um administrador. Cada solicitação deve ter uma relação concreta com a função do produto.

Por exemplo, um aplicativo de inspeção de rede pode pedir legitimamente uma extensão de rede. Um gateway de ações com credenciais pode precisar de permissão para gerenciar o próprio cofre e conectar-se a serviços específicos, mas não deveria precisar de gravação universal de tela para isso. Um scanner de disco pode precisar de Acesso total ao disco, mas deve explicar o que lê e o que permanece local. A categoria do produto não concede autorização irrestrita.

Use esta breve revisão da primeira inicialização:

- Relacione cada aviso a uma função documentada que você realmente pretende usar.
- Pare quando uma solicitação for inesperada e consulte a documentação do fornecedor antes de aprová-la.
- Recuse credenciais de administrador até saber o nome e a finalidade do componente que será instalado.
- Depois da configuração, verifique os Ajustes do Sistema em busca de novos Itens de Login, perfis, extensões ou itens em segundo plano.
- Registre a versão do aplicativo, o Team Identifier, o hash do download e as decisões sobre permissões junto ao registro da versão.

Os dois últimos itens são importantes porque a aprovação mais arriscada muitas vezes não é uma permissão do aplicativo. É um componente aprovado por um administrador que permanece ativo além da janela do aplicativo e pode agir com mais acesso do que o próprio aplicativo.

Para uma implantação em equipe, coloque essa revisão em um documento simples de entrada. Inclua o local de origem, a data, o hash do arquivo, a identidade de assinatura, o resultado do Gatekeeper, o resultado da notarização, os componentes instalados, as permissões aprovadas e o nome do revisor. Esse registro torna a revisão de uma atualização posterior muito mais rápida. Ele também revela uma mudança inesperada na identidade de assinatura antes que ela chegue aos notebooks de todos os desenvolvedores.

## Não confunda uma instalação limpa com um modelo operacional confiável

Uma assinatura limpa, uma avaliação aceita pelo Gatekeeper e um conjunto razoável de permissões são um bom ponto de partida. Eles não provam que o aplicativo fará escolhas seguras depois da inicialização. Você ainda precisa avaliar onde ele armazena segredos, como autentica atualizações, o que envia para fora do Mac e se um processo comprometido pode abusar de seus privilégios.

Para ferramentas de segurança voltadas a agentes, exija um limite que sobreviva a um erro do agente. O agente não deve receber credenciais reutilizáveis apenas porque precisa executar uma ação. Ele deve solicitar a ação por meio de um ponto de controle local que possa exigir aprovação humana e manter uma trilha de auditoria.

Esse também é o padrão de instalação que aplico ao Sallyport: primeiro verifico a versão assinada e depois avalio seu limite real. O Sallyport mantém as credenciais em seu cofre criptografado e executa sozinho as ações HTTP ou SSH aprovadas, em vez de passar os segredos a um processo do agente.

O hábito útil é simples: não permita que um aplicativo obtenha autoridade ampla apenas por ser chamado de software de segurança. Faça com que ele mostre a identidade do editor, o conteúdo sem alterações, o status do Gatekeeper e o acesso exato que deseja. Se não passar por essa revisão, não deve receber as permissões que tornam um aplicativo de segurança poderoso.