1.硬编码秘密或资源引用

太敏感而无法查看或随时间变化的信息（例如密钥，代码，IP地址，域名，别名或帐户名）应分配为具有适当名称的变量。作为经验法则，出于安全目的，不应在版本控制中对此类信息进行硬编码。这也非常不方便，因为如果我们旋转一些密钥或机密，我们将需要一个新的提交和审查阶段，如果部署不当，则可能会阻塞或延迟数小时或数天。取而代之的是，所有此类数据应存储在专门的服务中，以按需注入所需的秘密或上下文变量。

2.将状态文件提交到版本控件中

对于用户，状态文件是启动计划时创建的项目。它们包含用于特定基础结构的有用的元数据和配置选项。可以理解，将敏感值存储在此并将其提交到版本控制中的可能性更大。当其他人试图从版本控制中检出代码时，这会带来其他问题。状态文件会过时或不完整。他们可能终会部署难以安全回滚的错误或不安全的基础架构组件。

3.在部署之前或之后不执行健全性和安全性检查

在使用模板或状态计划之前，您可以选择针对当前基础结构部署对其进行验证。这将有助于捕获任何语法错误；但重要的是，在此过程中可能会发生任何意想不到的破坏性变化，另外，在完成部署之后，还应该进行其他健全性和安全性检查，以回答常见的问题：部署的基础架构是否安全？部署是否留有开放端口？部署是否没有正确破坏未使用的资源？

4.使用不受信任的图像或插件

如果图像和实例具有漏洞，则使用旧的或来自未知来源的图像和实例可能会带来安全风险。如果您使用来自第三方的IaC插件，则会发生相同的问题，仅仅因为它们是开源且公开的，并不意味着它们是可信赖的和可靠的。实际上，除非建立了全面的安全检查，否则它们会带来很大的安全风险，因为它们可能会在运行时泄漏数据或执行不安全的部署，在实际使用之前，应对图像或插件的功能进行良好的对等审查和评估。

5.不重用代码并将所有内容放在一个文件中

将所有配置和模板放在一个文件中是灾难的根源，这是因为它们可能不会融合在一起。增加配置数量可能导致大量重复代码，此代码重复导致难以理解的模板，从而导致更多配置漂移，终可能在生产中出现。IaC模板应按环境和逻辑边界进行企业。

应当在早期建立一些组织政策

只有这样，我们才能确保避免一整套错误和风险，使未经检查的代码进入生产空间。坚持良好的工程实践并保持领先地位总是可以从根本上避免这些风险。

商业联合会数据分析专业委员会