我们继承了一套既不安全也不符合合规要求的遗留代码库

你必须为团队从未编写过的代码中的漏洞负责,而修复这些漏洞会占用本应投入到其他地方的工程时间。HeroDevs 会将已到生命周期末期的依赖项固定在它们最初引入时的版本上,而无需进行任何无人规划的重写工作。

仪表盘显示,acme-corp 没有警报,而 2026 年 3 月收购的 orbit-labs 则有多个未解决的警报。

尽职调查报告中未附带整改方案

交易已完成,代码库归你们所有。你们团队中没有人编写过这些代码,而实际编写这些代码的工程师可能并未随交易一同加入。尽职调查报告虽然指出了已停用的依赖项,却未提供任何整改方案。这些依赖项已不再获得维护者的安全补丁,因此上游也不会对此进行修复。

这些漏洞现在已被列入您的风险登记册,归入您的名下,而解决这些漏洞的工作与业务部门已承诺的截止日期存在时间冲突。在制定本季度计划并作出承诺时,这些工作根本不存在。

当上游补丁停止发布时,哪些功能会出问题

安全

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

合规

没有证据表明

路线图与预算

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

时间线显示,已修复安全补丁的开源软件(OSS)将过渡到生命周期结束阶段,届时将存在未修复的CVE漏洞。

了解您实际继承了什么

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

软件扫描摘要显示:共扫描了 1701 个软件包,其中 218 个已达到生命周期终止(EOL),1322 个未达到 EOL,157 个状态未知,并附有风险指标。

问题

每种方案都会将收购的代码库交还给你们的工程师

将其重写到你的栈上

这是标准的集成方案,也是成本最高的一种。你正在重新构建一款已经付费购买的产品,且这一进程的时间安排将延迟交易所依据的所有协同效应的实现,同时还动用了本应开发其他项目的工程师。

推迟到集成之后再处理

从理论上讲这很合理,但安全漏洞不会等待你的整合计划,它们已经出现在你的登记册上了。无论被收购的团队此前对此采取了什么措施,这些发现现在都由你来负责。

让人工智能来做

这种方式既快捷,又日益成为人们的期待,因为模型能够解析团队中无人能懂的代码,并在几分钟内返回修复方案。但独立研究发现,近一半由人工智能生成的代码会引入新的漏洞,而未经审核的补丁则引发了一个悬而未决的问题:究竟由谁来为此负责?对于团队未亲自编写的代码,这个问题无人能给出明确答案。

解决方案

无需理解代码库即可保障其安全性

了解你的遗传基因

扫描已获取的代码库,并列出所有已达到生命周期终止的依赖项(包括直接依赖和传递依赖),且无需原开发团队参与。

确保所收购的代码库保持在交易中包含的版本上

即插即用型替代方案,由工程师构建,因此应用程序可以继续按原样运行,而无需在强制迁移过程中重新构建。

支持服务没有有效期。

只要您继续使用该软件,新出现的 CVE 漏洞就会根据 SLA 进行修复。

为什么选择 HeroDevs?

1900多万

已跟踪的软件包版本

1,000+

已修复的安全漏洞

900+

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

Statista 标志

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

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

您继承的每个已停用依赖项的清单,以及取代它们的安全版本

该风险报告显示,在六个代码库中,共扫描了 8,412 个依赖项,其中 1,247 个已达到生命周期终止。该拉取请求将 package.json 中的依赖项中 framework-core 的版本从 4.2.0 更改为 4.2.0-nes.7。

工程和安全团队会问什么


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

我们目前还不清楚代码库里都有什么内容。我们该从哪里着手呢? 
这在我们团队中没有人编写过的代码库上能行得通吗? 
如果参与建造它的工程师们并不包含在交易中,那该怎么办? 
我们定期进行收购。这种情况在各项交易中是否普遍存在? 
我们计划最终停用这款应用。还有必要报道它吗? 
那么,随此次收购而来的合规义务又该如何处理呢? 

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