潜伏在源代码中的硬编码凭证对供应链攻击意味着什么？

2021年，“供应链攻击”已经成为了信息安全行业中最热的一个名词。

所谓供应链攻击是指，当黑客操纵第三方软件组件中的代码去破坏它们“下游”的应用程序时，就会造成一次由软件供应链传导而来的攻击。2021 年备受关注的SolarWinds攻击、Kaseya攻击和Codecov数据泄露等大规模安全事件，都极大地动摇了企业对于第三方服务提供商的信心。

事实上，在供应链安全中，潜伏在源代码中的硬编码凭证仍然是应用程序安全领域中最容易被忽视的漏洞之一，在源代码中消除硬编码凭证，是确保当前软件开发生命周期安全的第一要务。

硬编码凭证是指在应用程序、服务或基础设施中使用的数字身份验证凭证（API 密钥、证书、令牌等）。就像个人密码用于验证个人身份一样，硬编码凭证验证系统以实现互操作性。但与个人密码不同，硬编码凭证会被分发出去。

具体来说，为了不断提供新功能，软件工程团队需要互连越来越多的构建块，组织间不同团队协作产生的（开发小组、SRE、DevOps、安全等）的凭证数量激增。甚至有时开发人员会将密钥保存在不安全的位置，以便更轻松地更改代码，但这样做通常会导致信息被错误地遗忘并无意中发布出去。

在应用程序安全环境中，硬编码凭证实际上是一种类似于后门的漏洞。首先，由于源代码是一种非常容易泄露的资产，意味着它会在多台机器上经常被克隆、签出和分叉，因此凭证也很容易泄露。更令人担忧的是，代码也会有“记忆”。

任何代码库都会使用某种版本控制系统 (VCS) 进行管理，保留对其进行的所有修改的历史时间表，有时甚至长达数十年。问题是仍然有效的凭证可以隐藏在这个时间线上的任何地方，从而为攻击者打开了一个新的窗口。大多数安全分析仅在代码库的当前、准备部署状态下进行，当涉及到旧提交甚至从未部署的分支中的凭据时，这些安全工具大多是无效的。

据统计，2021年GitGuardian检测到超过 600 万个泄露的硬编码凭证推送到 GitHub 上，比 2020 年翻了一番。平均而言，1000 个提交中有 3 个包含凭证，比2020年高出 50%。

这些硬编码凭证中有很大一部分都能够提供对公司资源的访问权限。因此，攻击者如果试图入侵目标企业系统，通常也会先尝试查看其在 GitHub 上的公共存储库，然后再查看其员工拥有的存储库。事实上，许多开发人员将 GitHub 用于个人项目，并且可能会意外泄漏公司凭据。使用这些泄露在外的公司凭据，攻击者可以伪装成合法的身份进行登录操作，绕开部署在边界的安全检测工具。

调查显示，每当有硬编码凭证被推送到 GitHub 后被窃取的时间仅为 4 秒，这意味着有大量攻击者都对这份资产表现出了兴趣和觊觎。

企业的另一个严重错误是容忍非公共存储库中存在硬编码凭证。GitGuardian 在State of Secrets Sprawl 报告中指出，私有存储库比公共存储库隐藏的硬编码凭证要多得多。这些被遗忘的凭证如果被黑客窃取，毁灭性的打击随时都有可能到来。

坦白来讲，应用程序安全团队或许很清楚这个问题。但是，要调查、撤销潜伏在代码中的这些隐患，甚至将过去多年来积攒下来的祸根一一拔除，其背后的工作量几乎是难以想象的。

GitGuardian指出，GitHub 并不是唯一存在硬编码凭证的地方，任何注册表（如 Docker Hub）或任何源代码泄漏都可能成为攻击者寻找利用向量的金矿。

在不久前的一起安全事件中，Twitch 的全部代码库发生了泄露，造成 6000 多个 Git 存储库和 300 万份文档泄露。其中包含了数百个 AWS、Google、Stripe 和 GitHub 的密钥。只需组合其中几个密钥，就足以对目标企业最关键的系统发起全面攻击。

在数年前优步发生的攻击事件中，就是一名员工不小心在他自己的公共 GitHub 存储库上发布了一些公司代码，攻击者发现并检测到了云服务提供商授予访问优步基础设施的密钥，利用这一可乘之机对优步发起了大规模的攻击行动。

事实告诉我们，攻击者正在监视企业的每一名开发人员，通过他们发布的企业代码来寻找入侵企业的捷径。上述的安全事件只是冰山一角，可能还有更多涉及硬编码凭证的违规行为没有公开披露。

硬编码凭证是任何软件堆栈的核心组件，正是它特别强大，因此它需要非常强大的保护。硬编码凭证的分布式特性和现代软件开发实践使得很难控制它们的最终位置，无论是源代码、生产日志、Docker 映像还是即时消息应用程序。

随着企业界使用越来越多的服务和基础设施，泄漏的硬编码凭证数量正在以非常快的速度增长。越早采取行动，就越容易保护源代码免受未来威胁。