执行摘要
合规曾是别人的问题。治理、风险管理与合规（GRC）团队负责填写问卷，审计员每年来一次，而开发人员则继续发布产品。那个时代已经一去不复返了。如今，全球各地的监管机构和标准制定机构已就一系列与安全相关的义务达成共识，这些义务直接落在了编写代码并发布应用程序的团队——即工程团队——的肩上。
几乎所有主要的框架和法规中都包含一些共同的原则：
- 保持软件组件的准确库存记录，这种记录越来越多地以软件物料清单（SBOM）的形式呈现。
- 在规定时限内修复已知的漏洞，对于严重程度为“关键”的漏洞，通常在30天或更短时间内完成修复。
- 展示一套经过文档记录且可重复的流程，用于识别、优先级排序和修复漏洞。
从定义上讲，生命周期结束（EOL）的软件在这三方面均不符合要求。当某个框架版本、运行时或库不再获得安全补丁时，此后出现的每个CVE都将无法通过常规渠道得到修复。不会再有补丁发布。正是这一事实，使得“我们正在运行AngularJS”或“我们仍在使用Node.js 16”这类讨论，从单纯的技术债务问题转变为合规性问题。
本白皮书详细介绍了各项主要标准、框架、指导方针和法规，重点关注开发人员实际能够控制的四个方面：漏洞处理、开源软件、受支持的版本以及已停止维护的软件。针对每个方面，白皮书都提供了具体示例和实用建议。
美利坚合众国
PCI DSS 4.x（支付卡行业数据安全标准）
适用对象：所有存储、处理或传输支付卡数据的实体。此为合同强制要求，由发卡机构和收单银行负责执行。
具体要求。要求6.3.1规定，组织应利用业界公认的信息来源识别新的安全漏洞，并对其进行风险分级。要求6.3.2规定，应盘点专用和定制软件，包括其中集成的第三方组件和开源组件。 要求6.3.3规定，针对关键或高严重性漏洞的补丁须在发布后一个月内安装，所有其他适用的补丁则须在该实体规定的时限内（通常为三个月）安装。要求11.3.1进一步规定，至少每季度进行一次内部漏洞扫描；而11.3.1.1则要求对非关键或非高严重性的漏洞进行针对性风险分析。 综上所述，要求 12.3.4 规定必须每年对所有在用硬件和软件进行审查，确认相关技术仍能获得供应商的安全修复程序、支持持续合规，并跟踪其生命周期结束公告；同时需制定经高级管理层批准的计划，以整改过时和已达到生命周期结束的技术。
为什么已停用（EOL）软件会导致问题。6.3.3 版中设定的“一个月期限”是基于存在补丁这一前提的。当针对已停用框架发布关键 CVE 漏洞时，无论厂商还是开源项目都不会发布补丁，因此该要求在结构上根本无法满足。评估员若在持卡人数据环境中发现存在已知关键 CVE 漏洞的已停用组件，即视为不符合要求，而非可协商的发现项。
示例。某支付平台的结账前端基于AngularJS .x 运行，而该版本已于 2022 年 1 月达到生命周期终止。 针对AngularJS 发布了一个新的关键 CVE。根据 6.3.3 条款，该组织有一个月的时间来安装一个尚不存在的补丁。其现实可行的选项包括：紧急迁移（对于生产环境中的结账流程，通常难以在 30 天内完成）、经评估人员认可的、有文档记录的补偿性控制措施，或者购买商业扩展支持服务——该服务可提供向后移植的补丁，并恢复一条具有可辩护性的整改路径。
对开发者的建议：
- 将 6.3.2 组件清单作为构建产物进行维护，而非电子表格。在每次发布时，通过持续集成（CI）生成软件物料清单（SBOM），以确保清单始终保持最新。
- 跟踪生产环境中每个框架和运行时的支持终止（EOL）日期，并将临近的支持终止日期视为合规截止日期，而非待办事项。
- 对于已经超过生命周期（EOL）的组件，应将其隔离在生产环境之外、进行迁移，或者签订商业延长支持协议，以便在30天内仍能对关键的CVE漏洞进行修补。
《健康保险可携带与责任法案》（HIPAA）安全规则
适用对象：在美国处理电子受保护健康信息（ePHI）的受管制实体和业务合作伙伴。联邦强制性法律。
相关要求。《安全规则》要求对电子受保护健康信息（ePHI）的风险和漏洞进行准确、全面的评估（45 CFR 164.308(a)(1)(ii)(A)），并采取充分的安全措施，将这些风险降低到合理且适当的水平。 美国卫生与公众服务部（HHS）的指导意见将风险分析和漏洞管理视为基础工作，而公民权利办公室（OCR）2026年1月的网络安全简报明确指出，风险分析必须识别诸如未打补丁的软件等漏洞，并将识别结果与积极的整改措施相结合。 2024年12月发布的《拟议规则制定通知》（NPRM）将进一步推进相关要求，新增明确的漏洞管理和补丁管理标准，规定至少每六个月进行一次漏洞扫描、每年进行一次渗透测试，并针对关键漏洞提出了最短15天的补丁修复时限。 截至2026年年中，该《拟议规则制定通知》尚未最终敲定，最终行动也已推迟，但OCR正在积极执行现有规定，其执法重点已瞄准那些记录风险却未采取相应行动的组织。
为什么已停止维护（EOL）软件会造成问题？HIPAA从未规定“禁止使用已停止维护的软件”，而是要求安全保障措施必须合理且适当。一旦发生数据泄露，在接触电子受保护健康信息（ePHI）的系统中运行存在已知且无法修复的通用漏洞披露（CVE）的、已停止维护的组件，极难被认定为合理行为。OCR的调查一再发现，某些漏洞年复一年地出现在风险评估中，却始终未得到缓解，直至被利用；正是这种模式导致了“故意疏忽”的认定。
示例。某患者门户网站运行在已停止Drupal v7）上。年度风险分析将其列为风险点，该发现已被记录在案，但由于迁移成本高昂，两年间未采取任何措施。随后，通过一个已知的CVE漏洞发生了数据泄露事件。这一“已记录但被忽视”的发现成为OCR调查的核心焦点，将原本的技术捷径转化为疏忽的证据。
对开发者的建议：
- 确保所有接触电子受保护健康信息（ePHI）的已停产（EOL）组件均纳入正式风险分析中，并附有整改计划及负责人。根据OCR的指导意见，未将未打补丁的软件纳入风险分析的风险分析现被明确认定为存在缺陷。
- 闭环处理：对于每个已识别的漏洞，都要记录所采取的整改措施（打补丁、升级、隔离、延长支持），因为OCR的执法工作现在侧重于组织针对已识别风险采取了哪些措施。
- 不要等到《拟议规则制定通知》（NPRM）最终定稿。其中提出的管控措施（扫描频率、补丁更新时间表、资产清点）描述了监管机构认为在2026年已属合理的安全标准。
FedRAMP 和 NIST SP 800-53 SI-2（漏洞修复）
适用范围：向美国联邦机构销售的所有云服务。强制要求。
具体要求。FedRAMP 基准基于 NIST SP 800-53 控制措施构建。 控制措施 SI-2 要求组织识别、报告并纠正系统缺陷，并在规定时限内安装与安全相关的软件更新。FedRAMP 通过基于严重程度的整改时限将此要求付诸实施：高严重程度问题为 30 天，中严重程度问题为 90 天，低严重程度问题为 180 天，并通过每月《行动计划与里程碑》（POA&M）流程及持续监控扫描进行跟踪。
为什么 EOL 软件会造成问题？安全扫描工具会标记 CVE；如果某个已停产组件存在高严重级别的 CVE，系统会生成一个有效期为 30 天的 POA&M 项目，且没有可安装的补丁。如果发现的问题在有效期内未得到修复，将危及运营授权（ATO）。 与商业审计不同，这并非年度性活动：扫描每月甚至更频繁地进行，因此 EOL 软件会持续产生大量逾期问题。
示例。一家获得 FedRAMP 授权的 SaaS 提供商发现其报告服务依赖于Express 的已停用版本。 每次安全扫描都会重新标记该组件，每个新的CVE都会生成一个新的30天或90天POA&M项目，而第三方评估机构（3PAO）的评估员会将该不受支持的依赖项列为持续性弱点。该提供商必须提供可信的迁移里程碑，或者证明已获得供应商支持以恢复补丁的可用性。
对开发者的建议：
- 将 FedRAMP 的 30/90/180 天时限视为工程服务水平协议（SLA），并将其与问题跟踪系统集成，以便漏洞工单能自动生成截止日期。
- 在初步评估之前，应淘汰已停产（EOL）的组件，或为其获取支持保障。这比事后每月为重复出现的POA&M项目进行辩护要便宜得多。
- 应确保偏差请求和风险调整既真实又罕见；评估人员会追踪相关模式，若针对同一项缺乏依据的组件反复提出偏差请求，则表明存在未得到管控的风险。
美国国家标准与技术研究院（NIST）网络安全框架（CSF）2.0
适用范围：对大多数私营组织而言为自愿性要求；对美国联邦机构而言为强制性要求，且其承包商也普遍被要求遵守。同时，该标准也是网络保险和董事会报告的事实上的参考模型。
具体要求。CSF 2.0 的子类别 PR.PS-02 规定，软件必须“根据风险程度进行维护、替换和移除”。ID.RA 子类别要求对资产中的漏洞进行识别、验证和记录。该框架以结果为导向：它并未规定补丁窗口，但确立了以下预期——环境中的每款软件都应根据风险情况，要么积极维护，要么有计划地退役。
为什么已停产（EOL）软件会造成问题？根据定义，已停产软件不再接受维护。根据 PR.PS-02 规范，对于此类软件，组织只有三种可辩护的状态：替换它、移除它，或者恢复对其的维护。默默地继续运行它，是该框架所不允许的唯一状态。这也是商业扩展支持与该框架最契合的情形，因为由供应商支持的已停产组件补丁更新，实际上就构成了“受维护”的状态。
示例。某制造商在根据CSF 2.0标准续签网络保险时，对其车间应用程序进行了盘点，发现一款基于已停产（EOL）Vue 2 和已停产版本Node.js运行时构建的排程工具。保险公司的问卷要求说明所有软件是否均获得支持并已安装补丁。如实回答需提供附有具体日期的迁移计划或支持合同；若作虚假回答，一旦发生事故，将导致保险理赔主张失效。
对开发者的建议：
- 将每个应用程序映射到以下三种状态之一：由上游项目积极维护、通过商业扩展支持进行维护，或已安排在特定日期进行替换/移除。任何未被映射的情况均属于 PR.PS-02 中的缺口。
- 将产品生命周期结束（EOL）和支持状态数据纳入用于 CSF 分析的同一资产清单中，以便风险负责人能够同时查看软件生命周期状态及其严重程度。
- 记录风险决策。CSF 是以证据为依据的：所谓“我们接受这一风险，直到第三季度的迁移完成”与“没人查看过”之间的区别，就在于是否进行了记录。
NIST SSDF（SP 800-218，《安全软件开发框架》）
适用范围：自愿性框架。OMB备忘录M-26-05撤销了此前由第14028号行政命令及OMB备忘录M-22-18/M-23-16规定的、针对向美国联邦机构销售软件的软件供应商的强制性自我声明要求。各机构仍可根据自身的风险评估，选择要求提供声明或软件成分清单（SBOM）。
具体要求。SSDF 是一个灵活的框架，致力于将安全工作“前移”，即在整个软件开发过程中将安全措施融入其中。它要求组织制定并维护安全开发政策（PO 实践）、保护软件（PS）、产出安全可靠的软件（PW）以及应对漏洞（RV）。 实践 PW.4 涵盖了安全软件的复用，要求组织对第三方和开源组件进行评估和监控。RV 实践组要求持续识别、评估和修复已发布软件中的漏洞，这假设相关组件仍可获得修复程序。
为何已停止维护（EOL）的软件会导致问题。对于基于不再接收安全更新的组件构建的产品，供应商无法保证其漏洞响应符合 SSDF 标准。当底层开源项目已停止支持时，PW.4 关于从受维护来源获取组件的要求，以及 RV 关于持续修复的要求，都将无法实现。
示例。某向联邦机构销售产品的软件公司自愿签署了CISA《安全软件开发声明表》。但其旗舰产品仍jQuery .x及已停止Bootstrap 。法务部门向工程部门询问该声明是否准确。工程部门要么仓促制定整改方案，要么公司就其依赖关系树与之相悖的内容作出声明——这不仅涉及安全风险，更存在作出虚假陈述的风险。
对开发者的建议：
- 制定一项开源项目引入政策，在采用新依赖项之前（而非之后）记录其支持状态和生命周期结束时间。
- 不仅要监控 CVE，还要监控生命周期事件（维护模式、已归档的仓库、已公布的停用日期）相关的依赖项。项目的支持终止即构成一项安全事件。
- 在进行任何联邦级认证之前，请先执行依赖项生命周期审计，并对产品中包含的每个已停用组件进行整改或获得支持性覆盖。
NIST SP 800-171 和网络安全成熟度模型认证（CMMC）
适用对象：处理受控非机密信息（CUI）的国防部承包商和联邦供应商。此要求为强制性规定，CMMC评估现已逐步纳入国防部合同。
相关要求。要求3.14.1（在修订版 3 中重新编号为 03.14.01）要求及时识别、报告并纠正系统缺陷。评估指南明确指出，已安装的补丁、服务包和热修复程序即为已纠正的证据。相关要求涵盖漏洞扫描和修复（3.11.2、3.11.3）。
为何已停用（EOL）软件会造成问题。“及时修复缺陷”这一要求对那些供应商或开源项目已停止发布修复程序的软件同样适用。如果CUI隔离区内存在包含已知CVE的已停用组件，这将构成对3.14.1条款的持续性违规，CMMC评估员会据此对承包商进行扣分；而单项实践的违规就可能导致认证失败，进而丧失合同资格。
示例。某国防供应商的工程文档门户运行在已停用的Web框架上。在CMMC 2级评估期间，评估员要求提供证据，证明该门户中的缺陷已得到及时修复。该供应商可以出示识别出CVE的扫描报告，但无法提供修复记录，因为上游并未进行任何修复。该实践被评定为“未达标”，这危及了该公司为维持其国防部合同所需的认证资格。
对开发者的建议：
- 严格界定范围：尽可能将已停用的软件完全排除在CUI边界之外，因为边界内的所有内容都会接受评估。
- 如果某个已停用（EOL）组件必须继续保留在适用范围内，则应记录补偿性控制措施，并将其与受支持的补丁来源配对，以便能够证明已进行“及时更正”。
- 请按需求分类整理补丁相关证据（工单、部署日志、修复前后的扫描结果）；CMMC评估本质上是证据审查，未记录的修复措施在评分上与未进行修复的情况相同。
美国证券交易委员会（SEC）网络安全信息披露规则
适用对象：美国所有上市公司。强制执行，自2023年12月起生效。
相关要求。注册公司必须在确定重大性后的四个工作日内，通过8-K表格披露重大的网络安全事件；并须每年在其年度报告（10-K表格）中披露（根据S-K条例第106项）评估、识别和管理重大网络安全风险的流程，包括董事会对网络安全风险管理、战略及治理的监督情况。
为何此处需关注已停用（EOL）软件？相关规则并未提及补丁更新或已停用软件，但“重大性”原则却涉及这一点。业务所依赖的组件中存在已知且未修复的严重漏洞，这一情况本身就可能构成需要披露的重大风险；而可追溯至已知已停用系统的安全事件，正是将数据泄露转化为证券诉讼的关键事实依据——因为原告将主张该风险是已知的、未得到修复且披露不充分的。
示例。某家金融服务企业因一款基于Java且使用了已停Spring 应用程序而遭遇数据泄露。在事件响应过程中，法律顾问发现，早在六个月前就有内部工单指出了该框架已停用的状态。如今，四天的披露时限反倒成了容易的部分；真正困难的是，在8-K报告及后续文件中解释为何一个有据可查且已知风险从未得到整改，而董事会的监督流程正面临直接审查。
对开发者的建议：
- 请注意，关于已停用（EOL）软件的内部工程记录（工单、Slack 讨论串、风险登记册条目）属于可调取信息，在发生安全事件后，这些记录将与公开披露的信息进行比对分析。
- 向安全团队和法务团队提供准确的生命周期数据：对产品生命周期结束（EOL）风险进行如实盘点，可使公司在第106项披露中如实描述其风险管理流程。
- 应优先处理收入关键路径中已停产（EOL）组件的整改工作，因为这是“关键”与“未打补丁”两个因素的交汇点。
加拿大
《关键网络系统保护法》（CCSPA，C-8号法案）
适用对象：联邦监管的关键基础设施中的指定运营商：电信、银行、能源和交通运输。强制性规定。C-8号法案已于2026年6月15日获得御准，《关键基础设施保护法》（CCSPA）规定的义务将根据内阁令分阶段生效。
相关要求。指定运营商必须制定并实施网络安全计划，降低供应链和第三方风险，在规定时限内报告网络安全事件，遵守网络安全指令，并保存相关记录。对组织的处罚金额最高可达1500万加元，且持续违规行为将按违规持续的天数分别计算。如果董事会成员和高管指示、授权或默许组织违反规定，则可能被追究个人责任。
为何已停产（EOL）软件会造成问题。供应链风险责任直接涉及软件栈。关键网络系统中未打补丁的开源库或已停用（EOL）框架，正是该计划必须识别并缓解的第三方风险类型；鉴于存在按日计算的罚款风险，“明知故犯”将付出高昂代价。CCSPA要求相关计划必须包含例行漏洞评估、系统扫描以及主动缓解计划，以便在漏洞被利用之前及时修补或隔离这些弱点。
示例。某家受联邦监管的能源运营商的停机管理门户运行在已停止支持（EOL）的Angular 。一旦根据《通信和通信安全保护法》（CCSPA）被指定为受监管对象，该运营商的网络安全计划就必须记录供应链风险。评估中会涉及该已停止支持的前端系统；运营商必须证明已采取缓解措施，这在实践中意味着必须按照既定时间表进行迁移、实施隔离，或恢复供应商支持并附带补丁服务水平协议（SLA）。
对开发者的建议：
- 如果您的雇主从事加拿大电信、金融、能源或交通运输行业，请立即着手进行软件生命周期盘点；相关指定标准和法规正在逐步实施，若等到指定标准出台后再启动项目，届时将不得不仓促推进。
- 在 CCSPA 框架下，将开源依赖项视为供应商：记录每个关键组件的维护者、其支持状态，以及安全修复程序如何传递给您。
- 将事件报告准备工作融入工程实践中（日志保留、组件级影响范围映射），以便报告能够快速指明受影响的系统和组件。
欧洲联盟
《数字运营韧性法案》（DORA）
适用对象：欧盟金融机构（银行、保险公司、投资公司、支付机构、加密资产服务提供商）以及关键信息通信技术（ICT）第三方服务提供商。该规定为强制性要求，自2025年1月17日起生效。
具体要求。DORA的信息通信技术（ICT）风险管理框架要求金融机构使用可靠、容量充足且技术上具有韧性的ICT系统；维护所有ICT资产的最新清单（包括对接近使用寿命终点的资产进行追踪）；实施补丁管理；并识别和记录遗留ICT系统，以便逐步淘汰或对其进行明确管理。
为何使用生命周期结束（EOL）软件会造成问题。DORA的表述异常直白：不再受支持的系统被视为运营韧性方面的根本缺陷，而资产清查义务则明确要求对生命周期结束软件进行追踪。任何在支付或交易流程中运行生命周期结束软件的金融机构，都存在经记录在案的韧性缺陷，监管机构及其审计人员已被要求对此进行审查。
示例。某家欧盟支付机构的交易仪表盘基于Vue 2 运行，该框架已于 2023 年 12 月达到生命周期终止（EOL）。DORA 资产清单必须记录此情况、其关键程度以及相关计划。在监管审查过程中，“无计划”会被视为一项审查发现；而“计划于 2027 年完成迁移，过渡期间将通过商业安全补丁进行防护”则属于受管控的遗留系统。
对开发者的建议：
- 在 ICT 资产清单中将停用日期和支持状态设为必填字段，并自动从依赖关系清单中提取相关数据。
- 对于关键或重要功能中的每个遗留组件或已停产组件，应制定以下三种计划之一：在指定日期前完成迁移、在指定日期前停用，或者在上述前两种情况发生之前持续对其进行补丁更新。
- 测试韧性假设：DORA 要求进行数字运营韧性测试，而已知存在漏洞且已停产的组件，正是以威胁为导向的渗透测试首先会利用的对象。
《通用数据保护条例》（GDPR）第32条
适用对象：所有处理欧盟个人数据的组织，无论该组织位于何处。强制性要求。
具体要求。第32条要求采取“适当的技术和组织措施”，以确保达到与风险相适应的安全水平，并明确要求将“最新技术水平”纳入考量。该条款并未强制要求进行补丁更新、规定具体时限或指定特定技术。
为什么已停用的软件会造成问题？关键在于“最先进的技术”这一表述。在发生个人数据泄露事件后，监管机构会审查：鉴于现有技术水平，已采取的措施是否恰当。如果运行的软件存在已公开披露的CVE漏洞、没有可用补丁且支持期限早已过期，那么很难将其辩称符合“最先进的技术”标准；欧洲监管机构已多次对因已知且未修补的漏洞导致数据泄露的组织处以罚款。
示例：一家处理欧盟客户数据的营销类SaaS公司，因一个已知CVE漏洞（该漏洞存在于一个已停止维护的jQuery 链中）而遭遇数据泄露。 第32条的分析重点不在于该公司是否运气不佳，而在于继续运行一个存在公开利用漏洞且已停止支持的组件是否“恰当”。若同时发现违反基本原则的情况，根据《通用数据保护条例》（GDPR）规定的罚款最高可达全球年营业额的4%，而因已知漏洞导致的泄露是典型的加重处罚情形（疏忽大意和技术措施失效）。
对开发者的建议：
- 应优先修复处理个人数据的系统中的漏洞，并能说明优先级排序的依据。
- 当某个组件达到生命周期终止（EOL）时，应记录当时的风险决策（迁移、隔离、支持合同），因为 contemporaneous documentation 是第32条最有力的抗辩依据。
- 在遗留系统中践行数据最小化原则：即将淘汰的系统接触的个人数据越少，在迁移过程中其面临的第32条相关风险就越小。
《NIS2指令》
适用范围：欧盟18个行业（能源、交通、卫生、数字基础设施、关键产品制造、数字服务提供商等）中的关键实体和重要实体。强制性规定；各成员国应于2024年10月前将其转化为国内法，目前各成员国正按照各自的时间表逐步加强执法力度。
具体要求。第21条第(2)款规定了十项最低风险管理措施，其中包括(e)“网络和信息系统的采购、开发和维护中的安全，包括漏洞处理和披露”，以及(d)涵盖与直接供应商和服务提供商关系的供应链安全。 第21条第3款要求各实体考虑各供应商特有的漏洞，以及供应商产品的整体质量和安全开发实践。第23条规定了事件报告时限：24小时（预警）、72小时（通报）和一个月（最终报告）。对关键实体，罚款金额可达1000万欧元或其全球营业额的2%；此外，《网络与信息安全条例II》（NIS2）还增加了管理层的个人责任。
为何已停用（EOL）软件会造成问题。第21条第(2)款第(e)项规定，在开发和维护过程中处理漏洞是一项法定义务，而已停用软件是指其漏洞处理工作已从根本上终止的软件。第21条第(2)款第(d)项和第(3)款规定的供应链措施将这一逻辑延伸至开源组件：实体必须对其所依赖的软件背后的安全实践负责，而已终止的上游项目则不存在此类安全实践。
示例。某医院集团（关键实体）在其已达到生命周期终止（EOL）的Nuxt 应用程序上运行员工排班系统。 一起勒索软件攻击事件通过该技术栈中已知的CVE漏洞侵入系统。在24小时报告时限过后，国家主管部门的调查将审查是否已落实第21条规定的措施；对于已知已达生命周期终止且存在已知漏洞、但未记录任何处理措施的系统，这直接构成第21(2)(e)条规定的违规，根据《网络与信息安全指令2》（NIS2），管理委员会需对批准的风险管理措施承担个人责任。
对开发者的建议：
- 实施一套明确涵盖开源依赖项的漏洞处理流程：识别（SCA扫描）、分级、修复服务水平协议（SLA）以及披露处理。
- 对支持关键或重要服务的系统维护软件物料清单（SBOM），以便能够通过数据解答供应链相关问题。
- 以书面形式向管理层上报产品生命周期结束（EOL）情况。根据《NIS2》中关于个人责任的规定，领导层必须知晓相关情况；向其提供准确的生命周期数据是工程师职责的一部分。
《网络弹性法案》（CRA）
适用对象：将“含数字元素的产品”（包括硬件和软件）投放到欧盟市场的制造商、进口商和分销商，无论制造商位于何处。 强制性规定。针对被积极利用的漏洞和严重事件的报告义务自2026年9月11日起生效；全部基本要求、符合性评估及CE标志要求自2027年12月11日起生效。处罚金额最高可达1500万欧元或全球营业额的2.5%。
相关要求。这是本清单中对开发者影响最大的法规，因为它对产品在其整个生命周期内的各个阶段都进行了规范。附件一第一部分要求产品在交付时不得存在已知的可被利用的漏洞。 附件一第二部分规定了漏洞处理要求：制造商必须识别并记录漏洞及组件，包括以机器可读格式编制软件物料清单（SBOM），该清单至少应涵盖顶级依赖项；通过免费安全更新及时修复漏洞；实施有效且定期的安全测试；并公开披露已修复的漏洞。这些义务在支持期内持续有效，在大多数情况下，支持期必须至少为五年。 第14条要求在主动被利用的漏洞出现后，须在24小时内（早期预警）、72小时内（全面通报）以及修复程序发布后14天内（最终报告）向欧洲网络与信息安全局（ENISA）和各国计算机安全事件响应小组（CSIRT）报告。关键的是，2026年9月的报告义务适用于已投放市场的产品，包括数年前出货的旧款产品。
为什么开源软件和已停止维护（EOL）软件在此具有极其重要的意义。发布开源组件的商业供应商需对这些组件中的漏洞承担法律责任。如果贵公司发布的产品中某个开源库存在已被积极利用的漏洞，那么无论上游项目是否依然存在，漏洞报告时限均适用于贵公司，且贵公司有义务“毫不拖延”地进行修复。 发布基于已终止支持（EOL）框架构建的产品，意味着在法律上承诺处理某个组件中的漏洞——而该组件的上游项目将永远不再处理这些漏洞。CRA 将“旧依赖项中被忽略的 CVE”从技术债务转化为法律责任，并设定了科技监管领域最高的罚款上限。
示例。某独立软件供应商（ISV）向欧盟销售一款文档管理产品。该产品嵌入了已停用的Bootstrap 和已停用的Express 。2026年10月，Express 存在的一个CVE漏洞被发现正在被积极利用。根据第14条规定，供应商必须在24小时内提交预警，72小时内提交完整通知，并在修复程序发布后14天内提交最终报告。 由于上游未提供修复方案，该供应商必须自行开发回溯补丁、通过延长商业支持购买补丁，或者向监管机构解释为何其仍在销售的产品无法获得修复方案。
对开发者的建议：
- 请立即为每件已发货的产品生成并维护可机读的SBOM（CycloneDX或SPDX）；如果不提前掌握每个产品版本的具体组成，就无法在2026年9月满足24小时内提交报告的要求。
- 对每条产品线中的停产（EOL）元器件进行排查，并在2027年12月之前逐一解决：进行升级、移除，或签订支持协议，以确保在您声明的支持期内能够获得补丁更新。
- 针对每款产品，明确并公布一个切合实际的支持周期，并将该承诺所涉及的补丁维护成本（包括第三方组件）纳入产品规划；支持周期现已成为一项法律承诺，而非营销声明。
- 制定一套协调一致的漏洞披露政策，并建立一套针对24/72小时时限进行过演练的接收-分流-报告工作流程。
英国
英国《通用数据保护条例》（GDPR）
适用对象：处理英国个人数据的组织。该规定为强制性规定，由信息专员办公室（ICO）负责执行。
具体要求。英国《通用数据保护条例》（UK GDPR）在英国脱欧后保留了欧盟《通用数据保护条例》（GDPR）的相关规定，同样包含第32条关于“采取适当的技术和组织措施”的义务。信息专员办公室（ICO）的执法记录对此作出了具体阐释：未能修复已知的漏洞将被视为未采取适当的安全措施；而可追溯至已停止支持或长期未修复漏洞的软件所导致的数据泄露事件，将被视为疏忽而非意外。
示例。信息专员办公室（ICO）发现，英国特许证券与投资学会（CISI）因运行已达到生命周期终止（EOL）的网站软件而违反了第32条；此外，攻击者利用了一个关键漏洞，该漏洞的补丁自2017年起便已发布，但该学会从未进行过修复。
对开发者的建议：
- 应采用与欧盟《通用数据保护条例》（GDPR）相同的规范要求：进行资产清点，对涉及个人数据的系统优先进行补丁修复，并对关于生命周期结束（EOL）组件的风险决策进行同步记录。
- 如果无法快速迁移旧系统，应减少其个人数据占用量并将其隔离，同时保留这两方面的相关证据。
- 跟踪ICO指导意见和执法通知；这些文件实际上构成了关于“适当”一词在实践中具体含义的持续更新的判例记录。
《2018年英国国家基础设施安全条例》
适用对象：基本服务（供水、能源、交通、医疗）的运营商及相关数字服务提供商（云服务、在线市场、搜索引擎）。强制性规定，具有法律约束力。
相关要求。运营商必须采取适当且相称的措施，以管理网络和信息系统面临的风险，预防和最大限度地减轻事件的影响，并须在72小时内报告重大事件。 英国国家网络安全中心（NCSC）的《网络安全评估框架》（CAF）被英国监管机构用于评估合规性，其中包含管理漏洞和保持系统受支持的目标；在实践中，对补丁及时性的要求通常与“网络安全基本要求”（Cyber Essentials）中“在14天内应用关键更新”的基准相一致。
为何已停产（EOL）软件会造成问题。如果某起导致关键服务中断的事件追溯到一个未打补丁的已停产系统，监管机构很可能会认定其违反了维持服务连续性的义务，而那份72小时报告也将成为执法案件的开端文件。对于没有补丁源的软件而言，14天内打补丁的要求是无法实现的。
示例。某英国水务公司的远程监测仪表盘运行在已停止支持的AngularJS 。因某已知 CVE 遭到利用，导致运营可视性中断了一天。该事件须在 72 小时内上报，随后进行的 CAF 评估将审查漏洞管理情况；对于存在公开 CVE 且无补丁路径的已停止支持组件，其在多项 CAF 评估指标中均得分较低。
对开发者的建议：
- 将关键服务系统与CAF进行对照，并标注所有未获支持的组件；CAF会明确审查系统是否获得支持以及漏洞是否得到管控。
- 建立一个补丁来源（上游或商业来源），能够满足对关键服务环境中的所有内容在14天内发布关键补丁的要求。
- 与工程团队共同演练72小时报告流程，以便能够快速获取组件层面的事实信息（哪些组件存在漏洞、自何时起存在漏洞、已采取了哪些措施）。
亚太地区
APPI（日本《个人信息保护法》）
适用对象：处理日本境内个人信息的组织。强制性要求。
相关要求。《个人信息保护法》（APPI）要求企业经营者采取必要且适当的措施，对个人信息进行安全管理，防止信息泄露、丢失或损毁。个人信息保护委员会的指导方针将此细化为组织、人员、物理和技术方面的安全保障措施；技术保障措施包括保持软件更新、定期应用安全补丁以及监测漏洞。
为何已停止支持（EOL）软件会引发问题。与《通用数据保护条例》（GDPR）类似，该法规并未明确提及已停止支持的软件，但监管机构显然期望企业使用仍受支持且持续维护的软件。因未受支持软件中已知漏洞导致的个人数据泄露，很难与“必要且适当”的安全管理相符，而强制性数据泄露通报规定（2022年修订案中新增）则确保此类事件会上报至监管机构。
示例。某日本电商运营商因其账户门户中使用的JavaScript框架已停用版本而遭遇数据泄露。向PPC提交的强制性报告引发了对技术防护措施的审查，而“该组件已停用三年”成为此次审查的核心发现。
对开发者的建议：
- 将PPC关于技术保障措施的指导意见作为运营基准：对于任何存储日本个人数据的系统，均应定期打补丁、监测漏洞，并使用受支持的软件。
- 应将面向日本市场的系统纳入与欧盟/美国合规要求相同的生命周期清点和整改服务水平协议（SLA）中，而不是维持一套单独且标准较低的规范。
- 应以能够支持数据泄露报告的形式记录安全保障措施的决策，因为目前通知已属强制性要求，且后续问题也具有可预见性。
《主动网络防御法》（日本，简称“ACD法”或“ACDA”）
适用对象：根据日本《经济安全促进法》指定的特定关键基础设施提供商，以及向其供货的IT供应商。强制性规定。于2025年5月16日颁布，分阶段实施，并于2027年全面生效。
具体要求。《ACDA》围绕四大支柱对日本的网络防御体系进行了重组：公私合作、利用通信数据进行威胁检测、政府对攻击者基础设施的削弱，以及组织改革。指定服务提供商必须向主管部门报告网络安全事件，该义务将于2026年10月1日生效（具体日期尚未正式确定）。 对于影响关键系统的漏洞，政府可通知IT供应商，主管部长可要求采取纠正措施；这些要求虽不具有约束力，但供应商必须尽合理努力予以回应。该框架还授权政府可及时要求运营商解决零日漏洞。
为何已停产（EOL）软件会破坏这一机制。ACDA在监管机构与关键基础设施内的软件之间建立了一条直接通道，而已停产软件在这两端都无法满足要求。提前通知机制使监管机构在部署前就能了解关键系统的构成，因此，任何不再受支持的框架在审查中都会被记录为已知弱点。 补救机制的前提是问题可以得到纠正：当部长要求针对已停用组件中的 CVE 采取纠正措施时，由于不存在上游修复方案，“合理努力”最终只能演变为独立开发补丁或承认无法获得补丁。强制性事件报告机制则确保，因已停用软件中已知 CVE 导致的违规事件，将在规定时限内上报给主管部门。
示例。某指定电力运营商在其已停用的.NET 上运行停电报告门户。国家协调办公室（NCO）发现该.NET 存在被积极利用的CVE漏洞，主管部长随即要求该运营商的IT供应商采取纠正措施。 由于不存在上游补丁，供应商可选方案包括紧急迁移或购买商业扩展支持以恢复补丁来源；“该组件已达到生命周期终止，无法修复”这一情况现已记录在案，供未来提交任何事件报告时参考。
对开发者的建议：
- 如果您的系统为指定的日本基础设施运营商提供服务，请立即对所有框架和运行时环境进行盘点，并在2026年11月通知和报告义务正式生效之前，解决已达到生命周期终止（EOL）的组件问题。
- 为关键系统中的每个组件（无论是上游组件、内部组件还是商业扩展支持组件）维护一个补丁源，以便能够及时响应政府的修复请求。
- 应将《ACDA》和《APPI》视为互为补充的监管框架：《APPI》规范个人数据泄露，而《ACDA》规范关键服务中断，日本市场系统中发生的单一事件可能同时触发这两项法规。
《SOCI法》（澳大利亚，《2018年关键基础设施安全法》）
适用对象：澳大利亚11个行业中关键基础设施资产的所有者和运营商。强制性要求。
具体要求。《SOCI法案》及其《关键基础设施风险管理计划》（CIRMP）规则要求责任实体识别重大风险（包括网络安全和供应链风险），并实施控制措施以将其降至最低或加以缓解，同时每年提交经董事会批准的报告。许多实体通过采用ACSC“八大核心要求”来履行网络安全框架义务，该框架的补丁成熟度级别要求在短暂且明确界定的时间窗口内安装关键补丁，并明确将不再受支持的软件视为需消除或替换的漏洞。
为何已停产（EOL）软件会造成问题。虽然该法案中并未明确提及已停产软件，但根据风险管理义务，其显然属于适用范围：关键系统中存在未获支持的组件属于重大网络风险，需要采取有据可查的控制措施或补救措施，且董事会必须每年对针对该问题的应对方案进行确认。
示例。某澳大利亚港口运营商的物流应用程序运行在已停止维护（EOL）的Node.js 版本上。经董事会签署的 CIRMP 年度报告必须描述重大风险及相应的缓解措施。对于已停止维护的运行时环境，要么提供可信的缓解措施（如迁移计划、隔离措施或通过补丁更新提供的延长支持），要么当事件或审计揭示该问题时，其缺失本身将成为审计发现。
对开发者的建议：
- 将补丁管理和生命周期管理实践与“Essential Eight”成熟度模型保持一致，该模型被大多数澳大利亚监管机构和董事会作为“合理”的代称。
- 将Surface产品生命周期结束（EOL）相关风险纳入CIRMP风险登记册，并提出相应的应对措施，因为董事会确认会使未报告的工程风险演变为治理问题。
- 对于确实无法升级的与运营技术相关的系统，应将分段和监控控制措施明确记录为风险应对措施。
全球标准
互联网安全中心（CIS）控制措施 v8.1
适用范围：自愿性最佳实践框架，已被广泛采用，并被监管机构和保险公司作为参考依据，在某些合同情境下具有强制性。
具体要求。控制措施2（软件资产的盘点与管控）要求组织积极管理所有软件，确保仅安装和运行经授权且受支持的软件；控制措施 2 下的防护措施明确要求确保软件受支持，并处理不受支持的软件。控制措施 7（持续漏洞管理）要求持续评估和跟踪漏洞，并建立具有明确周期性的修复流程。
为何已停产（EOL）软件会造成问题。CIS 是少数几个直接指明该问题的框架之一：未受支持的软件被视为本质上存在漏洞，必须作为例外情况进行记录并采取缓解措施，或者予以移除。以 CIS 为基准进行评估的组织（或其客户和保险公司以此为基准的组织），若存在任何未受管理的已停产组件，都将无法通过内部审计。
示例。一家中型SaaS公司采用CIS控制措施来填写企业安全问卷。其控制措施2（软件清单）显示，有四款应用程序运行在已停止支持（EOL）的框架上。每款应用程序都必须作为有记录的例外情况进行列出，并附上补偿性控制措施和停用日期，或者将其状态变更为受支持状态；若未将其列入清单，不仅会导致该控制措施未通过，更严重的是，会使基于此的问卷答案失实。
对开发者的建议：
- 根据软件包清单和部署工具自动生成 Control 2 库存清单，并为每个框架和运行时添加“支持至”字段。
- 在控制项 7 下，根据严重程度设定整改服务水平协议（SLA），并据此进行考核；该控制项要求建立有规律的流程，而非临时性修补。
- 应将每个已停产（EOL）组件视为一项正式例外情况，需要进行记录、采取缓解措施并设定有效期，这完全符合该控制措施的初衷。
SOC 2 信任服务标准
适用范围：虽属自愿性声明，但对于B2B SaaS和云服务供应商而言实际上是强制性的，因为企业客户在合同中要求提供该报告。
相关要求。《信任服务准则》（特别是CC7.1）要求对新发现的漏洞进行监控、定期扫描、及时修复，并建立有效的补丁和变更管理流程。审计员将测试在审计期间发现的漏洞是否已在该组织自身规定的SLA期限内得到修复，以及该流程是否始终如一地运行。
为什么已停产（EOL）软件会造成问题。SOC 2 II类报告涵盖数月的周期。在此期间，任何一次扫描都会发现存在未修复CVE漏洞的已停产组件，且无法进行修复，这要么会在报告中产生例外项，要么导致报告中对此的解释越来越牵强附会。企业客户会关注这些例外项；SaaS供应商报告中出现的漏洞管理例外项，既是安全问题，也是销售问题。
示例。某SaaS供应商的II类审计周期为1月至6月。 2月，发布了一项针对其构建管道中已停用（EOL）开源工具以及内部服务中某已停用（EOL）Express 的高严重性CVE。根据该供应商自身的政策，高严重性问题应在30天内完成整改。审计员于7月对这些工单进行了抽样检查。由于缺乏上游或商业补丁，截至第120天这些工单仍处于未解决状态，因此报告中注明了该例外情况。
对开发者的建议：
- 制定切实可行的整改服务水平协议（SLA），并切实履行；审计人员会根据贵方自身的政策进行核查，那些目标宏大却无法按时完成的政策，远不如那些目标适中但能切实履行的政策。
- 确保在审计期开始前，范围内的每个组件都已配备补丁来源；若在审计期内发现已停用的软件，则会被记录为持续数月的失职行为。
- 请确保漏洞工单内容清晰完整（包括发现日期、严重程度、修复措施及关闭依据），因为这些工单是审计对象。
ISO/IEC 27001:2022
适用范围：信息安全管理体系的自愿性国际认证，通常通过客户合同和采购要求被强制执行。
相关要求。附件A中的控制措施8.8（技术漏洞管理）要求及时获取有关技术漏洞的信息，评估风险敞口，并采取适当措施。控制措施8.9（配置管理）要求建立、记录、实施和监控配置，包括硬件和软件的基线模板。控制措施5.9要求对信息及相关资产进行盘点。
为何已停用（EOL）软件会造成问题。根据第8.8条规定，针对已停用组件中已知漏洞采取的“适当措施”不能包括等待一个永远不会发布的补丁；组织必须进行升级、隔离、缓解或恢复支持，并须展示决策流程。 根据第8.9条，EOL软件从定义上讲已超出任何可辩护的安全基准范围，因为没有任何加固模板能够弥补一个不断积累无法修复的CVE的组件。认证审核是定期进行的（每年进行监督审核，每三年进行一次重新认证），因此，未受管理的EOL组件在每次审核时都将成为不符合项。
示例。某软件咨询公司持有其政府客户要求的ISO 27001认证。在监督审核期间，审核员抽查了漏洞管理记录，发现客户门户中存在针对已停用（EOL）jQuery 反复扫描结果，这些结果均被标记为“接受风险”并已关闭，且未采取任何缓解措施，未指定负责人，也未设定截止日期。 审核员针对8.8条款提出不符合项：未经评估、处理或设定时限的复审即接受风险，并不属于“适当措施”。
对开发者的建议：
- 将资产清点（5.9）、配置基线（8.9）和漏洞处理流程（8.8）相互关联，使生命周期状态贯穿这三个环节；审计人员越来越倾向于对各项控制措施之间的衔接点进行测试。
- 对已停产（EOL）组件的风险接受决策应设定时间限制、明确责任归属，并配以切实可行的缓解措施，同时按规定间隔进行复审。
- 将SCA和EOL扫描结果直接纳入ISMS的纠正措施流程，从而自动积累“及时”识别和响应的证据。
这对开发者意味着什么：一份综合指南
将二十项框架或法规并列对比后，其规律显而易见。具体时限虽有差异（PCI DSS 6.3.3 和 FedRAMP “高”级别发现要求为 30 天，英国《网络安全基本要求》为 14 天，CRA 和 NIS2 报告要求分别为 24 小时和 72 小时），但其核心要求完全一致，且均为技术要求：
1. 清楚了解您所交付和运行的内容。软件物料清单（SBOM）已不再是可选项。《欧盟产品责任条例》（CRA）将其作为销往欧盟产品的法定要求；PCI DSS 6.3.2 要求提供组件清单；《数字权利法案》（DORA）要求建立包含产品生命周期结束（EOL）追踪功能的 ICT 资产清单；而 CIS 控制项 2、ISO 27001 5.9 以及 NIST CSF 均默认需要 SBOM。 请在持续集成（CI）环境中按每个版本生成 CycloneDX 或 SPDX 格式的 SBOM，并确保其可供查询。当下一场类似 Log4Shell 的事件发生时，上述所有监管机构都期望您能在数小时内回答“我们是否受到影响、受影响的具体位置以及自何时起受影响”等问题。
2. 将生命周期结束（EOL）日期视为合规截止日期。开源项目公布的生命周期结束日期是指，在此日期之后，该项目中出现的任何新CVE都将无法通过常规渠道永久修复。 请以对待证书过期同样的严肃态度，跟踪每个运行时环境、框架和主要库（Node.js、Angular、AngularJS、Vue、React 工具链、Express、Nuxt、Bootstrap、jQuery、Drupal .NET、Spring 以及栈中的其他组件）的 EOL 时间节点。在距 EOL 还有 12 个月时发出警报，在 9 个月前制定计划，并在 EOL 当天之前采取行动。
3. 为每个组件明确指定以下三种状态中的一种：上游正在积极维护；通过提供安全补丁的商业扩展支持协议进行维护（这既符合 NIST CSF PR.PS-02 中“受维护”的要求，又能确保 PCI 的 30 天时限可满足，并保持 FedRAMP POA&M 时间表）；或已安排在确定日期进行替换/移除。 任何未处于这三种状态之一的组件，都是本清单中每位审计员、评估员和监管机构经过培训后会重点排查的漏洞。
4. 为问题修复制定服务水平协议（SLA）并建立相应的监控机制。将基于严重程度的截止日期嵌入问题跟踪系统，测量平均修复时间，并保留问题关闭的证据。SOC 2、ISO 27001、CMMC 和 FedRAMP 归根结底都是证据验证工作：能够通过认证的组织，正是那些在日常工程工作流中自然产生审计轨迹作为副产品的组织。
5. 为那些默认你已知情的报告时限做好准备。加拿大税务局（CRA）的24小时预警（自2026年9月11日起生效，包括已上市的产品）、NIS2的24小时事件预警，以及美国证券交易委员会（SEC）的四个工作日重大性时限，均预设在事件发生前，您已掌握系统各组件的详细信息。请演练以下流程：检测、通过软件物料清单（SBOM）识别组件、影响评估、起草通知。
6. 以书面形式上报生命周期风险。《NIS2》规定管理层须承担个人责任，美国证券交易委员会（SEC）的规则要求董事会对监督披露负责，而澳大利亚的《CIRMP》则要求董事会出具确认书。领导层只能对可见的风险进行管控。一份关于产品生命周期末期（EOL）风险的真实、及时的评估报告，其中包含可选方案（迁移、隔离、延长支持），是工程团队能够产出的最具影响力的文件之一。
该方向为单向通行。 2027年12月CRA的全面实施、NIS2在各成员国逐步成熟、CMMC逐步纳入国防部合同、加拿大CCSPA在获得御准后逐步实施，以及拟议中的HIPAA安全规则全面修订，这些举措都在收紧同一套三大要求：资产清点、及时整改、流程记录。现在就将生命周期意识融入开发流程的开发人员，将来会将这些规定视为例行公事；而未这样做的开发人员，则会将其视为紧急状况。
HeroDevsNever-Ending Support (NES) 如何Never-Ending Support (NES) 产品生命周期结束（EOL）合规性缺口
NES 涵盖了一系列已达到生命周期终止（EOL）的开源框架、运行时和库，这些组件在各类规模的组织中占了大量未解决的 EOL 风险，包括AngularJS、Angular、Vue 2、Node.js、Spring、.NET、jQuery、Bootstrap、Express、Nuxt 等。 NES 通过私有、安全的注册表以及一套完整的合规性构建产物，提供持续的 CVE 修复服务：包括经签名的支持协议、已发布的 CVE 修复日志、发布说明，以及适合纳入 SBOM 的发布版本。
对照前几节所述的义务，NES 将结构上无法实现的内容转化为可验证的覆盖范围：
- 修复时限再次变得可达成。NES 为那些上游项目将不再发布任何修复程序的组件恢复了商业补丁来源，这使得这些时限保持可达成状态，并确保相关问题能够关闭。
- “已维护”成为一个真实的答案。根据 NIST CSF 2.0 PR.PS-02 的规定，软件必须根据风险程度进行维护、替换或移除。由供应商提供的已停产组件补丁即构成“已维护”的状态。
- 遗留系统将转变为受管系统。DORA 和 NIS2 并未禁止使用遗留软件；它们禁止的是未受管理的遗留软件。根据 NES 合同，对于已达到生命周期终止（EOL）的组件，只要具备已承诺的补丁服务水平协议（SLA）和有据可查的整改记录，即可确保该遗留软件的安全性并使其处于商业支持之下。
- 产品生命周期承诺得以持续履行。根据《网络弹性法案》，向市场提供开源组件的制造商在声明的支持期内，有法律义务修复这些组件中的漏洞。NES 提供的回溯补丁，使基于那些上游支持已于数年前终止的框架构建的产品，其支持承诺具有可信度。
在迁移是正确解决方案的情况下，NES 不能替代迁移。它是确保迁移时间表真实可信的机制。组织可以向董事会、审计师和监管机构以书面形式承诺一个切合实际的现代化时间表，同时确保期间出现的每个 CVE 都能按时得到修复并有据可查。
人工智能发现的漏洞频发，正使已停产软件的风险成倍增加。采用NES（非执行系统）的实际效果是：对于在生产环境中运行已停产开源软件的企业而言，其对审计师提问的答复，可从原本可能导致不合格的披露，转变为有据可依且经得起推敲的控制措施。
如需了解最新的技术动态、版本说明以及 CVE 修复文档，请访问herodevs.com和https://docs.herodevs.com/guide/getting-started
参考文献
- PCI安全标准委员会，《支付卡行业数据安全标准》（PCI DSS）v4.0.1，要求6.3.1、6.3.2、6.3.3和11.3.1，2024年6月。https://www.pcisecuritystandards.org/document_library/https://blog.basistheory.com/pci-dss-requirement-6
- Risk Associates，《PCI DSS v4.0.1 如何改变漏洞识别与修复规则》，2026年4月。https://riskassociates.com/blogs/how-pci-dss-v4-0-1-shifts-the-rules-on-identifying-and-fixing-vulnerabilities/
- Endor Labs（与Schellman合作），《从审计师视角看如何应对PCI DSS v4中的开源软件漏洞》，2026年1月。https://www.endorlabs.com/learn/an-auditors-perspective-on-addressing-oss-vulnerabilities-for-pci-dss-v4
- Angular ，终止对AngularJS 的长期支持，谷歌，2022 年 1 月。angularjs
- 《美国联邦法规汇编》，第45卷第164部分，C分部（HIPAA安全规则）。https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164
- Medcurity，《2026年HIPAA安全规则更新：需提前准备的新要求》（总结了OCR于2026年1月发布的关于风险分析和未打补丁软件的网络安全简报），2026年6月。https://medcurity.com/hipaa-security-rule-2026-update/
- 美国卫生与公众服务部民权办公室，《HIPAA安全规则》关于加强电子受保护健康信息网络安全的拟议规则制定通知。https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/index.html
- 《联邦公报》，《HIPAA安全规则：加强电子受保护健康信息的网络安全》，90 FR 898，2025年1月6日。https://www.federalregister.gov/public-inspection/2024-30983/health-insurance-portability-and-accountability-act-security-rule-to-strengthen-the-cybersecurity-of
- Clearwater Security，《HIPAA 安全规则的执行：2026 年的现状》，2026 年 7 月。https://clearwatersecurity.com/blog/hipaa-security-rule-enforcement-2026/
- 美国国家标准与技术研究院（NIST），NIST SP 800-53 第5版：《信息系统与组织的安全与隐私控制措施》，控制措施 SI-2（漏洞修复）。https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf
- FedRAMP 持续监控指南。https://www.fedramp.gov/resources/documents/Continuous_Monitoring_Playbook.pdf
- 美国国家标准与技术研究院，《NIST网络安全框架（CSF）2.0》，NIST CSWP 29，子类别 PR.PS-02，2024年2月。https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
- 美国管理和预算办公室致各行政部门及机构负责人的备忘录，M-26-05，2026年1月23日。https://www.whitehouse.gov/wp-content/uploads/2026/01/M-26-05-Adopting-a-Risk-based-Approach-to-Software-and-Hardware-Security.pdf
- 美国国家标准与技术研究院（NIST），NIST SP 800-218：《安全软件开发框架》（SSDF）1.1版，实践指南PW.4和RV.1–RV.3。https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf
- 网络安全与基础设施安全局，《安全软件开发证明表》。https://www.cisa.gov/secure-software-attestation-form
- 《联邦公报》，第14028号行政命令：加强国家网络安全，2021年5月12日。https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity
- 美国国家标准与技术研究院（NIST），NIST SP 800-171 第3版：《在非联邦系统和组织中保护受控非机密信息》，要求3.14.1。https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171r3.pdf
- 美国证券交易委员会，《网络安全风险管理、战略、治理及事件披露》，公告编号：33-11216；34-97989，2023年7月。https://www.sec.gov/files/rules/final/2023/33-11216.pdf
- 加拿大议会，C-8号法案：《关于网络安全的法案》，修订《电信法》并对其他法案作出相应修订，2026年加拿大法令，第9章，LEGISinfo。https://www.parl.ca/legisinfo/en/bill/45-1/c-8
- 加拿大公共安全部，加拿大政府随着C-8号法案获得御准，加强了网络安全和关键基础设施保护，2026年6月。https://www.canada.ca/en/public-safety-canada/news/2026/06/government-of-canada-strengthens-cyber-security-and-critical-infrastructure-with-royal-assent-of-bill-c8.html
- 博登·拉德纳·杰尔维斯律师事务所（Borden Ladner Gervais LLP），C-8号法案获通过：《关键网络系统保护法》，2026年6月。https://www.blg.com/en/insights/2025/07/bill-c-8-revives-canadian-cyber-security-reform-what-critical-infrastructure-sectors-need-to-know
- 欧盟，《关于金融部门数字运营韧性的第2022/2554号条例》（DORA），第5至15条，EUR-Lex。https://eur-lex.europa.eu/eli/reg/2022/2554/oj
- 欧盟，《(EU) 2016/679 号条例》（《通用数据保护条例》），第 32 条，EUR-Lex。https://eur-lex.europa.eu/eli/reg/2016/679/oj
- 欧盟，《(EU) 2022/2555 号指令》（NIS2 指令），第 21 条和第 23 条，EUR-Lex。https://eur-lex.europa.eu/eli/dir/2022/2555/oj
- NIS-2-Directive.com，《NIS 2 指令》第 21 条：网络安全风险管理措施（全文）。https://www.nis-2-directive.com/NIS_2_Directive_Article_21.html
- Glocert International，《NIS2第21条风险管理措施详解：全部10项控制措施》，2025年12月。https://www.glocertinternational.com/resources/guides/nis2-article-21-risk-management-measures-explained/
- 欧盟，《（EU）2024/2847号条例》（《网络弹性法》），第14条及附件一，EUR-Lex。https://eur-lex.europa.eu/eli/reg/2024/2847/oj
- 欧盟委员会，《网络韧性法案：立法文本摘要》，《塑造欧洲的数字未来》。https://digital-strategy.ec.europa.eu/en/policies/cra-summary
- CyberResilienceAct.eu，《〈网络韧性法〉解读：适用范围、分类及截止日期》，2026年6月。https://www.cyberresilienceact.eu/explained.html
- 是德科技，《距离欧盟《化学品法规》（CRA）合规还有一年：2026年9月11日，一切将发生改变》，2025年9月。https://www.keysight.com/blogs/en/tech/nwvs/2025/09/11/one-year-countdown-to-eu-cra-compliance-september-11-2026-changes-everything
- Mend（通过 Security Boulevard），《欧盟网络弹性法案：2026年及以后的全面合规指南》，2026年5月。https://securityboulevard.com/2026/05/the-eu-cyber-resilience-act-a-complete-compliance-guide-for-2026-and-beyond/
- 信息专员办公室，案件编号 INV/0158/2020。https://ico.org.uk/media2/1kip5gw2/chartered-institiute-for-securities-and-investment-reprimand.pdf
- 信息专员办公室，《数据安全指南》（英国《通用数据保护条例》安全目标）。https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/security/a-guide-to-data-security/
- 英国政府，《2018年网络与信息系统条例》（SI 2018/506）。https://www.legislation.gov.uk/uksi/2018/506/contents
- 英国国家网络安全中心（NCSC），网络安全评估框架（CAF）。https://www.ncsc.gov.uk/collection/cyber-assessment-framework
- 英国国家网络安全中心（NCSC），《网络安全基本要求》（Cyber Essentials）：IT 基础设施要求（14 天更新要求）。https://www.ncsc.gov.uk/cyberessentials/overview
- 日本个人信息保护委员会、《个人信息保护法》（APPI）及PPC指南（英文资料）。https://www.ppc.go.jp/en/legal/
- 日本——2026年网络安全法律法规。https://iclg.com/practice-areas/cybersecurity-laws-and-regulations/japan
- 日本新颁布的《积极网络防御法》：对企业的影响。https://connectontech.bakermckenzie.com/japans-new-active-cyber-defense-law-impact-on-businesses/
- 澳大利亚政府，《2018年关键基础设施安全法》（包括《关键基础设施风险管理计划》规则）。https://www.legislation.gov.au/C2018A00029/latest
- 澳大利亚网络安全中心，“八项基本措施”成熟度模型（应用程序和操作系统的补丁更新；移除不再受支持的软件）。https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/essential-eight
- 互联网安全中心（CIS）《关键安全控制》v8.1版，控制项2（软件资产的盘点与控制）和控制项7（持续漏洞管理）。https://www.cisecurity.org/controls
- 美国注册会计师协会（AICPA），《信托服务准则》（2017年版，附2022年修订的重点事项），准则CC7.1。https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022
- 国际标准化组织，ISO/IEC 27001:2022《信息安全管理体系》，附录A 控制措施5.9、8.8、8.9。https://www.iso.org/standard/27001
- CyberResilienceAct.eu，《〈网络韧性法〉解读：适用范围、分类及截止日期》，2026年6月。https://www.cyberresilienceact.eu/explained.html
- endoflife.date，框架、运行时和数据库的停用日期（由社区维护的参考资料）。https://endoflife.date/
- Node.js 项目（OpenJS 基金会）、以往版本及生命周期终止计划。https://nodejs.org/en/about/previous-releases
- Vue.js 团队Vue 2 （2023年12月31日）。https://v2.vuejs.org/eol/
迈出第一步。
立即查看您的 EOL 风险。
只需几分钟，即可对您的代码库运行一次免费的EOL扫描。
无需任何承诺，也不需要接听销售电话。
.webp)
