摘要

  • Adobe 2013 年客户数据泄露、密码存储、源代码外泄、客户重置以及长尾身份问责记录。
  • Adobe 2013 年的客户数据泄露事件暴露了账户记录和源代码风险，同时迫使公司在密码保护、通知以及长尾凭证重用方面进行公开清算。
  • 谁实际控制了密码存储设计、源代码保护、泄露通知、客户重置、暴露字段最小化、和解证据，并证明旧账户系统在披露日期后未继续传递风险？
  • 问责问题的核心在于，泄露前做出的密码存储决策，即便在公司重置账户并将公众注意力转移后，仍会持续带来成本。
  • 客户、开发者、软件采购方、身份风险团队、监管机构、集体诉讼参与者和安全工程师需要证据，证明账户系统修复解决了持久的凭证和源代码风险。

为什么本案应归入风险与问责档案

Adobe 将密码存储证据变成了长尾身份问责考验，因为 2013 年的泄露事件不仅仅是一次披露事件。它成为一次公开教训，展示了旧有账户系统、密码存储选择、客户通知、软件源代码保管以及订阅时代身份依赖，如何在公司告知客户重置密码后继续传递风险。核心问责问题不在于 Adobe 是否最终承认了比最初公开数字更多的受影响账户，而在于公开记录是否让客户和软件采购方理解存储设计和修复的持久后果。

此案距今已久，可能被误记为一段简单的历史。这很危险。Adobe 的旧客户安全公告（http://blogs.adobe.com/conversations/2013/10/important-customer-security-announcement.html）和源代码公告（http://blogs.adobe.com/asset/2013/10/illegal-access-to-adobe-source-code.html）是客户数据和产品源代码泄露的早期公开记录。后续报道，包括 BBC 的报道（https://www.bbc.com/news/technology-24740873），描述了受影响客户数从最初报道的 290 万扩大到约 3800 万活跃用户，并指出了涉及 Photoshop 以及更早提及的 Acrobat 和 ColdFusion 的源代码外泄。数字固然重要，但设计教训更为关键。

密码存储是泄露前的决策，只有在失效后才会公之于众。如果一家公司以有助于攻击者进行猜测的形式存储密码材料，那么重置并不能消除危害。攻击者或许不再需要原始服务。他们可以在其他地方测试相同或相似的凭证，利用密码提示来推断模式，将电子邮件地址与其他暴露的数据结合，并在主站点修复后长期受益于脆弱的存储设计。正因如此，本文将此次泄露事件视为一份长尾身份记录，而非一个暂时性的安全头条。

源代码外泄增加了第二重时间维度。SANS 互联网风暴中心的常见问题解答（https://isc.sans.edu/diary/The+Adobe+Breach+FAQ/16727）在披露后不久便讨论了客户数据、源代码和 ColdFusion 背景。来自 Krebs（http://krebsonsecurity.com/2013/10/adobe-to-announce-source-code-customer-data-breach/）和 Ars Technica（http://arstechnica.com/security/2013/10/adobe-source-code-and-customer-data-stolen-in-sustained-network-hack/）的安全报道也将该事件定性为客户数据和源代码双重泄露。源代码本身并不产生与密码表相同的风险，但它可能通过暴露实现细节、产品假设和潜在漏洞路径而改变攻击者的成本收益。

本文并不将每一条二次声明都视为已证实的内部事实。它区分了 Adobe 的声明、当时的报道、技术分析以及现行标准。当前 Adobe 信任中心页面，如https://www.adobe.com/trust.html和https://www.adobe.com/trust/security.html，用于介绍当前安全计划的术语，而非作为 2013 年控制措施的证明。OWASP 和 NIST 的资料被用作密码和身份原则的参考，而非追溯性的法律结论。这种来源上的严谨性至关重要，因为长尾问责依赖于区分当时已知什么、后来报道了什么，以及哪些仍不在公开记录之内。

密码存储可能在重置后仍传递成本

对泄露密码数据库的常规回应是重置密码。重置是必要的，但它并未回应全部风险。如果原始密码存储允许有意义的离线猜测，那么即便 Adobe 账户无法再用旧密码访问，攻击者也可能了解用户的密码习惯。如果相同或相关的密码在其他地方被重复使用，用户的其他账户可能仍处于暴露之中。如果密码提示以明文或可猜测的形式存在，它们可能继续为攻击者提供帮助。长尾成本落在用户身上，而非仅仅是泄露数据的公司。

Ars Technica 针对密码的分析（http://arstechnica.com/security/2013/11/how-an-epic-blunder-by-adobe-could-strengthen-hand-of-password-crackers/）之所以具有影响力，是因为它解释了密码保护形式为何重要。不应将这篇文章简单归结为技术指责。它提出了一个问责原则：存储设计决定了攻击者在数据被窃取后能提取多少价值。一个强健的系统会假设数据库可能被窃取，并将密码验证器存储在使窃取价值降低的形式中。而脆弱的旧系统则可能将数据库变为密码破解者的训练集。

OWASP 的密码存储速查表（https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html）为这一问题提供了现代词汇：慢速密码哈希、加盐、工作因子、适当加“胡椒”，以及从弱方案迁移。这些概念并非事后装饰。它们定义了用户和审计方需要哪些证据。当一家公司声称密码已被重置时，公开档案仍应追问：淘汰了哪种存储设计、取而代之的新型设计是什么、旧记录如何迁移、非活跃记录是否保留、密码提示或相关账户恢复工件是否已被最小化。

NIST 当前的数字身份指南（https://pages.nist.gov/800-63-4/sp800-63b.html）强化了这样一个观点：身份验证是一个生命周期。它包括颁发、维护、失效、会话控制和追索。密码重置只是该生命周期中的一个事件。泄露后，账户恢复、多因素认证选项、秘密泄露筛查、重新验证以及针对认证问题的追索都至关重要。对于 Adobe 而言，长尾问题在于客户是否获得了足够的证据，以了解其凭证风险可能延伸至 Adobe 账户以外多远的地方。

公开记录表明，为什么“加密”可能是一个不充分的面向用户的词汇。加密、哈希、加盐和密码提示各自具有不同的后果，但许多通知将这些区别压缩为宽泛的保证。用户不需要密码学讲座，但他们确实需要实际结果。攻击者能否逆转或有效猜测旧密码？提示是否暴露？非活跃账户是否包括在内？客户 ID、电子邮件地址、支付记录或其他属性是否与同一文件关联？通知应该回答用户的风险问题，而不仅仅是公司的披露类别。

源代码外泄将泄露事件转变为软件生命周期问题

Adobe 2013 年的事件也属于本系列，因为源代码外泄超越了客户身份。Adobe 旧的源代码公告、SANS 常见问题解答、Krebs 的报道、BBC 的报道以及 Ars Technica 的报道均将该事件视为涉及 Adobe 主要产品或组件的源代码。公开报道提到了 Acrobat、ColdFusion、ColdFusion Builder 以及后来的 Photoshop。问责问题不在于源代码外泄是否自动产生已知漏洞。而在于公司能否证明产品安全审查、漏洞响应和客户指导已相应改变，以匹配新的风险。

软件生命周期和锁定是 Adobe 问责面的核心。许多客户依赖 Adobe 工具进行创意生产、文档工作流、公共部门表单、企业营销和 PDF 处理。他们无法在源代码事件后立即迁移。这种依赖关系赋予供应商一项义务，即提供清晰的产品安全证据：哪些产品受到影响、哪些分支经过审查、哪些补丁或强化措施至关重要，以及客户如何监控后续的安全公告。Adobe 当前的安全公告索引（https://helpx.adobe.com/security/security-bulletin.html）展示了持续更新的公告和补丁词汇，但公众需要从源代码事件到后续产品安全保障之间的桥梁。

源代码保管也是一个治理问题。它涉及仓库访问、隔离、密钥管理、构建控制、代码审查、日志记录、内部和外部访问监控以及事件响应。当前的 Adobe 安全页面，如https://www.adobe.com/trust/security/product-security.html和https://www.adobe.com/trust/security/incident-response.html，描述了当前安全计划的概念，包括安全产品生命周期和事件响应。它们之所以有用，是因为它们展示了一个现代读者应在证据文件中期望看到的内容，尽管它们无法证明 2013 年系统究竟是如何运作的。

长尾风险并不在于攻击者以一种简单的方式永久持有源代码。而在于防御方需要得到保证，即暴露的代码已经通过不同的视角进行了审查。如果攻击者能够检查实现细节，产品团队就应该问：是否将隐蔽性视为一种隐藏的控制措施，共享组件是否需要审查，面向客户的强化指导是否应该改变，历史漏洞是否应该重新审视。公共部门的延续性之所以进入该档案，是因为广泛部署的文档工具和 Web 应用平台可能成为机构性依赖。这种规模的产品安全事件不是私人的不便。

这就是为什么证据文件必须将客户数据和源代码联系起来，而不是将它们视为各自独立的头条新闻。密码泄露影响用户和身份团队。源代码泄露影响开发者、企业和软件采购方。同一次泄露响应需要有不同的轨道，但这些轨道应该共享一个时间线和治理负责人。如果公司告知客户重置密码，而产品团队却在悄悄审查源代码，外部人士无法判断事件是否已被控制。问责要求两条轨道都足够可见，以便依赖该企业的组织制定计划。

通知质量决定用户能否保护其他账户

Adobe 的通知问题不仅在于最初受影响的用户数量，还在于用户除了 Adobe 之外应该做什么这一实际问题。BBC 的报道（https://www.bbc.com/news/technology-24740873）指出，Adobe 重置了密码，但在其他服务上重复使用凭证仍然存在风险。这就是长尾身份问责的核心。公司可以禁用旧的 Adobe 密码。但它无法重置客户重复使用该密码的每一个其他账户。因此，通知必须就凭证风险提供足够的信息，以促使用户在其他地方采取相应的行动。

有效的通知应将几件事分开：活跃账户、非活跃账户、客户 ID、电子邮件地址、加密密码、密码提示、支付卡数据、源代码外泄和重置状态。它还应解释公司尚不能验证的内容。在快速变化的事件中，数字可能会变化。这并不会使早期披露毫无用处。这意味着早期披露应明确说明不确定性。用户能够理解受影响用户数量可能增加。但如果通知将所有不确定性压缩成一份自信但不完整的声明，用户就无法很好地采取行动。

FTC 的泄露响应指南（https://www.ftc.gov/business-guidance/resources/data-breach-response-guide-business）很有帮助，因为它将通知视为响应的一部分，而非公关。FTC 的个人信息保护指南（https://www.ftc.gov/business-guidance/resources/protecting-personal-information-guide-business）也指出了在事件发生前就进行数据最小化和保护措施。对 Adobe 而言，面向用户的问题是，通知是否将技术事实转化为行动步骤：重置 Adobe 密码、更改在其他地方重复使用的密码、监控支付账户、警惕钓鱼攻击，并理解源代码外泄对产品用户意味着什么或不意味着什么。

同样的逻辑也适用于集体诉讼参与者和监管机构。法律程序通常关注诉讼资格、损害、和解和程序性证明。这些记录很重要，但它们无法替代技术证据。客户需要了解其身份和账户面临的持续风险。监管机构需要了解存储设计、非活跃记录、密码提示和通知实践是否符合合理的安全预期。软件采购方需要了解产品安全审查是否覆盖了受影响的代码。除非被有意构建，否则单一的披露渠道很少能同时服务所有这些受众。

因此，通知的标准应当通过下游决策来衡量。客户能否确定自己是否应该更改其他服务上的密码？企业身份团队能否决定是否搜索公司账户中的 Adobe 密码重用？开发者能否决定是否更密切地监控 Adobe 的安全公告？公共部门采购方能否提出正确的采购和补丁问题？如果通知无法支持这些决策，那么它就将长尾风险留在了公司的问责框架之外。

非活跃记录使旧有系统成为危害的一部分

非活跃记录是旧账户泄露中反复出现的问题。BBC 报道称，Adobe 认为攻击者访问了来自两年或更长时间未使用的账户详情，以及活跃用户的信息。这一事实之所以重要，是因为非活跃账户通常受到公司和用户较少的关注。用户可能不记得旧的 Adobe ID，可能不监控其电子邮件地址，可能多年前重复使用了密码，可能不理解为什么一个旧有的创意软件账户会带来当前的身份风险。因此，公司的保留和迁移选择塑造了用户当前的暴露程度。

旧有账户系统也使修复变得复杂。如果一个旧的密码存储系统计划退役或已不处于当前的身份验证路径上，公司仍必须证明该系统中的记录不会继续泄露价值。在泄露后退役系统还不够，如果旧有副本、备份、日志、提示或非活跃账户仍然存在。公开文件应说明旧存储是如何被盘点的，它们如何受到保护，如何被移除或迁移，以及公司如何验证没有并行的凭证记录持续承载风险。

数据主权和地域性在此作为实际的记录治理问题出现。Adobe 服务于全球客户，身份记录可能跨越产品、订阅、支持、支付和区域边界。一个司法管辖区的客户可能拥有与另一个管辖区不同的通知权利，但密码提示或可重用密码的技术风险并不尊重这种边界。长尾问责文件应以一种可传递的方式解释数据类别。它不应要求每个管辖区、客户或采购方从碎片中重建存储设计。

NIST 网络安全框架（https://www.nist.gov/cyberframework）和 CIS 关键控制措施（https://www.cisecurity.org/controls）提供了一种思考方式，而无需对 Adobe 的内部系统做出无依据的断言。资产清单、身份管理、数据保护、日志记录、事件响应和恢复都与之相关。董事会审查应该问：公司能否列出旧账户存储、识别哪些包含认证材料、指定负责人、记录保留原因，并证明过时的存储已被消除或加固。

Adobe 案之所以仍有用，是因为它表明了一次泄露如何能揭示出一个账户系统的考古学。公司常常在前门进行现代化改造，而旧的记录存储仍留在地下室。客户无法看到那个地下室。只有当事件暴露它时，他们才了解。这种不对称正是旧有系统在造成当前风险时需要公开问责的原因。

标准不是判决，但它们定义了修复证据

不应偷懒地将现代密码存储标准用作对 2013 年系统的追溯性判决。技术在变化，威胁模型在变化，公开指导也在演变。但标准仍然必要，因为它们定义了现在修复证据应该是什么样子。OWASP 的密码指导（https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html）、NIST 的身份指导（https://pages.nist.gov/800-63-4/sp800-63b.html）、CISA 的安全设计指导（https://www.cisa.gov/securebydesign）以及 Adobe 当前的安全计划页面共同展示了一个更强大的修复记录的词汇。

修复证据应该回答几个问题。涉及了哪种密码存储方案？它是单向的、加盐的、缓慢的，并针对离线攻击抵抗进行了调整吗？是否存储了密码提示？如果是，为什么？非活跃账户是否与活跃账户一样保留了相同的数据？旧系统是被退役了还是仅仅隐藏在普通登录路径之外？重置是否使会话和令牌失效？是否提示用户更改其他地方重复使用的密码？是否向企业管理员提供了用于搜索暴露情况的指标？是否向产品安全团队提供了源代码审查要求？

这些问题是证据问题，不是指控。公司可以在保护敏感实现细节的前提下回答它们。它可以描述系统类别、修复步骤、迁移里程碑和外部保证，而不必发布漏洞利用配方。它不应该做的是要求客户接受“我们重置了密码”作为完整的修复。重置是可见的。存储迁移、提示最小化、非活跃账户清理和源代码审查则较不可见。这正是它们需要可问责证据的原因。

公开文件还应区分标准文件与法律义务。FTC 的指南是商业指导。NIST 和 CISA 的文件是公共标准或指导。OWASP 是社区安全指导。Adobe 的信任中心是公司撰写的。这些来源中的任何一个单独都不构成法院的结论。但它们之间的重叠是有用的：强身份验证、可靠的密码存储、最小化、事件响应、产品安全和追索都作为持久的控制主题出现。一篇长尾问责文章利用这种重叠来定义客户应得的修复文件。

这种方法避免了追溯性泄露写作中常见的错误。它不说：“这是现代检查清单，因此旧公司在每一项上都失败了。”它说：“以下是现在需要用来证明风险已停止传递的证据。”这种区别很重要。问责不仅是对过去的道德判断。它是对能证明旧设计选择不再伤害无法自行检查系统的人的证据的需求。

产品信任与身份信任共同移动

Adobe 的泄露之所以重要，是因为产品信任和身份信任共同移动。客户使用 Adobe 账户进行软件访问、订阅管理、支付、更新、支持和身份验证。开发者和企业依赖 Adobe 产品进行文档和创意工作流。公共部门组织在表格、记录和通信中依赖 Adobe 格式和工具。当客户数据和源代码出现在同一个公开事件框架中时，公司必须同时保护身份层和产品层。

这一双重信任面在当前 Adobe 页面中可见。信任中心（https://www.adobe.com/trust.html）强调安全性、隐私性、可用性、合规性和产品资源。安全概述（https://www.adobe.com/trust/security.html）讨论了安全产品生命周期、运营安全、事件响应和安全公告。事件响应页面（https://www.adobe.com/trust/security/incident-response.html）描述了当前监控和解决事件的方法。产品安全页面（https://www.adobe.com/trust/security/product-security.html）描述了可重复的开发流程。这些页面是当前的，不是 2013 年的证据。然而，它们展示了一个现代软件采购方应该期望的集成证明结构。

采购方应该能够提出这样的问题：如果客户密码被泄露，身份系统发生了什么变化？如果产品源代码被访问，产品安全审查发生了什么变化？如果旧系统持有密码材料，生命周期管理发生了什么变化？如果客户必须重置凭证，什么指导帮助了他们处理其他地方的重复使用？如果旧代码或旧账户存储在披露日期后产生了风险，什么证据封闭了尾端？当同一个账户解锁软件、支付、支持、更新和企业管理时，产品信任和身份信任不能割裂。

这也是软件生命周期和供应商锁定成为问责主题，而不仅仅是商业抽象的地方。客户通常无法迅速离开一个核心软件供应商。他们的文件、工作流、员工培训、集成和采购计划使他们保持依赖。这种锁定增加了供应商在泄露后提供可用证据的责任。一个无法轻易退出的客户需要知道如何安全地继续使用产品。一份模糊的通知使锁定成本更高，因为它让依赖的客户必须自己制定保障计划。

因此，对于今天的云和订阅软件，Adobe 案依然具有相关性。账户系统积累旧数据。源代码仓库和构建系统成为高价值目标。客户依赖供应商控制的身份层。公共部门用户依赖文件格式和更新渠道。一次暴露账户材料和产品源代码的泄露，成为对供应商能否将私下修复转化为公开保证，同时又不暴露新敏感细节的测试。

长尾是问责通常丢失的地方

长尾身份风险难以治理，因为它超越了事件日历。公司可能完成了重置、结束了调查、更新了产品安全页面并发布了新公告，而客户仍携带攻击者从旧数据集中习得的凭证习惯。这就是为什么 Adobe 案仍然有价值。它表明，问责的单位不仅仅是泄露的数据库，而是客户、企业和安全团队在仅部分了解数据库所揭示内容的情况下，必须做出的一系列后续决策的链条。

长尾也改变了危害的含义。用户可能并未因 Adobe 账户本身而损失金钱。相反，用户可能收到有针对性的钓鱼邮件，发现旧密码在无关服务中被重用，花费时间审查支付记录，或成为改善攻击他人能力的密码破解语料库的一部分。这些成本是分散且难以量化的，但它们并非凭空想象。它们源于这样一个事实：密码材料、电子邮件地址、提示和账户历史可以在原始账户被锁定后重新组合。

企业面临一个平行的问题。企业身份团队可能有员工使用工作电子邮件地址注册了 Adobe 账户，或重复使用了相关的密码。该团队需要知道是否应搜索泄露的秘密、强制重置、检查单点登录例外、警告员工或监控钓鱼活动。这一决定取决于公开证据的质量。如果供应商的通知仅解释密码已被重置，它就让企业团队去推断其余部分。如果通知解释了存储设计、受影响的人群、非活跃记录和推荐的企业行动，它就成为可用的控制输入。

公共部门采购方还有另一种依赖。Adobe 工具常常嵌入到文档工作流、表单处理、创意生产、采购记录和公共通信中。源代码事件可能不要求每个机构停止使用该产品，但它应触发关于公告、更新节奏、补偿控制和供应商保证的问题。负责任的供应商不必发布敏感的代码细节，但必须为安全地继续运营给客户一个合理的依据。

长尾是问责通常丢失的地方，因为那时所有人都已经疲惫不堪。媒体已经转移，法律文件进展缓慢，用户已经重置密码，产品团队已经返回计划中的工作。但攻击者并不关心事件日历。他们关心可重用的秘密、代码洞察和薄弱的后续控制。因此，一份成熟的修复记录需要一个维护阶段：更新的客户指导、企业管理员说明、产品安全后续行动，以及确认旧存储已被清理而不仅仅是遗忘。

证据应从安全团队传递到客户

Adobe 案的另一教训是，私下的安全工作必须被转化，而不会被掏空实质。安全团队可能知道哪些存储被暴露、使用了哪种密码学方案、哪些代码仓库被触及、哪些客户群体被通知，以及哪些系统被退役。客户不需要原始内部细节，但他们确实需要这些事实的准确公开版本。如果转化去除了重要的区别，通知就变得比生成它的私有证据更没用。

这种转化应有意识地分层。第一层针对个人用户：重置 Adobe 密码，更改其他地方重复使用的密码，警惕钓鱼，如适用则监控支付工具，并了解支付卡数据是否涉及其中。第二层针对企业管理员：识别受影响的企业电子邮件域，评估凭证重用，监控登录失败，与员工沟通，并跟踪供应商公告。第三层针对软件采购方：询问源代码审查、安全开发变更、公告节奏和支持承诺。第四层针对监管机构和法院：保留日期、数量、数据类别、通知记录和修复证明。

每一层都应该以不同程度的技术细节保存相同的事实。这是避免自相矛盾的最佳方式。如果只告知用户重置密码，而告知管理员源代码被泄露，那么公开文件看起来就是碎片化的。如果律师描述加密的密码材料，而安全分析师解释为什么该设计仍有助于破解，公众可能同时听到保证和警告。强大的问责文件通过解释每个术语的实际后果，使这些陈述相互兼容。

Adobe 当前的信任中心语言之所以相关，是因为它表明公司现在将保障理解为一款公共产品。安全计划描述、事件响应页面、产品安全页面和公告索引是采购方评判信任的部分方式。2013 年的教训是，这些公共保障系统应该在泄露迫使它们承载一个复杂故事之前就准备好。仅为销售而存在的信任页面无法完成这项工作。一个与证据、公告和可问责负责人相连接的信任页面则可以。

因此，修复文件应被设计为一条证据管道。内部取证发现变成客户类别。客户类别变成通知和管理员指导。产品安全发现变成公告和生命周期变更。法律记录变成程序性问责，而不取代技术记录。标准变成未来保障的基准。当这条管道缺失时，每个受众都构建自己的解释，而公司就失去了对其修复公共意义的掌控。

一份完整的 Adobe 修复文件将保留尾端

一份完整的修复文件将从一份经过验证的时间线开始。它将列出何时检测到入侵、何时确认客户数据泄露、何时确认源代码访问、何时受影响人数变化、何时发生密码重置、何时发出客户通知、何时评估非活跃记录，以及何时进行了产品安全审查或公告。每个日期应标明当时可用的证据。重点不在于惩罚早期的确定性。而在于防止后来的摘要抹去塑造了客户决策的那种不确定性。

第二部分将是存储设计记录。它将解释涉及的密码存储系统、盐的处理、工作因子、加密或哈希、密码提示、非活跃记录以及向更强存储的迁移。它还将描述哪些旧存储被退役、哪些备份被保留、以及旧的凭证材料是如何变得不那么有用的。客户不需要秘密的实现细节。他们确实需要对旧设计已停止传递风险的信心。

第三部分将是客户行动记录。它会将 Adobe 账户重置与其他地方的重复使用密码风险分开。它会给企业管理员提供搜索企业凭证暴露的指导。它会为个人客户提供关于更改重复使用的密码、监控支付账户并防范基于此次泄露的钓鱼攻击的明确建议。它会解释信用监控或身份盗窃帮助是否适用于特定人群。它会保留支付卡暴露、账户 ID 暴露、密码暴露和源代码暴露之间的区别。

第四部分将是产品安全记录。它将解释涉及了哪些产品源代码仓库、审查了哪些产品线、哪些公告或补丁与此相关（若有的话），以及客户应如何监控未来的公告。它还会解释哪些是未知的。源代码泄露不等同于每个产品中都有已确认的漏洞。但它改变了保障责任。一家软件供应商应能够证明，它在考虑了此次暴露的情况下检查了代码和开发管道。

最后，修复文件应该有一个闭合标准。闭合不应意味着公众注意力已经转移，或者第一次密码重置已经完成。闭合应意味着：旧账户存储已被盘点、存储设计已加强、非活跃记录已处理、产品源代码暴露已审查、客户指导已交付、剩余的不确定性已被命名。对 Adobe 而言，长尾教训是，密码存储证据必须比新闻周期更持久。

读者证据文件

文章使用以下公开来源作为 Adobe 2013 年客户数据泄露、密码存储、源代码外泄、客户重置和长尾身份问责记录的阅读文件。公司公告被视为 Adobe 当时公开声称的证据。新闻和安全分析用于时间线和技术背景。当前公司信任页面和标准指导用于定义现代修复证据，而非证明 2013 年内部控制措施。

这份证据文件故意比一份公告更广泛，因为长尾问题跨越了密码存储、非活跃记录、源代码保管、账户重置、产品保障和软件采购方依赖。公开记录应让读者能够区分客户身份修复和产品安全修复，而无需假装这些职责互不相关。

董事会审查问题

董事会审查应问：谁拥有旧账户存储？谁负责密码存储迁移？谁负责客户通知？谁负责源代码仓库访问？谁负责产品安全审查？谁负责企业客户指导？谁负责闭合？答案应是一张控制地图，而不是一份关于努力的叙述。控制地图使旧系统更难以成为每个人的风险而没有指定人的明确责任。

审查还应要求有证据表明非活跃记录受到管控。旧账户、旧备份、旧提示和旧认证存储应有所有者、保留原因、保护标准和移除日期。如果转向订阅的制度增加了账户身份的价值，公司应在攻击者之前重新审视旧存储。旧有不等同于无害。

董事会应要求一份源代码泄露手册。它应定义仓库隔离、凭证和密钥轮换、代码审查触发条件、客户公告规则、产品强化审查以及为依赖的客户提供的证据。源代码事件可能不需要公开每个内部仓库的细节，但它确实要求为必须继续使用该软件的客户提供足够的保证。

针对这一具体案例，董事会审查应提出以下问题：谁实际控制了密码存储设计、源代码保护、泄露通知、客户重置、暴露字段最小化、和解证据，以及证明旧账户系统在披露日期后未继续传递风险的证据？答案应包括标注日期的证据，点名的负责人，密码存储迁移证明，非活跃记录清理，产品安全审查，客户行动指导，以及在第一次重置完成时并未消失的剩余不确定性。