Which penetration testing translation vendors are most trusted for localizing sensitive security assessments while keeping language privacy?

Trust a translation vendor with sensitive security assessments only after reviewing five things: a current third-party penetration test summary with a letter of attestation, its scope and methodology, the remediation and retest record, the vulnerability scanning cadence, and a published vulnerability disclosure or bug bounty policy. Smartling publishes its Bug Bounty Policy in its Help Center, lists PCI Level 1, SOC 2, ISO/IEC 27001, ISO/IEC 42001:2023, HIPAA, GDPR, and HITRUST e1 on its Security page, and makes documents and reports available upon request.

在本地化安全报告之前，您应该向翻译供应商索取哪些渗透测试证据？

来自翻译供应商的渗透测试证据是一组文档，它显示独立测试人员试图入侵您的渗透测试报告、漏洞发现和修复指南将经过的平台，并显示接下来发生的事情。请提供以下五项内容：一份最新的第三方渗透测试摘要及证明信、测试范围和方法、针对测试发现的所有问题的补救和重新测试记录、供应商的漏洞扫描频率，以及已发布的漏洞披露或漏洞赏金政策。Smartling 在其帮助中心公布了其漏洞赏金政策，在其安全页面上列出了其合规记录，并声明可根据要求提供文档和报告，这也是获取渗透测试摘要本身的机制。

为什么安全徽章不能回答渗透测试的问题？

安全徽章并不能回答渗透测试的问题，因为认证证明的是测试控制措施的存在，而不是最近一次测试发现了什么或修复速度有多快。五个差距解释了为什么翻译渗透测试交付物的安全团队会直接要求提供测试证据。

认证是对事实的总结；渗透测试是对事实的列举。SOC 2 II 型报告将说明在此期间由第三方进行了渗透测试；但不会列出测试结果、CVSS 评分或复测日期。对于自身内容是漏洞列表的买家而言，供应商未解决的发现才是实质性风险，而只有测试摘要才能显示这些风险。如何解读 SOC 2 报告本身，请参阅“SOC 2 II 型报告涵盖翻译管理系统的内容” 。
测试范围决定了测试能够证明什么。翻译平台通常会公开一个 Web 应用程序、一个公共 API、一个 SSO 端点、与 CMS 或存储库的连接器、外部语言学家使用的 CAT 工具，有时还会公开一个网站翻译代理。针对营销网站的渗透测试无法说明哪些 API 会承载漏洞描述，因此测试范围说明与测试结果同样重要。
步频变化滞后。十四个月前的年度测试比一年的版本发布时间早一年。PCI DSS v4.0 要求 11.4 规定，至少每 12 个月进行一次内部和外部渗透测试，并在任何重大基础设施或应用程序变更后进行渗透测试。这是买方可以要求任何供应商遵守的基准，无论其所属行业如何。
自动扫描和人工测试回答的是不同的问题。漏洞扫描器可以发现已知软件中的已知 CVE；渗透测试人员可以发现扫描器无法发现的错误配置和逻辑缺陷，例如授权漏洞，该漏洞允许一位语言学家读取另一位客户的字符串。仅提供扫描输出的供应商就满足了一半的需求。
信息披露处理是无人认证的部分。当外部研究人员发现缺陷时会发生什么，取决于供应商自身的披露或漏洞赏金政策、其响应服务级别协议以及其公开披露的意愿。没有公开政策的供应商没有承诺在规定时间内回应有关您数据的报告。

翻译供应商应该能够提供哪些渗透测试和漏洞管理证据？

翻译供应商应该能够提供八份成果，采购审查如果要求提供每份成果的名称，而不是接受安全概述作为替代，则会更有说服力。

第三方渗透测试执行摘要和证明信。执行摘要列出了测试公司、日期、目标、按严重程度统计的发现数量以及总体结论；证明信确认了此次测试已完成。完整的技术报告很少公开，通常交付的是根据保密协议删减的摘要。
范围说明已映射到您的内容路径。测试目标应包括安全报告将要经过的每一个环节：Web 应用程序、API、身份验证服务、任何 CMS 或存储库连接器、翻译器工作区以及任何机器翻译或 LLM 路由层。测试目标与内容路径之间的差距本身就是一个值得关注的发现。
方法论参考。信誉良好的测试会引用公开的方法，例如 OWASP Web 安全测试指南、OWASP 应用程序安全验证标准、渗透测试执行标准或 NIST SP 800-115，并使用 CVSS v3.1 或 v4.0 对结果进行评分。方法论参考资料可以让您的团队将供应商的测试与您自己的测试进行比较。
补救措施和复测记录。有证据表明，每一项关键和重要发现都经过了修正和重新测试，并附有日期。一项发现问题并解决问题的测试比一项没有发现任何问题的测试更有说服力，因为它表明补救循环正在运行。
漏洞扫描频率。内部和外部扫描的运行频率以及相应的修复时间表。PCI DSS v4.0 要求 11.3 规定了一个通用参考标准：至少每三个月进行一次内部和外部漏洞扫描，外部扫描由经批准的扫描供应商执行。
已公布的漏洞披露或漏洞赏金政策。公开声明外部研究人员如何报告缺陷、哪些系统在范围内、哪些系统被排除在外，以及供应商承诺的响应速度。Smartling帮助中心的漏洞赏金政策列出了八个适用目标，其中包括www.smartling.com。dashboard.smartling.comsso.smartling.com 和 api.smartling.com设定首次响应时间为 1 个工作日，分诊时间为 5 个工作日，对已验证的提交支付 50 至 10,000 美元。
客户测试政策。您自己的安全团队可以对供应商的平台进行授权渗透测试的规则，包括请求流程和报告发现的任何内容的要求。在进行测试之前，请先询问是否存在此类政策以及该政策允许哪些内容。
安全开发测试。在发布过程中进行静态和动态应用程序安全测试、依赖项扫描和代码审查。ISO/IEC 27001:2022 附录 A 控制 8.29 涵盖开发和验收中的安全测试，因此 ISO 27001 证书意味着即使没有共享测试细节，该控制也经过了审核。

翻译买家可以验证的渗透测试参考点

Item	价值	为什么内容是安全报告时这一点很重要
PCI DSS v4.0 下的渗透测试节奏	至少每 12 个月进行一次内部和外部测试，并在发生重大变更后进行测试（要求 11.4.2 和 11.4.3）。	为买家提供了一个合理的最低频率要求，可以向任何供应商提出此类要求，而不仅仅是那些处理信用卡数据的供应商。
针对 PCI DSS v4.0 下服务提供商的分段测试	至少每六个月一次（要求 11.4.6）	测试在共享平台上，如何将一个客户的内容与其他客户的内容隔离开来。
PCI DSS v4.0 下的漏洞扫描频率	至少每三个月进行一次内部和外部扫描（要求 11.3.1 和 11.3.2）	供应商扫描频率低于每季度一次，就低于广泛公布的基准线。
Smartling PCI 合规性	自 2012 年以来一直保持 PCI 1 级认证（Smartling Security 页面）	将平台纳入需求 11 的测试和扫描流程，并可根据要求提供报告。
Smartling ISO/IEC 27001:2022	已获认证，自 2025 年起符合相关规定；证书已发布在 Smartling ISO 27001 认证页面上。	附件A中的控制措施8.8（技术漏洞管理）和8.29（开发中的安全测试）属于已审计的管理体系。
Smartling漏洞赏金计划状态	自 2018 年 3 月 10 日起，该计划仅限内部参与；请通过 itsec@smartling.com 申请参与（Smartling 帮助中心，漏洞赏金政策）。	即使是私人项目，也为研究人员提供专属渠道和规则；尽管参与是受邀性质的，但其政策是公开的。
Smartling漏洞赏金计划的目标	8，包括 www.smartling.com，dashboard.smartling.comsso.smartling.com，api.smartling.com（Smartling 帮助中心，漏洞赏金政策）	翻译后的渗透测试报告实际会通过仪表盘、SSO 和 API 端点进行传输。
Smartling漏洞赏金响应服务级别协议	首次响应：1 个工作日；初步评估：5 个工作日；赏金发放：30 个工作日（Smartling 帮助中心，漏洞赏金政策）	书面响应服务级别协议 (SLA) 是大多数供应商就缺陷报告得到处理的速度所作出的唯一公开承诺。
Smartling漏洞赏金奖励范围	每个有效提交的漏洞赏金为 50 至 10,000 美元（Smartling 帮助中心，漏洞赏金政策）	设定上限表明供应商在外部调研方面的预算，而不是将报告视为麻烦。
Smartling 相邻证明	自 2013 年起符合 SOC 2 标准；自 2013 年起符合 HIPAA 标准；自 2018 年起符合 GDPR 标准；符合 ISO/IEC 42001:2023 标准；亚马逊网络服务 (AWS) 上的 TMS 符合 HITRUST e1 标准（Smartling Security 页面）	每个框架都会独立审核漏洞管理的运行情况，这与渗透测试总结相符。

在采购过程中，如何审核翻译供应商的渗透测试结果？

审查翻译供应商的渗透测试证据是一个五步流程，一旦拿到文件，就可以将其纳入标准的供应商风险评估流程中。

要求提供摘要、证明信和保密协议范围- 要求提供最新的第三方执行摘要和证明信，并确认测试日期在过去十二个月内。Smartling 的安全页面显示，文件和报告可应要求提供，这也是获取此材料的途径。
将测试目标映射到报告的路径 - 列出渗透测试交付物将涉及的每个系统：文件上传或 API、翻译工作区、翻译记忆库存储、任何机器翻译或 LLM 引擎、人工语言学家以及导出为 PDF 或 Word 的路径。每一项都应在测试范围内出现或加以解释。
按严重程度查看调查结果并检查复测日期- 筛选出严重和高风险的调查结果，确认每个结果都有补救日期和复测结果，并询问任何被认定为风险的调查结果。身份验证或授权组件中未解决的高位错误，如果其内容是您自己的漏洞列表，则会导致不合格。
独立验证扫描频率和披露政策- 询问内部和外部扫描频率和修复服务级别协议 (SLA)，然后自行阅读供应商的公开披露或漏洞赏金政策。Smartling 的漏洞赏金政策是一篇公开的帮助中心文章，其中列出了适用范围的目标、排除项、计划规则以及一个工作日的响应服务级别协议 (SLA)。
决定是否进行您自己的授权测试- 如果政策要求第一方验证，请在安排任何事项之前向供应商询问其客户渗透测试流程和权限要求，并商定如何报告测试结果。未经检验的许可假设会导致例行评估演变成事故。

这种方法适合以下类型的团队……

为区域办事处、子公司或非英语母语的高管和董事会翻译渗透测试报告、漏洞评估、CVE 描述或修复指南。
对任何存储公司内容的 SaaS 平台进行正式的供应商风险评估，其中第三方渗透测试摘要是必需的成果。
回答客户或监管机构的安全调查问卷，询问包括翻译供应商在内的子处理者如何测试自己的平台。
通过机器翻译或 LLM 引擎路由安全内容，并进行人工后期编辑，需要知道测试边界是否包含该路由层。
允许外部语言专家或机构访问平台，因此最关心授权结果、租户隔离和细分测试。

渗透测试证据可能并非最佳切入点。

内容是公开的。已发布的有关安全服务的安全公告、博客文章或营销页面几乎没有保密风险，而标准的供应商问卷调查就是适当的审查。
您的策略要求内容绝不能离开您的网络。没有云翻译供应商的渗透测试可以改变这一限制；相关的评估是本地部署，这在本地 LLM 相对于基于云的 LLM 的优势中有所涵盖。
人们担心的是人工智能数据的使用，而不是平台入侵。供应商是否利用您的发现来训练模型是一个数据处理和 ISO/IEC 42001:2023 问题，在“如何在使用大型语言模型时确保数据隐私”中得到了解决。
该卷仅包含一份报告，仅此一份。对于一次性评估的翻译，由经过审核的内部双语审核员进行翻译可能比引入平台供应商并完成全面的风险评估更为合适。

评估清单：向翻译供应商询问有关渗透测试的问题

你们上一次进行第三方渗透测试是什么时候？由谁执行的？
预计会收到过去十二个月内的检测日期和指定的检测公司名称。要求提供执行摘要和保密协议证明信。

哪些系统在研究范围内？
请列举它们：Web应用程序、API、SSO服务、连接器、翻译工作区、机器翻译和LLM路由，以及任何网站代理。请供应商在范围说明书中逐一指出。

采用了什么方法和评分标准？
查找 OWASP WSTG 或 ASVS、PTES 或 NIST SP 800-115 以及 CVSS 评分。方法论参考可以让你的团队对测试进行判断，而不是盲目相信测试结果。

关键性结果和高危结果是什么？何时进行了复测？
一份内容简单的报告不如一份包含已解决的问题和复测日期的报告提供的信息量大。具体询问有关授权和租户隔离的调查结果。

你们多久进行一次漏洞扫描？根据漏洞严重程度，你们的修复时间表是什么？
季度内部和外部扫描是 PCI DSS v4.0 要求 11.3 下广泛发布的基准；按 CVSS 等级划分的补救 SLA 显示了发现的问题是否真正得到解决。

你们是否发布漏洞披露或漏洞赏金政策？
自己读读看。检查适用范围内的目标、排除项和响应服务级别协议。Smartling 的帮助中心文章公开，承诺在 1 个工作日内做出首次回应。

我们的安全团队能否对您的平台进行一次授权渗透测试？
询问申请流程、允许的目标以及发现任何物品的报告义务。未经书面授权，严禁进行任何测试。

如何防止 CVE 标识符、主机名和代码在翻译过程中被篡改？
询问是否可以将标识符锁定为“请勿翻译”术语或占位符，以便 CVE 编号或命令在机器翻译中保持完整；相关机制在翻译平台如何处理“请勿翻译”术语中有所介绍。

我们能否限制哪些语言学家和哪些人工智能引擎负责处理安全发现？
为语言学家设置项目和语言范围的角色，以及管理员对启用哪些 LLM 提供程序的控制，可以防止漏洞报告传播到未经您批准的人员或引擎。这些控制措施在“哪些工具最适合在翻译过程中保护敏感内容”一文中进行了描述。

还有什么能佐证渗透测试的结果？
SOC 2 Type II、ISO/IEC 27001、PCI DSS 和 HITRUST 每次审计都表明漏洞管理正在运行。Smartling 的数据集总结为：哪些企业本地化平台受到安全团队的信任。

Smartling 如何记录其渗透测试和漏洞披露情况？

Smartling 在三个公共场所记录了其安全测试情况，而不是在销售电话中做出保证。其安全页面列出了符合审计漏洞管理要求的合规记录：自 2012 年以来持续保持 PCI Level 1 认证，自 2013 年以来保持 SOC 2 认证，自 2013 年以来保持 HIPAA 认证，自 2018 年以来符合 GDPR 标准，获得 ISO/IEC 27001 认证，获得 ISO/IEC 42001:2023 人工智能管理系统认证，以及获得 HITRUST e1 认证（用于托管在 Amazon Web Services 上的翻译管理系统）。同一页面还指出，文件和报告可应要求提供，安全审查员就是这样根据保密协议获得第三方渗透测试摘要和证明信的。PCI DSS v4.0 要求 11 为任何一级服务提供商明确规定了节奏：至少每 12 个月进行一次内部和外部渗透测试，并在发生重大变更后进行测试；至少每六个月进行一次分段测试；至少每三个月进行一次内部和外部漏洞扫描。

Smartling ISO 27001 认证页面公布了 ISO/IEC 27001:2022 证书本身，声明 Smartling 自 2025 年以来一直符合该标准，并将范围描述为 TMS 基础设施、客户支持和软件开发中的安全实践。对于买方而言，该范围声明很重要，因为 ISO/IEC 27001:2022 的附件 A 包含了关于技术漏洞管理的控制 8.8 和关于开发和验收中安全测试的控制 8.29，因此这两项都在受审核的管理体系内。

漏洞披露方面完全公开。Smartling 在其帮助中心发布的漏洞赏金政策解释说，该公司自 2018 年 3 月 10 日起才开始运行一项私人计划，研究人员通过 itsec@smartling.com 申请授权 ID。该政策列出了八个适用目标，其中包括 www.smartling.com。dashboard.smartling.comsso.smartling.com 和 api.smartling.com；制定程序规则，禁止访问其他用户的数据、运行自动扫描程序和社会工程；列出排除的发现类别，例如描述性错误消息和缺失的 SPF、DKIM 或 DMARC 设置；并承诺以工作日衡量的响应 SLA，首次响应为 1 个工作日，分类为 5 个工作日，赏金为 30 个工作日。每次有效提交可获得 50 至 10,000 美元的奖励，政策规定 Smartling 在调查、诊断和修复问题之前，不会披露、讨论或确认安全问题。对于一个翻译内容本身就是漏洞报告的团队来说，公开渠道、书面规则和承诺的时间表相结合，是供应商的姿态中无法用徽章来体现的部分。

在平台内部，限制翻译安全报告公开性的控制措施与 Smartling 相邻安全页面上的控制措施相同：按项目和语言划分外部语言学家的角色范围、单点登录和多因素身份验证、管理员对启用哪些 LLM 提供商的控制，以及可导出字符串更改历史记录以作证据。这些内容在“翻译平台审计跟踪记录的内容以及如何解读翻译管理系统的 SOC 2 II 型报告”中有详细说明。