将公司机密硬编码到代码中是一个严重的可以避免的安全风险。
译自 How to Prevent Secrets from Creeping into Code，作者 Robert Curlee。
机密信息经常出现在已发布的代码中，从而使所有者面临安全风险。这些机密信息包括密码、API 密钥、加密密钥、令牌、数据库凭据和其他私有公司信息。
在源代码中硬编码机密信息很危险，尽管开发人员付出了最认真的努力，但机密信息仍然可能渗入。开发人员在编写代码时可能会采取捷径并将机密信息传递给代码，或者他们可能没有意识到代码中机密信息的影响。此外，大多数扫描解决方案都将确定代码被标记为问题的原因留给开发人员。最后，大多数工具在泄漏发生后才会在代码存储库中查找机密信息，这需要痛苦的补救措施（即轮换机密信息）。
由于时间限制，正确管理、存储和保护机密信息可能会变得复杂、被误解或干脆被跳过。此外，如果公司不知道机密信息何时何地进入项目，他们就无法防止机密信息随项目发布而泄露并损害其安全性。
定期渗入代码的凭据和其他机密信息会成为新闻头条 — 并且由于人为错误，曝光 的数量正在增加。在 IDE 和整个 CI/CD 管道中捕获机密信息的工具（在它们有机会造成问题之前）是改变游戏规则的工具。
能够在机密信息在代码中泄露之前检测到它们，使组织能够降低其风险敞口。通过在 IDE 中检测到它们，您可以避免通过轮换机密信息来补救它们的痛苦。但首先，您需要了解机密信息如何最终进入代码。原因有以下几个：
可能由于缺乏经验或培训不当，一些开发人员可能根本不了解适当的机密信息管理和源代码安全性。只要有一名开发人员不知道在代码中处理机密信息的最佳实践，就会使公司落入威胁参与者手中。如果知识就是力量，那么最好的防线就是一支知识渊博的团队。
开发人员可能会临时硬编码凭据或机密信息以进行快速本地测试，并打算之后将其删除。但是，有时这些文件会被意外提交到公共存储库，从而使这些临时更改变为永久更改。即使之后删除了代码，也有人可能在清理之前复制了包含机密信息的代码。犯错是人之常情，但当后果可能产生巨大影响时，最好尽可能主动防止错误。
自己解决问题是一种很好的学习方式，有时问题非常具体，唯一的方法就是自己动手解决。如果它占用大量时间并且您找不到解决方案，最好从产品文档和 Stack Overflow 等网站中寻求帮助。但是，虽然这些材料提供了有用的解释和示例，但它们不应被简单地复制粘贴并表面上信任。
Stack Overflow 和文档中的代码可以回答问题，但这不是实现解决方案的最安全方法。例如，文档通常包含代码片段来说明产品的特性，但可能不会提及是否应谨慎使用以及是否有更安全的选择。结果？糟糕的代码。您引入代码库的任何解决方案都应经过适当评估，以确认它符合质量标准，并且不会给代码带来问题。
导致机密信息泄露到代码中的另一个信任问题是 AI 生成的代码的使用增加。随着生成式 AI 在代码开发中变得越来越流行，您会发现需要扫描的代码行数和机密信息问题数量都会增加。AI 生成的代码可能会让您认为连接到服务的正确方法是硬编码令牌或机密信息。根据提示的质量和对这个问题的认识，AI 可能不会生成干净的代码，并且可能导致机密信息泄露。AI 生成的代码可以作为了解如何连接到服务的基础，但您必须对其进行修改以使用机密信息保管库。
最终，您必须挑战您使用 AI 找到或生成的任何代码。组织必须确保其开发人员团队拥有适当的代码质量工具，以防止机密信息渗入代码，并在代码开发的尽可能早的阶段解决任何泄露问题。
当在引入点标记公开的机密信息时，无论是在编码期间实时进行还是在即将提交时进行，都可以为团队节省很多麻烦。人为错误时有发生，但通过在正确的时间进行正确的检查，您可以尽早防止错误的后果。
在开发工作流中检测和解决这些问题最好的地方是在一开始，在 IDE 中。SonarLint、SonarQube 和 SonarCloud 中的机密信息检测功能使组织能够检测源代码中的公开机密信息，消除其泄露，并降低对私有数据进行非法或未经授权访问的安全风险。使用 SonarQube Enterprise Edition 10.3 及更高版本的开发人员还可以创建自定义机密信息模式检测规则。将它们与 Clean as You Code (CaYC) 和 Learn as You Code 方法配对支持交付 干净代码 — 生成可维护、可靠且安全的软件的代码。
通过从开发一开始就在 IDE 中消除代码中的机密信息，团队可以防止机密信息进入其存储库。在项目开发的早期阶段检测和删除机密信息可减少在发布周期后期发现公开机密信息时所需的复杂且昂贵的补救措施。