CVE漏洞层出不穷，迫使工程师进行计划外的维护

这不是一个可以“清零”的待办事项列表。借助 Evergreen，应用程序中的每个依赖项都会受到监控，并在达到生命周期终止时得到妥善处理——无论是在今天，还是两年后。

在已停止维护的软件包中，每个 CVE 都是一个项目

工程师需要评估该漏洞的影响，阅读上游的修复方案，将其回溯移植到该修复方案原本未针对的版本上，测试确保其他功能不受影响，然后发布该修复。一旦开源项目达到生命周期终止（EOL），维护者将停止发布安全补丁，因此针对该项目的每个新CVE都将成为贵团队的工作，而非由上游发布。

这些工作都不是计划内的。它们占用了原本用于处理其他事务的资源，而你仍然需要对完成这些其他事务负责。随着开源依赖关系树的不断扩展和CVE数量的攀升，工作中被打断的情况也随之增多。

安全

CVE 漏洞已公开，尚无修复方案

合规

没有证据表明

路线图与预算

迁移已完成，速度未按计划

获取一份关于您所有代码库中所有已过生命周期的依赖项（包括直接依赖和传递依赖）的报告。

获取您的辐射暴露报告

问题

安排专人长期负责此事

轮值维护使工作具有可预测性，同时并未减少工作量。你已将中断转化为一项固定成本，而当值工程师在该季度内并未参与任何项目开发。

依靠自动更新

Dependabot 和 Renovate 基于已发布的版本进行匹配。对于已停止维护的版本，其上游没有发布包含修复程序的版本，因此会触发警报，且不会生成拉取请求。该工具确认了该漏洞的存在，因此无法关闭该警报。

使用人工智能生成修复方案

这种现象发展迅速，且日益普遍。独立研究发现，近一半由人工智能生成的代码会引入新的漏洞，而未经审查的补丁若未能修复该漏洞或导致生产环境故障，将引发一个悬而未决的问题：究竟该由谁来承担责任。

解决方案

只需将您的代码库连接一次

在构成您应用程序的各个代码库中安装 HeroDevs GitHub 应用。

每个依赖项都有一个状态

扫描会自动运行。在支持期间，每个依赖项都会受到监控；一旦达到生命周期终止且出现 CVE，该依赖项就会被加入修复队列。

替换内容以拉取请求的形式提交

每个依赖项仅允许提交一个公开的拉取请求，按严重程度排序，且每日有数量上限。您可以根据自己的日程安排进行审核和合并。

获取定价

1900多万

已跟踪的软件包版本

1,000+

已修复的安全漏洞

900+

由 HeroDevs 提供安全保障的企业客户

我们在不影响战略路线图的前提下，维持了现有安全态势，同时与全面迁移相比，实现了可观的成本节约。

马库斯·沃尔夫，Statista 架构师

当然，如果您找不到想要的答案，请随时联系我们。

这里没有涵盖的内容？ 咨询专家。