作者atsec张力关键词敏感资产、SAID、SBOM、SDK、Delta变更、安全软件本文为atsec和作者技术共享类文章旨在共同探讨信息安全的相关话题。转载请注明atsec和作者名称。1 引言2026年1月PCI安全标准委员会PCI SSC正式发布了PCI Secure Software标准v2.0版本及其配套体系指南Program Guide。这是该标准自2019年推出以来的首次重大修订。v2.0并非对v1.2.1的增量更新而是一次全面的结构性重组。此次修订标志着PCI安全软件标准从规范性“支付软件”分类向以“敏感资产保护”为中心的原则性方法转型代表了软件安全理念的进一步成熟。以下系统梳理此次版本变更的核心内容。2核心概念的根本性转变“支付软件”让位于“敏感资产”2.1术语移除与概念重塑v2.0最根本性的变革在于彻底移除了“支付软件”Payment Software这一术语代之为“敏感资产”Sensitive Assets的核心概念。敏感资产被定义为软件产品中任何未经授权访问、使用、修改或披露可能导致支付处理或支付相关数据安全受损的元素包括软件产品本身。这一转变意味着标准的适用范围从狭隘的“支付类应用”扩展到更广泛的“敏感资产”保护理念反映了软件安全在当今互联数字环境中的演进。2.2 强制性配套文件敏感资产识别SAID为支持这一框架标准同步发布了强制性的敏感资产识别文件Sensitive Asset Identification要求软件厂商系统性地识别和记录其软件中的四类敏感资产资产类别说明敏感数据Sensitive Data需保护的支付相关数据敏感资源Sensitive Resource系统资源层面的保护对象敏感功能Sensitive Functionality涉及支付处理的关键功能敏感操作模式Sensitive Modes of Operation需特殊保护的操作场景该文件并非可选参考文档而是PCI安全软件计划的必要组成部分。对于处理EMVCo 3DS相关数据的供应商标准还引用了PCI 3DS数据矩阵文档。2.3 术语表内化v2.0将术语表从外部SSF文档移至标准本身的附录A所有已定义的术语在安全要求中均有标记以便识别。同时引入了新术语“强认证”Strong Authentication并将密码学要求的基准统一为“强密码学”Strong Cryptography取代了之前依赖特定有效密钥强度参数的做法。3 标准结构的重组从控制目标到安全目标3.1 11个安全目标取代控制目标v2.0将标准要求全面重组为11个安全目标Security Objectives取代了原有的控制目标Control Objectives术语。这一调整使标准结构更加清晰、逻辑更加连贯。11个安全目标覆盖了从架构设计到部署管理的完整生命周期编号安全目标核心要点目标1软件架构、组合和版本控制包括软件物料清单SBOMSoftware Bill of Materials、版本控制实践及通配符使用目标2敏感资产识别依赖SAIDSensitive Asset Identification Document配套文件涵盖四类敏感资产的识别目标3敏感资产的存储和保留存储与保留的安全控制目标4敏感操作模式引入“强认证”要求适用于存在敏感操作模式的场景目标5敏感资产保护将软件设计本身视为敏感资产引入“异常行为”概念目标6敏感资产输出正式确立安全通道要求目标7随机数涵盖外部RNG使用与内部RNG实现目标8密钥管理密钥全生命周期管理目标9密码学涵盖其他领域未覆盖的综合性密码学要求目标10威胁和漏洞威胁建模与漏洞管理目标11安全部署和管理包括实施指南和软件版本控制3.2测试方法的三支柱重构v2.0将所有测试需求围绕三种核心方法进行了重写● 文档审查Documentation Review评估安全策略和设计记录。● 静态分析Static Analysis在不运行代码的情况下检查代码漏洞。● 动态分析Dynamic Analysis在软件运行时观察其行为以确保其能够正确处理正常输入和恶意输入。3.3强制性源代码审查标准中明确规定软件供应商应根据评估人员的需要提供其被评估软件产品的源代码。如果没有提供相关的源代码软件产品将无法按照此标准进行评估。源代码提供从隐含要求升级为明确的强制性要求。4 模块体系的演进与扩展4.1 核心部分更名与精简原“核心”部分更名为“核心——所有软件”以强调这些要求普遍适用于根据该标准评估的所有软件。标准已删除与SLC相关的要求因为这些内容现已纳入PCI Secure SLC标准。4.2 模块A账户数据保护要求已修订为仅聚焦于PCI DSS中的PANPrimary Account Number和SADSensitive Authentication DataSAID文档提供了更多背景信息。4.3 模块BPOI设备软件原“终端软件需求”更名为“POI设备软件”Point of Interaction设备软件需求大幅精简。多项原属模块B的要求B1.1、B1.2、B1.3、B3.x、B5.x已并入核心部分SREDSecure Reading and Exchange of Data需求同步修订。4.4模块C公开可访问软件​​ 原“Web软件需求”更名为“公开可访问软件”Publicly Accessible Software以更准确地表达其适用于任何可通过公共网络访问的软件。原C.1部分的多项要求已移至核心部分C.1.5和C.1.6因已包含在PCI Secure SLC标准中而被移除。4.5 模块D软件开发工具包SDK新增这是v2.0最重要的新增内容之一。模块D专门针对SDK评估引入了全新的安全目标和要求。该模块的推出使得v2.0能够对SDK进行通用评估包括EMVCo 3DS SDK。PCI SSC计划最终用安全软件标准v2.0及后续版本取代独立的PCI 3DS SDK标准因为安全软件标准更加客观能为所有安全软件供应商包括3DS SDK供应商提供更大的灵活性。5 变更流程的重构v2.0对变更管理体系进行了较为全面重构。在v1.x版本中变更已确立管理变更Administrative Change、低影响变更Low Impact Change 和高影响变更High Impact Change 三大类别。v2.0在此基础上进行了重新梳理与细化正式移除了“低影响变更”和“高影响变更”的表述代之为管理变更、通配符合格变更Wildcard Eligible Changes 和两级Delta变更Tier 1 / Tier 2 Delta Changes 的新体系。这一调整旨在使变更评估流程更加精简、清晰和易于管理降低软件厂商在维护已验证产品时的合规负担。v2.0将所有变更划分为以下三大类别变更类别核心特征是否需要提交PCI SSC管理变更Administrative Change仅更新已列出的通过验证的安全软件产品的供应商公司名称或产品名称。需要通过Portal提交。通配符合格变更Wildcard Eligible对已验证产品的非安全影响变更且版本号中使用已验证的通配符。通配符不能用于属于Delta变更Tier 1或Tier 2的软件变更。不需要Tier 1 Delta变更非安全影响的版本号变更未使用通配符或SSLCSecure SLC合格供应商的安全漏洞修复/补丁。SSLC合格供应商无需评估人员介入非SSLC合格供应商需评估人员进行评估评估结果通过Portal提交。Tier 2 Delta变更安全影响的变更含引入新敏感资产类型、修改依赖项等8类情形。必须使用评估人员进行评估评估结果通过Portal提交。6 安全要求的显著强化6.1 软件物料清单SBOM强制化标准要求强制提供软件物料清单SBOM并对软件架构进行完整文档化。6.2 敏感操作模式的多因素认证对敏感操作模式强制实施多因素认证MFA/强认证。6.3 日志与监控增强● 生成的日志需要更细粒度● 导出的日志必须加密● 必须生成并加密可疑事件日志7 过渡期安排PCI SSC已于2026年1月16日发布的技术常见问题解答中明确了过渡期安排12个月的共存期v1.2.1和v2.0均可用于向PCI SSC提交评估和申请。v1.2.1版本的截止日期● 完整的评估报告提交截止日期为2027年4月30日● 提交材料必须在2027年7月31日之前通过PCI SSC的质量管理流程AQM● 根据v1.2.1版本审核通过并上架的产品其上架有效期为3年● ROV v1.x和AOV v1.x将继续使用v2.0版本的启用● v2.0评估将在安全软件评估员完成新版本培训后开放● 自2027年5月1日起所有已验证安全软件产品的新全面评估必须使用v2.0● 增量变更须使用ROV v2.x、AOV v2.x和新的变更影响模板重要澄清2.0版本不会影响已在1.x版本标准下列出的产品的年度重新验证日期或重新评估日期。对于已通过v1.2.1验证的产品年度重新验证和定期重新评估义务将继续按照既定时间表执行。8 总结PCI安全软件标准v2.0标志着该框架的根本性成熟其核心变化集中体现了从规范性“支付软件”分类向以“敏感资产保护”为中心的原则性方法转型。这一转型以“敏感资产”概念全面取代“支付软件”为起点并配套发布强制性的敏感资产识别文件作为评估基础。在标准架构层面v2.0以11个安全目标取代原有的控制目标并将测试方法重构为文档审查、静态分析和动态分析三大支柱在适用范围上首次新增模块D将SDK纳入评估涵盖EMVCo 3DS SDK。变更管理流程得到系统化精简以两级Delta变更取代原有的低/高影响分类同时正式化通配符版本管理以降低非安全变更的行政负担。安全要求层面显著强化包括SBOM和源代码审查的强制化以及对敏感操作模式实施多因素认证。在此基础上已通过Secure SLC认证的供应商在Tier 1 Delta变更中享有自我证明的程序性便利进一步优化了维护成本与响应效率。atsec将凭借丰富的PCI 安全软件评估经验和专业技术团队深入解读新版标准在敏感资产识别、SDK评估、安全架构文档化等方面的核心要求协助客户完成从v1.2.1到v2.0的平稳迁移在全新的安全框架下持续提升软件产品的安全水平。9 参考文献[1] PCI-Secure-Software-Standard-v2.0. https://docs-prv.pcisecuritystandards.org/Software%20Security/Standard/PCI-Secure-Software-Standard-v2.0.pdf[3] PCI-Secure-Software-Program-Guide-v2.0. https://docs-prv.pcisecuritystandards.org/Software%20Security/Program%20Documents/PCI-Secure-Software-Program-Guide-v2.0.pdf[4] PCI-Secure-Software-Standard-Sensitive-Asset-Identification_v1.0. https://docs-prv.pcisecuritystandards.org/Software%20Security/Standard/PCI-Secure-Software-Standard-Sensitive-Asset-Identification_v1.0.pdf[5] PCI-Secure-Software-Standard-v2.0-Summary-Of-Changes. https://docs-prv.pcisecuritystandards.org/Software%20Security/Standard/PCI-Secure-Software-Standard-v2.0-Summary-Of-Changes.pdf[6] Secure Software v2.x Technical FAQs. https://docs-prv.pcisecuritystandards.org/Software%20Security/Standard/PCI-SecSW_v2.x_TechFAQs_June2026.pdf[7] atsec website. https://www.atsec.com/