Como verificar a procedência de software em marketplaces

A procedência de software se verifica no distribuidor e no arquivo instalado. Compras compara o artefato com uma referência independente e autenticada e define quem interrompe seu uso. Em 29 de outubro de 2026, versões maliciosas de uma extensão, componente instalado que acrescenta funções a um programa, apareceram no marketplace da Cursor.

O aviso da Cursor, atualizado em 30 de outubro, identifica as versões 2.1.312 e 2.1.313 de Anthropic.claude-code, para Windows e macOS, disponíveis aproximadamente das 2h27 às 13h35, no horário do Pacífico. As versões modificadas foram disponibilizadas no marketplace da Cursor, mas não foram desenvolvidas pela Anthropic. O aviso não identifica organizações, clientes ou países afetados, nem informa compra paga. O caso não comprova falha de um comprador.

O que reunir antes de avaliar a compra?

A avaliação começa com a proposta, o contrato disponível, o fabricante e o canal de entrega, além do inventário das extensões pretendidas. Compras precisa reunir engenharia, segurança e financeiro antes da assinatura, porque cada equipe responde por parte da aprovação e nenhuma consegue fechá-la sozinha.

O inventário deve relacionar produto, identificador da extensão, versão, sistema operacional, usuários previstos e responsável interno, para que segurança localize instalações quando houver alerta sobre aquele pacote. Uma estação gerenciada, ou endpoint, exige definir quem autoriza instalações e quem as restringe.

O aceite segue cinco passos.

1. Identificar quem vende e quem distribui.
2. Conferir a identidade e a integridade do artefato.
3. Combinar a resposta a incidentes com as partes envolvidas.
4. Limitar a autoridade concedida na máquina.
5. Definir e testar o desligamento.

Cada passo exige evidência.

Passo 1: quem vende e quem distribui o software?

A cadeia de suprimentos de software começa antes do contrato: quem fabrica, quem assina e quem entrega o arquivo podem ser partes diferentes. Compras registra essas identidades e obtém confirmação do canal autorizado para cada componente, pois o nome na proposta não identifica, por si só, a origem do pacote instalado na estação.

Na comparação entre compra direta e marketplace, a rota comercial ajuda a identificar quem responde pela proposta. Em qualquer rota, o comprador confirma quem contrata, quem emite o documento fiscal e quem entrega a extensão. A rota comercial não substitui a conferência da procedência de software.

Cada resposta exige documento ou confirmação escrita antes da compra.

A Receita Federal descreve a NFS-e como documento digital que formaliza a prestação de serviços. Ela não verifica os bytes do artefato. O financeiro e o jurídico analisam o documento aplicável à operação; a leitura sobre importação e nota fiscal aborda a trilha documental separadamente.

O Nexforce Marketplace oferece uma rota de contratação de software internacional com pagamento local e gestão centralizada. Em ambas as rotas, compras confirma faturamento, pagamento, fabricante e canal. A contratação local não substitui a verificação do arquivo.

Passo 2: como verificar a procedência de software no artefato?

A verificação de procedência de software compara o artefato recebido com uma referência autenticada e independente do canal de entrega, vinculada ao identificador, à versão e à plataforma corretos. Quando houver assinatura verificável, segurança também deve examinar quem assinou e se a cadeia de confiança permanece válida.

Um hash é um resumo calculado a partir do conteúdo de um arquivo, e a verificação de extensões de software depende de uma referência que não venha do mesmo canal. Se o hash do artefato recebido diverge da referência confiável, a instalação não passa no aceite. Se corresponde, a comparação indica que os arquivos coincidem para aquele cálculo, mas não prova autoria quando arquivo e referência vieram do mesmo canal comprometido. A fonte independente precisa ser autenticada. A conferência se repete a cada atualização, não só na instalação.

Assinatura digital permite conferir integridade e identidade associada à assinatura. A equipe verifica o signatário. Examina a cadeia de confiança. Verifica a revogação conforme o formato do arquivo. Sem hash confiável ou assinatura verificável, compras registra a lacuna para pendência ou exceção formal. A triagem de achados de segurança complementa, mas não substitui a verificação de procedência de software.

No caso relatado pela Cursor, os hashes publicados identificam arquivos maliciosos e servem à detecção. Não são hashes de referência confiáveis. A equipe deve separar o material usado para procurar comprometimento da referência autenticada usada para aceitar uma nova instalação.

Passo 3: como combinar a resposta a incidentes no contrato?

O contrato deve deixar claro quem avisa, por qual canal e de que marco começa o prazo negociado de notificação. Compras e jurídico obtêm esses compromissos antes da assinatura e confirmam como o fornecedor apoiará a investigação e a correção quando um artefato suspeito chegar às máquinas.

A negociação pede versões e plataformas afetadas, janela de exposição, indicadores e atualizações. O prazo precisa de marco inicial e destinatário definidos. As partes combinam preservação de evidências, apoio à investigação e orientações de correção. O jurídico avalia notificações e responsabilidades aplicáveis à operação, sem presumir obrigações a partir do caso da Cursor.

São propostas, não cláusulas atribuídas. O custo total inclui investigação e restauração, mesmo quando a proposta não os separa.

Passo 4: como limitar a autoridade na máquina do desenvolvedor?

A empresa deve autorizar uma extensão pelo acesso necessário, não pela função anunciada. Engenharia e segurança precisam examinar acesso a repositórios, arquivos locais, terminal, rede e credenciais, e distinguir as permissões da extensão daquelas que pertencem ao usuário ou ao administrador da máquina.

Uma extensão executada no contexto do usuário pode alcançar recursos acessíveis àquela conta; acesso administrativo é outra decisão e deve seguir um processo próprio. O inventário deve registrar quais componentes podem iniciar processos, alterar configurações ou permanecer ativos após o programa fechar. A equipe revisa a necessidade desses acessos quando a versão ou a função mudar.

No aviso da Cursor, o código tentava adicionar uma chave SSH controlada pelo atacante, habilitar o serviço SSH local e abrir um túnel reverso. A etapa de habilitar o serviço exigia privilégios de administrador que a extensão não tinha na maioria dos hosts; nesses hosts, a etapa falhou. Segundo o aviso, a chave foi adicionada, a persistência instalada e dados do host enviados. Isso não prova acesso remoto em todos os dispositivos. Nem prova roubo de credenciais.

Passo 5: como definir e testar o desligamento?

O desligamento precisa cobrir a distribuição e a execução em máquinas já expostas. Antes da compra, segurança e operações definem quem retira um pacote do canal, quem bloqueia a execução nos endpoints gerenciados e quem isola um dispositivo com evidência de comprometimento.

Compras e jurídico registram no contrato quais medidas de desligamento cabem ao fornecedor e quais ao canal, após confirmar a divisão. A retirada do catálogo não remove persistência instalada. A Cursor informa que removeu as versões, bloqueou a distribuição e reconstruiu o marketplace; desinstalar a extensão pode não bastar. A empresa exige instruções de recuperação verificáveis.

O teste parte do inventário de versões e confirma se as equipes conseguem localizar instalações, bloquear a execução e registrar os responsáveis. O teste simula a chegada de versão nova antes da conferência. Segurança preserva evidências antes da limpeza e verifica o retorno ao uso. A ausência de um indicador não prova que a máquina está limpa.

Com evidência de execução maliciosa, o plano deve permitir isolamento, investigação, remoção da persistência e avaliação de reconstrução do dispositivo. A equipe responsável avalia a rotação de credenciais e sessões a partir de um sistema confiável e registra o resultado.

Como verificar que a compra está pronta para aprovação?

A compra está pronta quando cada requisito tem evidência aceita pela equipe competente e um responsável pela decisão. Lacunas ficam pendentes ou seguem para exceção formal, com risco, prazo, responsável e compensações documentados; uma aprovação comercial isolada não substitui o aceite técnico antes da instalação.

A matriz reúne exigências ao comprador, não garantias de um fornecedor, e organiza a segurança na compra de software em evidências verificáveis.

Aprovado significa que os seis controles foram aceitos para as versões aprovadas. Pendente indica falta de evidência ou teste. A exceção formal exige decisão da autoridade competente, data de revisão e medidas compensatórias; não transforma verificação ausente em verificação concluída.

Quais erros evitar na compra?

Um erro é tratar um documento comercial como um controle que ele não executa. Nota fiscal, hash e remoção do catálogo respondem a perguntas diferentes; a equipe precisa conservar essa distinção no registro e revê-la quando o software mudar de versão.

A nota fiscal documenta a operação a que se refere, enquanto a integridade do arquivo depende de conferência técnica. Um hash copiado do mesmo canal suspeito não comprova autoria. E retirar uma extensão do marketplace não limpa, por si só, as máquinas nas quais ela já executou. São lacunas distintas, com responsáveis distintos.

Perguntas frequentes

A nota fiscal não autentica uma extensão, e retirar um pacote do catálogo não limpa os dispositivos em que ele já executou. A decisão de compra exige evidência técnica. Sem referência confiável, o aceite deve ficar pendente ou seguir para uma exceção formal avaliada pela autoridade competente.

A nota fiscal comprova a autenticidade da extensão?

Não. A NFS-e formaliza a prestação de serviços no escopo descrito pela Receita Federal; não verifica o arquivo instalado. O comprador deve pedir ao fornecedor a identificação do canal e a evidência técnica aplicável, além de pedir ao financeiro a análise do documento da operação.

Um hash igual ao publicado pelo canal basta?

Não quando o arquivo e o hash vêm do mesmo canal que pode ter sido comprometido. A comparação exige referência independente e autenticada para a versão e a plataforma corretas. Sem essa referência ou assinatura verificável, a decisão fica pendente ou segue para exceção formal.

A remoção do catálogo resolve o incidente?

Ela pode interromper novas entregas pelo canal, mas não garante a remoção de chave, processo ou persistência nos endpoints. Segurança deve investigar os dispositivos expostos e seguir o plano documentado de contenção e recuperação. A ausência isolada de um indicador também não comprova limpeza.

Quem deve aprovar a compra?

Compras coordena a decisão comercial, mas engenharia e segurança devem aceitar as evidências técnicas e o teste de desligamento. Jurídico avalia os compromissos negociados e financeiro confere a documentação da operação. Quando há lacuna, a autoridade interna de risco decide sobre a exceção documentada.

Referências e Leitura Complementar

As fontes a seguir tratam de pontos diferentes da decisão de compra: o aviso da Cursor descreve o incidente e seus indicadores, enquanto a Receita Federal explica a finalidade documental da NFS-e. Nenhuma delas comprova a integridade do arquivo. Contrato assinado não substitui prova técnica.

• Cursor: aviso de segurança da extensão
• Receita Federal: emissão de NFS-e de padrão nacional

Como tornar a próxima compra operacional?

A instalação não deve ser liberada apenas porque o contrato foi assinado ou a nota chegou. A próxima aquisição deve sair com canal autorizado, evidência de procedência de software e responsável pela contenção registrados. O Nexforce Marketplace pode estruturar a contratação local; a verificação do artefato e a resposta técnica continuam exigindo responsáveis e provas próprias.