5.4 遗留软件

如果我们看看开源生态系统中为解决供应链问题而推出的所有优秀项目，包括现代应用开发框架和工具，这无疑展现了一个特别乐观的前景。但是，这对于遗留软件意味着什么呢？

特别是在关键基础设施或国防领域——这些地方的系统使用寿命经常是20到30年，甚至更长——以及在没有使用包管理器的情况下生产的软件，源代码可能已经不再可用，原开发人员也许已经退休，或者更糟的是，已经不在人世了。我们面对的是一套截然不同的问题。在某些情况下，软件已经不再得到支持，或者只能定期应用定制补丁。在这些情况下，逆向工程可能是确定软件构成的唯一可行选项。不过，让我们再来探讨一下处理专有软件的另一个挑战，在遗留软件的背景下，这变得尤为有趣。

很久以前，几乎所有的软件都是专有的。虽然有时与学术界分享，或出于其他信息共享的原因，但总体来说，当我们思考当前开源软件（OSS）的定义时，带有明确定义的许可证的这种结构化概念，仅在过去大约25年左右才逐渐形成。当然也有一些例外，例如glibc（GNU C库）和GNU编译器集合（GCC），其中C编译器可以追溯到1987年。然而，当比较30多年前构建的软件和今天构建的软件时，我们会发现现代软件中有更多的组件是可以识别和理解的。

为什么开源概念如此重要呢？因为大多数应用安全工具今天并不考虑专有软件的生产过程。当前市场上绝大多数的软件物料清单（SBOM）工具只会告知您，基于已知的开源组件，您的软件是否存在漏洞。对于几乎没有或没有任何开源组件的遗留软件来说，这是一个巨大的盲点。事实上，许多SBOM工具只有在您的软件构建过程中使用了包管理器时才能发挥作用。虽然Linux已经使用包管理超过20年，但像Python和Node.js这样的现代语言的包管理工具只有大约10年左右的历史。现代的SBOM工具是根据当前的使用情况开发的，而不是几十年前在许多环境中仍然广泛使用的技术。例如，Python的包安装器pip是在2014年随Python 2.7.9引入的。

如果源代码不可用，静态分析工具就无法评估它。如果没有运行时环境进行仪表化，使用现代交互式应用安全测试（IAST）工具进行验证将变得非常具有挑战性。而且如果研究人员无法访问源代码，那么几乎可以肯定，没有公开的CVE（公共漏洞披露）能够帮助理解那些专有代码何时极为脆弱。事实上，在许多情况下，理解软件的构建方式几乎是一个黑盒子。唯一的救赎是，如果软件存在漏洞，且这不是一个新的风险。不利的一面是，这些软件往往是地球上一些最关键的软件，例如运行导弹发射井、核反应堆、水处理厂等设施的软件。