原文发表于 Bug Circuit 博客。

客户的采购或法务团队刚刚发来一份包含 40 个问题的电子表格，内容涉及渗透测试、漏洞管理和加密标准，而你所在的公司只有两个人，没有安全团队。以下是简要说明。

你不需要 SOC 2 或内部安全团队就能通过供应商问卷——你需要的是诚实、具体的回答，并附上真实证据，而最近的第三方安全评估是可附上的最有用的证据。

本文其余部分将逐一解析你实际会遇到的问题，解释每道题的真实意图，并提供可直接复制和调整的措辞，既不撒谎，也不拖延交易。

他们为什么会问这些问题

供应商安全问卷存在的原因是：如果你遭遇安全事件，导致客户数据通过你的系统泄露，你的客户公司也要承担责任。这不是针对个人，且这些问卷很少像你感觉的那样被仔细阅读——大多数时候这只是法务或采购团队的合规核查项，一名初级分析师会根据评分标准打分。含糊其辞或沉默不语，比诚实地说“我们规模小，以下是我们实际在做的事”看起来更糟。

如果你想知道是否需要安全审计才能赢得合同：通常没有单一的审计是强制要求，但拥有一份具体的东西可供参考，能让停滞的邮件线程在五分钟内获得批准。

解析常见问题

“你们是否定期进行渗透测试？”

他们真正想确认的是：除了你们自己的开发人员，是否还有其他人尝试入侵你的应用，以及你们是否修复了发现的问题。

如果尚未进行过渗透测试，诚实的回答方式是：直接说明，然后展示你确实做过的事。“我们没有持续的渗透测试计划。我们曾在[日期]对[范围]进行了手动安全评估，并已修复发现的问题；报告已附上。”一份最近的手动审计报告，远比空泛的“是”更有说服力——当评审人员要求查看报告而你无法提供时，他们能立即分辨出区别。

“请描述你们的漏洞管理流程”

这个问题是在问：当出现新的漏洞或 CVE 时，你们如何获知，并以多快的速度进行修补？你不需要正式的 SLA 文档也能诚实回答。一个真实的小团队流程可能是：“我们使用[托管平台]的操作系统和依赖项自动安全更新，在每次发布前运行 npm audit / composer audit，并订阅主要框架的安全公告。关键问题会在披露后几天内修补。”写下你实际在做的事——大多数评审人员只是想确认存在流程，而不是特定的工具栈。

“你们是否有 SOC 2 报告或 ISO 27001 认证？”

SOC 2 是由持牌注册会计师事务所对内部控制进行为期数月的审计，通常花费数千美元——它是为拥有数十名员工和专职合规人员的公司设计的，而不是为五人规模的 SaaS 公司准备的。如果你没有 SOC 2，请直接说明，并提供最接近的真实替代方案：

  • 针对你们实际产品的最近的手动安全审计报告（而不是泛泛的公司级审计）
  • 云服务商自身的合规证明（AWS、GCP 和 Azure 均会发布其基础设施的 SOC 2 / ISO 报告——你们可以继承部分覆盖范围）
  • 关于访问控制、加密和备份实践的书面总结

回答“我们未获得 SOC 2 认证，但附上我们最新的审计报告以及云服务商的合规文档”，既能回应潜在担忧，又不会假装拥有实际上没有的东西。

“你们如何对传输中和静态数据进行加密？”

这个问题通常可以自信地回答。传输中：“所有流量均通过 HTTPS/TLS 1.2+ 提供服务；HTTP 请求会被重定向到 HTTPS。”你可以通过 我们的免费安全头检查工具 验证并加强这一设置——它可以确认是否设置了 Strict-Transport-Security（基线值可设为 max-age=31536000; includeSubDomains），并标记缺失的头信息，如 Content-Security-Policy 或 X-Content-Type-Options: nosniff。静态数据：大多数托管数据库（RDS、Cloud SQL、MongoDB Atlas、Supabase）默认会对存储进行加密——请检查服务商的控制台，并说明实际机制，例如“由[服务商]管理的 AES-256 静态加密”。

“你们是否有事件响应计划？”

他们想知道如果发生问题，你们是否会沉默两周。这不需要是 20 页的文档。一个简短而真实的回答即可：“如果我们检测到安全事件，我们会隔离受影响的系统，评估范围，在 72 小时内通知受影响的客户，并记录根本原因和修复措施。”如果你从未考虑过这个问题，现在就写下来——这是本清单中最容易解决的一项。

“谁可以访问生产数据，访问如何管理？”

诚实地列出：有多少人，是否使用唯一登录和多因素身份验证，是否在有人离职时撤销访问权限。“两名团队成员拥有生产访问权限，均通过 MFA 保护的账户；访问权限每季度审查一次，并在离职时立即撤销”——即使对于小团队，这也是完整且可信的回答。

“我们只运行过一次扫描器”不等于真正的审计

很多小团队都曾用自动化扫描器扫描过自己的网站，并获得一份干净的报告。这值得一提，但要准确说明它能证明什么：自动化扫描器仅检查已知特征——过时的软件版本、缺失的头信息、常见配置错误。它们无法串联业务逻辑漏洞，无法测试一个客户是否能看到另一个客户的数据，也无法发现密码重置流程泄露账户存在性。如果你想了解两者机制的实际区别，我们关于手动与自动化渗透测试的指南对此进行了详细说明。看过数百份问卷的评审人员通常能分辨“我们运行过免费扫描器”和“有人实际测试过”，所以不要过度夸大扫描结果——准确描述，并尽可能搭配更有力的证据。

实际应附上哪些材料

如果你希望用一份文档同时回答渗透测试问题、漏洞管理问题以及一半的加密问题，那么请进行手动审计并附上报告。它不需要是企业级的、多周的审计才能可信——它只需要是最近的、针对你实际网站的、由人工测试而非脚本生成的。

在花费任何费用之前，你可以免费了解自己的现状：运行 免费的被动安全检查 以发现明显暴露，或使用 我们的电子邮件欺骗工具 检查邮件设置（如果问卷还询问钓鱼/域名保护，SPF/DKIM/DMARC 记录是常见的跟进问题）。如果你想在承诺前了解定价，我们的渗透测试成本分析 解释了为什么企业级渗透测试费用可达五位数，以及产品化手动审计如何定位于此之下。

总结

不要撒谎，不要留空字段，也不要将免费扫描结果伪装成渗透测试。用你实际的设置如实回答每个问题，用真实证据支持重大声明，并在提交前修复可以低成本解决的问题（安全头、MFA、书面事件计划）。对于你可能暂时无法诚实回答的问题——真实安全测试的证明——手动审计是弥合这一差距最快、最经济的方式。

如果你希望在下一次问卷到来前就掌握这些证据，Circuit 是一次性 49 美元的手动审计：真实工程师会测试你的网站，并提供包含严重性评级和具体修复建议的书面报告——你可以直接将其附在供应商问卷中，而非留空。