代码完整性风险：无服务器安全中被忽视的问题

DevOps 和开发人员很容易喜欢上无服务器应用程序，因为它提供了高度可扩展、简单且“无基础架构”的应用程序部署方式。无服务器让开发人员可以专注于重要的事情——编写代码——而不是配置他们的应用程序基础设施。

然而，无服务器也带来了一些挑战，最大的挑战是它们的无状态执行或收集准确的指标。在安全方面，Serverless 功能几乎没有独特的风险和挑战。在本博客中，我们将重点关注被称为软件供应链的新攻击向量，黑客会在其中修改应用程序代码，同时在持续集成 (CI) 中编写它。这就是为什么战略性地思考如何验证完整性至关重要的原因在您的开发管道中，尽可能早且经常地在无服务器函数中添加代码。

供应链攻击和代码完整性风险

当我们谈论代码完整性时，我们指的是验证无服务器函数中的代码实际上是开发人员认为的那样的能力。如果黑客能够通过在部署功能之前对其进行修改来破坏代码的完整性，则黑客可能会插入恶意代码，从而暴露敏感数据、破坏应用程序功能或以其他方式对您的业务造成严重破坏。我们在这里讨论的代码完整性风险类型不仅仅是理论上的。他们已经成为近年来一些最重大攻击的幕后黑手。

SolarWinds 泄露的源代码

在此期间，黑客侵入了该公司的软件交付工具并修改了代码，从而危害了 18,000 名下游用户。

如果有一个系统的流程来验证部署到生产 SolarWinds 环境中的代码是否与开发人员编写的代码相匹配，那么黑客可能已经被检测到。然而，没有，因此它成为历史上最具灾难性的软件供应链攻击之一。

当然，代码完整性风险并不是无服务器安全所独有的。从理论上讲，黑客可以对任何类型的应用程序发起这种类型的攻击，包括容器化的应用程序。然而，无服务器安全性的问题在于，更难验证无服务器功能的完整性。大多数容器镜像在构建镜像 (CI) 或推送到托管它们的注册表时使用加密摘要 (SHA256) 进行签名。这允许在部署之前验证它们。相反，无服务器功能是在您的云环境中编译的，并且可以根据其部署框架（例如无服务器框架）而有所不同，这使得在部署之前几乎不可能进行验证。因此，

如果您认为黑客无法以这种方式篡改您的代码，请再想一想。薄弱的云访问控制、不安全的云帐户共享或组织内恶意内部人员的攻击都可能成为在部署之前修改无服务器功能中的代码的媒介。

为无服务器函数的代码完整性添加代码签名

为了避免成为供应链攻击的下一个受害者，现在是时候确保您拥有严格的代码验证流程了。为此，您需要在 CI 阶段集成代码时使用加密哈希函数对代码进行签名。我们在 Cisco 采用的方法是通过使用OpenSSF SigStore项目应用它来签署无服务器功能持续集成 (CI) 阶段的代码开发。我们添加了一个补充验证机制，我们将作为开源贡献给社区，基于 CI（公钥/私钥对）生成的加密签名验证任何新的或修改的无服务器功能。

无论软件来自何处，这都大大提高了检查数据真实性的效率。这种标准化方法不仅适用于当前的集成，也适用于未来的集成，并为 DevOps 提供了简单的代码签名、透明度和可审计的数据。通过统一执行这些任务，部署未经验证的代码的可能性大大降低。