《韦氏词典》将秘密定义为不让他人知道或仅与少数人秘密共享的东西。现代软件开发团队使用密码、令牌和 API 密钥等软件机密来正确设置、保护和维护开发环境和交付管道，并为云原生应用程序启用对 AWS Buckets 或 Azure Blob Storage 等服务的编程访问。然而，虽然秘密对于现代软件的运行至关重要，但它们很难跨交付阶段进行管理。软件团队常常会因为复杂性而绊倒，并无意中将这些秘密暴露在公共和私有软件存储库中。

潜在的暴露可能源于许多因素：纯文本密码、弱加密、有缺陷的 CI/CD 或打包自动化以及受损的开发人员帐户或恶意内部人员。无论出于何种原因，不良行为者都会定期搜索存储库和应用程序二进制文件，以获取他们可以利用的硬编码秘密。看看 CircleCI 和 CodeCov 事件就知道了，这些事件中暴露的秘密使这些组织容易受到意图攻击软件供应链的对手的攻击。

重新思考秘密的优先顺序

据 GitGuardian 分析，2022 年 GitHub 上有1000 万起新的机密事件被曝光，与该公司 2021 年的调查结果相比增加了 67%。随着软件变得越来越大、越来越复杂（使用开源、第三方和商业组件），检测到的秘密数量只会增加，从而带来不同的挑战：修复的优先级。

遗憾的是，团队缺乏可扩展的方法来了解开发人员无法或不应该修复哪些检测到的秘密。如今，团队必须手动筛选潜在的数千个检测并了解其上下文以对这些威胁进行分类。获取上下文意味着发现秘密所在的位置（在您的代码中、在软件依赖项中、在软件附带的文档中）并了解其目的（访问资源、启用用户测试、启用入侵检测）。

当团队考虑如何简化和自动化秘密优先级时，需要考虑的重要问题包括：

• 您的开发人员负责保护哪些秘密？例如，用于访问内部 CI/CD 管道技术的秘密。根据权限的不同，泄露这些秘密可以让恶意行为者在无人知晓的情况下更改自动化构建流程。同样，API 凭据用于访问其代码运行所需的数据或服务。泄露这些秘密可以让恶意行为者以编程方式访问这些 API，这可能成为客户数据的金矿或进一步危害环境。

• 哪些秘密值得保护？有些您可能需要负责，但不值得保护。例如，为了促进自动化软件测试，开发人员通常在公共存储库中与应用程序一起发布 API 密钥和证书，或者在捆绑到发布包或软件容器中的文档中发布 API 密钥和证书。由于这些测试“秘密”旨在共同共享，因此不应对其进行加密或保护。

• 哪些检测到的秘密不可操作？例如，开发人员通常无法管理第三方或商业组件中的秘密以及软件内的依赖项。相反，这些风险暴露代表了第三方风险管理问题。另一个例子是通过安全操作添加到软件中的金丝雀秘密；修复这些秘密会妨碍入侵检测。

一旦团队建立了秘密定义，接下来就是建立一个流程来识别它们并确定其优先级。

管理秘密

任何参与软件开发的组织都应该有明确的规则来处理秘密并将其合并到代码中，以及向开发人员传达该过程和这些规则。以下是每个组织都应考虑的秘密最佳实践：

●推广开发人员最佳实践并监控合规性：如果开发组织缺乏正确管理代码中秘密的明确指南以及实施这些指南的易于使用的工具，那么秘密泄露更有可能发生。DevOps 团队应根据对开发环境中如何生成机密、部署后如何保护这些机密以及（希望如此）它们最终如何循环使用的理解来制定策略。

●改进应用程序使用机密的方式：以消除对驻留在代码中的访问令牌的依赖的方式设计应用程序。使用 OAuth OpenID Connect (OIDC) 令牌等技术，允许开发人员对用户进行身份验证，而无需直接在代码中公开用户凭据。通过使用多重身份验证、利用身份和访问管理平台以及设置 IP 范围（将 API 的入站连接限制为已知地址或地址范围）来降低滥用风险。

●建立端到端安全性： CI/CD 工具或发布监督中的错误配置可能会导致在最终构建期间包含机密，否则这些机密可能会在代码审计期间逃脱注意。考虑实施二进制分析，以将泄露的秘密的可见性扩展到原始代码之外以及准备发布的软件包和容器中。此功能可以检测由于构建或打包自动化而暴露的秘密。

●简化秘密优先级：嘈杂的扫描结果会产生大量分类工作，只是为了在开始修复之前清除误报（例如，广泛分布的测试密钥或网络凭证占位符）。使用相关文件智能自动执行部分分类可以节省无数时间，并确保开发人员专注于解决实际风险。

没有银弹

不幸的是，对于软件供应链风险和攻击，以及泄漏和暴露，没有“灵丹妙药”解决方案。相反，组织需要一种整体方法，包括确定问题范围，解决泄露凭证带来的短期风险，然后将变革扩展到所有流程，着眼于消除识别、优先排序和补救秘密泄露的繁琐工作，从而防止潜在的泄露在供应链攻击发生之前。