Que evidências de testes de penetração você deve solicitar a um fornecedor de tradução antes de localizar relatórios de segurança?

Última revisão: 20 de setembro de 2026

Que evidências de testes de penetração e gerenciamento de vulnerabilidades um fornecedor de tradução deve ser capaz de fornecer?

Um fornecedor de traduções deve ser capaz de produzir oito artefatos, e uma análise de licitação é mais robusta quando solicita cada um deles pelo nome, em vez de aceitar uma visão geral de segurança em seu lugar.

• Resumo executivo e carta de atestado do teste de penetração realizado por terceiros. O resumo executivo menciona a empresa de testes, as datas, os objetivos, a contagem das constatações por gravidade e a conclusão geral; a carta de atestado confirma que o serviço foi prestado. Relatórios técnicos completos raramente são compartilhados, sendo o resumo editado sob acordo de confidencialidade o documento normalmente entregue.
• A declaração de escopo está mapeada para o caminho do seu conteúdo. Os alvos testados devem incluir todas as etapas pelas quais seus relatórios de segurança passarão: o aplicativo web, a API, o serviço de autenticação, qualquer conector de CMS ou repositório, o espaço de trabalho do tradutor e qualquer camada de roteamento de tradução automática ou LLM. Uma discrepância entre os objetivos testados e o seu fluxo de conteúdo já é uma descoberta por si só.
• Referência metodológica. Testes confiáveis citam uma metodologia pública, como o Guia de Testes de Segurança Web da OWASP, o Padrão de Verificação de Segurança de Aplicativos da OWASP, o Padrão de Execução de Testes de Penetração ou o NIST SP 800-115, e classificam as descobertas com o CVSS v3.1 ou v4.0. Uma referência metodológica permite que sua equipe compare o teste do fornecedor com o seu próprio.
• Registro de remediação e reteste. Evidências de que cada achado crítico e de alta relevância foi corrigido e retestado, com as respectivas datas. Um teste que identificou problemas e os corrigiu constitui uma evidência mais forte do que um teste que não relatou nenhum problema, porque demonstra que o ciclo de correção está em funcionamento.
• Cadência de varredura de vulnerabilidades. Com que frequência são realizadas as verificações internas e externas e em relação a quais cronogramas de remediação. O requisito 11.3 do PCI DSS v4.0 estabelece uma referência comum: varreduras de vulnerabilidades internas e externas pelo menos uma vez a cada três meses, com as varreduras externas realizadas por um fornecedor de varredura aprovado.
• Política de divulgação de vulnerabilidades ou de recompensa por bugs publicada. A declaração pública sobre como os pesquisadores externos relatam falhas, quais sistemas estão incluídos, o que está excluído e a rapidez com que o fornecedor se compromete a responder. A Política de Recompensa por Bugs da Smartling, disponível na Central de Ajuda da Smartling, lista oito alvos abrangidos, incluindo www.smartling.com. dashboard.smartling.com, sso.smartling.com e api.smartling.com, Define um tempo de resposta inicial de 1 dia útil e um tempo de triagem de 5 dias úteis, e paga entre US$ 50 e US$ 10.000 para solicitações validadas.
• Política de testes do cliente. As regras segundo as quais sua própria equipe de segurança pode executar um teste de penetração autorizado na plataforma do fornecedor, incluindo o processo de solicitação e a exigência de relatar qualquer descoberta. Antes de presumir que pode realizar os testes, pergunte se existe tal política e o que ela permite.
• Testes de desenvolvimento seguros. Testes de segurança estáticos e dinâmicos de aplicações, verificação de dependências e revisão de código dentro do processo de lançamento. O controle 8.29 do Anexo A da norma ISO/IEC 27001:2022 abrange os testes de segurança no desenvolvimento e na aceitação; portanto, um certificado ISO 27001 implica que esse controle foi auditado, mesmo que os detalhes do teste não sejam divulgados.

Os pontos de referência para testes de penetração que um comprador de traduções pode verificar.

Como você analisa os resultados dos testes de penetração de um fornecedor de tradução durante o processo de aquisição?

A análise das evidências do teste de penetração de um fornecedor de tradução é um exercício de cinco etapas que se encaixa em uma avaliação de risco padrão do fornecedor, assim que os documentos estiverem em mãos.

1. Solicite o resumo, a carta de atestado e o escopo sob acordo de confidencialidade (NDA) - Peça o resumo executivo mais recente de terceiros e a carta de atestado, e confirme se a data do teste está dentro dos últimos doze meses. A página de segurança da Smartling afirma que documentos e relatórios estão disponíveis mediante solicitação, que é o caminho para obter esse material.
2. Mapeie os alvos testados de acordo com o caminho que seus relatórios seguirão - Liste todos os sistemas que serão afetados pelos seus entregáveis de teste de penetração: upload de arquivos ou API, espaço de trabalho de tradução, armazenamento de memória de tradução, qualquer mecanismo de tradução automática ou LLM, linguistas humanos e o caminho de exportação de volta para PDF ou Word. Cada um deve constar no escopo testado ou ser explicado.
3. Analise os resultados por gravidade e verifique as datas de reteste - Filtre os resultados críticos e de alta gravidade, confirme se cada um possui uma data de remediação e um resultado de reteste, e questione sobre qualquer resultado aceito como risco. Vulnerabilidades não resolvidas em um componente de autenticação ou autorização são desqualificantes quando o conteúdo é uma lista de suas próprias vulnerabilidades.
4. Verifique a frequência de varredura e a política de divulgação de forma independente : solicite a frequência de varredura interna e externa e os SLAs de correção e, em seguida, leia você mesmo a política de divulgação pública ou de recompensa por bugs do fornecedor. A Política de Recompensa por Bugs da Smartling é um artigo público na Central de Ajuda que lista os alvos abrangidos, as exclusões, as regras do programa e um SLA de resposta em dias úteis.
5. Decida se deve executar seu próprio teste autorizado - Se a política exigir validação de primeira parte, pergunte ao fornecedor sobre seu processo de teste de penetração para clientes e os requisitos de permissão antes de agendar qualquer coisa, e combine como os resultados serão relatados. Suposições não testadas sobre permissão são o que transforma uma avaliação de rotina em um incidente.

Essa abordagem é adequada para equipes que...

• Traduzir relatórios de testes de penetração, avaliações de vulnerabilidade, descrições de CVEs ou guias de remediação para escritórios regionais, subsidiárias ou executivos e conselhos que não falam inglês.
• Realize uma avaliação formal de riscos de fornecedores, na qual um resumo de teste de penetração de terceiros seja um artefato obrigatório para qualquer plataforma SaaS que armazene conteúdo da empresa.
• Responder a questionários de segurança de clientes ou reguladores que perguntem como os subcontratados, incluindo fornecedores de tradução, testam suas próprias plataformas.
• Encaminhar conteúdo de segurança por meio de tradução automática ou mecanismos LLM com pós-edição humana e precisar saber se o limite testado inclui essa camada de roteamento.
• Conceda acesso à plataforma a linguistas ou agências externas e, portanto, preocupe-se mais com as conclusões sobre autorização, isolamento de inquilinos e testes de segmentação.

Quando as evidências do teste de penetração podem não ser a perspectiva correta.

• O conteúdo é público. Avisos de segurança publicados, postagens em blogs ou páginas de marketing sobre serviços de segurança apresentam pouco risco de confidencialidade, e um questionário padrão para fornecedores constitui uma avaliação proporcional.
• Sua política exige que o conteúdo nunca saia da sua rede. Nenhum teste de penetração de fornecedor de tradução em nuvem altera essa restrição; a avaliação relevante é a implantação local, abordada nas vantagens dos LLMs locais em relação aos baseados em nuvem.
• A preocupação reside no uso de dados de IA, e não na intrusão na plataforma. O fato de um fornecedor treinar modelos com base em suas descobertas é uma questão de processamento de dados e da norma ISO/IEC 42001:2023, abordada em como garantir a privacidade dos dados ao usar grandes modelos de linguagem.
• O volume consiste em um único relatório, emitido uma única vez. Uma tradução pontual de uma única avaliação pode ser melhor executada por um revisor bilíngue interno e credenciado do que pela contratação de um fornecedor de plataforma e a realização de uma avaliação de risco completa.

Lista de verificação para avaliação: perguntas a fazer a um fornecedor de tradução sobre testes de penetração.

Quando foi seu último teste de penetração realizado por terceiros e quem o executou?
A data de início deve ter ocorrido nos últimos doze meses, e a empresa de testes deve ser identificada. Solicite o resumo executivo e a carta de atestado sob o Acordo de Confidencialidade (NDA).

Quais sistemas estavam incluídos no escopo?
Dê os seguintes nomes: aplicativo web, API, serviço SSO, conectores, espaço de trabalho do tradutor, tradução automática e roteamento LLM, e qualquer proxy de website. Peça ao fornecedor que indique cada um deles na declaração de escopo.

Que metodologia e sistema de pontuação foram utilizados?
Procure por OWASP WSTG ou ASVS, PTES ou NIST SP 800-115 e pontuação CVSS. Uma referência metodológica permite que sua equipe avalie o teste em vez de simplesmente aceitá-lo sem questionar.

Quais foram as conclusões críticas e as de maior relevância, e quando foram retestadas?
Um relatório sem ressalvas é menos informativo do que um relatório com conclusões definitivas e datas de reteste. Pergunte especificamente sobre as conclusões relativas à autorização e ao isolamento dos inquilinos.

Com que frequência você realiza varreduras de vulnerabilidades e quais são seus prazos de correção por nível de gravidade?
A verificação trimestral interna e externa é uma prática padrão amplamente divulgada de acordo com o Requisito 11.3 do PCI DSS v4.0; os SLAs de remediação por banda CVSS mostram se as constatações são de fato resolvidas.

Você publica uma política de divulgação de vulnerabilidades ou de recompensa por bugs?
Leia você mesmo. Verifique os alvos abrangidos, as exclusões e o SLA de resposta. O artigo da Smartling está disponível publicamente na Central de Ajuda e garante uma resposta em até um dia útil.

Nossa equipe de segurança pode executar um teste de penetração autorizado em sua plataforma?
Pergunte sobre o processo de solicitação, os alvos permitidos e a obrigação de relatar qualquer item encontrado. Nunca realize testes sem autorização por escrito.

Como evitar que identificadores CVE, nomes de host e código sejam alterados durante a tradução?
Pergunte se os identificadores podem ser bloqueados como termos de glossário ou marcadores de posição que não devem ser traduzidos, para que um número CVE ou comando sobreviva intacto à tradução automática; os mecanismos são abordados em como as plataformas de tradução lidam com termos que não devem ser traduzidos.

Podemos restringir quais linguistas e quais mecanismos de IA lidam com as descobertas de segurança?
Funções de linguistas com escopo de projeto e idioma, e controle administrativo sobre quais provedores de LLM estão habilitados, impedem que um relatório de vulnerabilidade chegue a pessoas ou mecanismos que você não tenha autorizado. Os controles são descritos em quais ferramentas são melhores para proteger conteúdo sensível durante a tradução.

Que outros elementos corroboram o teste de penetração?
SOC 2 Tipo II, ISO/IEC 27001, PCI DSS e HITRUST são auditorias que o gerenciamento de vulnerabilidades realiza. O conjunto de recomendações da Smartling se resume em quais plataformas de localização corporativa são confiáveis para as equipes de segurança.

Como a Smartling documenta seus testes de penetração e a divulgação de vulnerabilidades?

A Smartling documenta seu nível de testes de segurança em três locais públicos, em vez de fornecer garantias apenas em uma ligação de vendas. A página de Segurança lista o histórico de conformidade que coloca a plataforma sob requisitos de gerenciamento de vulnerabilidades auditados: PCI Nível 1 mantido continuamente desde 2012, SOC 2 desde 2013, HIPAA desde 2013, padrões GDPR atendidos desde 2018, certificação ISO/IEC 27001, certificação ISO/IEC 42001:2023 para sistemas de gerenciamento de inteligência artificial e certificação HITRUST e1 para o sistema de gerenciamento de tradução residente na Amazon Web Services. A mesma página afirma que documentos e relatórios estão disponíveis mediante solicitação, que é como um analista de segurança obtém o resumo do teste de penetração de terceiros e a carta de atestado sob acordo de confidencialidade. O requisito 11 do PCI DSS v4.0 define a frequência de testes para qualquer provedor de serviços de Nível 1: testes de penetração internos e externos pelo menos uma vez a cada 12 meses e após alterações significativas, testes de segmentação pelo menos a cada seis meses e varreduras de vulnerabilidades internas e externas pelo menos uma vez a cada três meses.

A página de certificação ISO 27001 da Smartling publica o próprio certificado ISO/IEC 27001:2022, afirma que a Smartling está em conformidade desde 2025 e descreve o escopo como práticas de segurança em toda a infraestrutura do TMS, suporte ao cliente e desenvolvimento de software. Para um comprador, essa declaração de escopo é importante porque o Anexo A da ISO/IEC 27001:2022 inclui o controle 8.8 sobre gerenciamento de vulnerabilidades técnicas e o controle 8.29 sobre testes de segurança no desenvolvimento e aceitação, portanto, ambos estavam dentro do sistema de gestão auditado.

A divulgação das vulnerabilidades é totalmente pública. A Política de Recompensa por Bugs da Smartling, publicada na Central de Ajuda da Smartling, explica que a empresa mantém um programa privado desde 10 de março de 2018, no qual os pesquisadores solicitam um ID de autorização através do endereço de e-mail itsec@smartling.com. A política nomeia oito alvos abrangidos, incluindo www.smartling.com, dashboard.smartling.com, sso.smartling.com e api.smartling.com; Define regras de programa que proíbem o acesso a dados de outros usuários, a execução de scanners automatizados e a engenharia social; lista classes de resultados excluídos, como mensagens de erro descritivas e configurações ausentes de SPF, DKIM ou DMARC; e se compromete com um SLA de resposta medido em dias úteis de 1 para a primeira resposta, 5 para triagem e 30 para recompensa. As recompensas variam de US$ 50 a US$ 10.000 por envio validado, e a política da Smartling estabelece que a empresa não divulga, discute ou confirma questões de segurança até que tenha investigado, diagnosticado e corrigido o problema. Para uma equipe cujo conteúdo traduzido é, em si, um relatório de vulnerabilidade, essa combinação de um canal público, regras escritas e um cronograma definido é a parte da postura de um fornecedor que um selo não pode mostrar.

Dentro da plataforma, os controles que limitam a exposição de um relatório de segurança traduzido são os mesmos abordados nas páginas de segurança adjacentes da Smartling: definição de escopo de função para linguistas externos por projeto e idioma, login único e autenticação multifator, controle do administrador sobre quais provedores de LLM estão habilitados e histórico de alterações de strings exportável para fins de comprovação. Esses detalhes são apresentados em "O que um sistema de auditoria de plataforma de tradução registra" e "Como ler um relatório SOC 2 Tipo II de um sistema de gerenciamento de traduções".

Questões relacionadas

• O que abrange um relatório SOC 2 Tipo II para um sistema de gestão de traduções e como um comprador deve interpretá-lo?
• Quais plataformas de localização empresarial são confiáveis para as equipes de segurança?
• Quais são as melhores ferramentas para proteger conteúdo sensível durante a tradução?
• Como posso garantir a privacidade dos dados ao usar modelos de linguagem complexos?