编码员征服安全基础设施即代码系列--使用来自不信任来源的组件
我们的 "基础设施即代码 "系列已接近尾声，但能帮助像你这样的开发者在IaC安全之路上走得很好。
你一直在进行挑战吗？到目前为止你的分数是多少？在我们开始之前，让我们看看你对使用来自不可信任来源的组件的陷阱已经了解多少。
仍有一些工作要做？继续阅读。
我们今天要关注的诱发漏洞的行为是使用来自不受信任的来源的代码，这种看似良性的做法正在造成大问题。使用开放源代码和资源有很多好处。一般来说，它允许专家将他们的想法、工作甚至是已完成的代码贡献给GitHub这样的存储库，供其他努力使程序或应用表现正常的人使用。使用已完成的代码来管理程序功能，使开发人员不必在每次需要创建新的应用程序时重新发明车轮。
然而，使用来自不可靠的、未经审查的、甚至有潜在危险的来源的代码片段会带来很多风险。事实上，使用来自不受信任的来源的代码是主要和次要安全漏洞潜入其他安全应用程序的最常见方式之一。有时，这些漏洞是由它们的创造者意外地诱发的。也有潜在攻击者编写恶意代码的情况。然后，这些代码被分享出来，希望能诱使受害者将其放入他们的应用程序中。
为什么使用来自不受信任来源的代码是危险的？
比方说，一个开发人员很匆忙，需要配置他们正在开发的一个应用程序。这可能是一个棘手的过程。因此，与其花大量的时间去研究每一种可能的配置，不如在谷歌上搜索一下，发现有人已经完成了一个看起来很完美的配置文件。尽管开发者对写代码的人一无所知，但将其添加到一个新的应用程序是相对容易的。它可以在Docker环境中使用两行来完成。
RUN cd /etc/apache2/sites-available/ &&
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
现在，Docker镜像将动态地拉入第三方的配置文件。即使该文件在当时被测试并发现没有问题，但现在该指针被嵌入到新应用程序的代码中，这意味着存在一个永久的依赖关系。几天、几周或几个月后，该文件可能被原作者或入侵代码库的攻击者修改。突然间，共享的配置文件可以告诉应用程序以非常不同的方式执行，可能让未经授权的用户访问，甚至直接窃取数据并将其渗出。
使用共享资源的更好方法
如果你的组织允许使用外部来源的代码，那么就必须制定程序，以确保安全地进行。当评估可能使用的外部代码时，要确保只使用安全链接从官方来源获得组件。即使如此，你也不应该链接到外部来源来拉动该代码，因为这使该过程脱离了你的控制。相反，经过批准的代码应该被带入一个安全的库中，并且只能从这个受保护的地方使用。因此，在Docker环境中，代码将看起来像这样。
复制 src/config/default-ssl.conf /etc/apache2/sites-available/。
这将取代对远程第三方配置文件的依赖，而是依靠这些文件的本地副本。这将防止任何意外或恶意的改变。
除了使用安全代码库外，还应该建立一个补丁管理程序，在整个软件生命周期内持续监控组件。所有客户端和服务器端的组件也应使用NVD或CVE等工具进行安全警报检查。最后，删除任何未使用或不必要的依赖和功能，这些功能可能与外部代码一起出现。
通过遵循这些步骤，开发人员可以更安全地利用外部资源，而不会意外地将漏洞诱发到他们的应用程序和代码中。
请查看 Secure Code Warrior博客页面，了解有关这一漏洞的更多见解，以及如何保护您的组织和客户免受其他安全缺陷的破坏。你也可以在Secure Code Warrior 培训平台上尝试演示IaC挑战，以保持你的所有网络安全技能得到磨练和更新。
马蒂亚斯-马杜博士
马蒂亚斯是一名研究员和开发人员，拥有超过15年的软件安全实践经验。他曾为Fortify Software和他自己的公司Sensei Security等公司开发解决方案。在他的职业生涯中，马蒂亚斯领导了多个应用安全研究项目，并将其转化为商业产品，他拥有超过10项专利。当他离开办公桌时，Matias曾担任高级应用安全培训courses ，并定期在全球会议上发言，包括RSA会议、黑帽、DefCon、BSIMM、OWASP AppSec和BruCon。
马蒂亚斯拥有根特大学的计算机工程博士学位，在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。
在博客上深入了解我们最新的安全编码见解。
我们广泛的资源库旨在增强人类对安全编码技术提升的方法。
获取关于开发者驱动的安全的最新研究
我们广泛的资源库充满了有用的资源，从白皮书到网络研讨会，让你开始使用开发者驱动的安全编码。现在就去探索它。
编码员征服安全基础设施即代码系列--使用来自不信任来源的组件
我们的 "基础设施即代码 "系列已接近尾声，但能帮助像你这样的开发者在IaC安全之路上走得很好。
你一直在进行挑战吗？到目前为止你的分数是多少？在我们开始之前，让我们看看你对使用来自不可信任来源的组件的陷阱已经了解多少。
仍有一些工作要做？继续阅读。
我们今天要关注的诱发漏洞的行为是使用来自不受信任的来源的代码，这种看似良性的做法正在造成大问题。使用开放源代码和资源有很多好处。一般来说，它允许专家将他们的想法、工作甚至是已完成的代码贡献给GitHub这样的存储库，供其他努力使程序或应用表现正常的人使用。使用已完成的代码来管理程序功能，使开发人员不必在每次需要创建新的应用程序时重新发明车轮。
然而，使用来自不可靠的、未经审查的、甚至有潜在危险的来源的代码片段会带来很多风险。事实上，使用来自不受信任的来源的代码是主要和次要安全漏洞潜入其他安全应用程序的最常见方式之一。有时，这些漏洞是由它们的创造者意外地诱发的。也有潜在攻击者编写恶意代码的情况。然后，这些代码被分享出来，希望能诱使受害者将其放入他们的应用程序中。
为什么使用来自不受信任来源的代码是危险的？
比方说，一个开发人员很匆忙，需要配置他们正在开发的一个应用程序。这可能是一个棘手的过程。因此，与其花大量的时间去研究每一种可能的配置，不如在谷歌上搜索一下，发现有人已经完成了一个看起来很完美的配置文件。尽管开发者对写代码的人一无所知，但将其添加到一个新的应用程序是相对容易的。它可以在Docker环境中使用两行来完成。
RUN cd /etc/apache2/sites-available/ &&
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
现在，Docker镜像将动态地拉入第三方的配置文件。即使该文件在当时被测试并发现没有问题，但现在该指针被嵌入到新应用程序的代码中，这意味着存在一个永久的依赖关系。几天、几周或几个月后，该文件可能被原作者或入侵代码库的攻击者修改。突然间，共享的配置文件可以告诉应用程序以非常不同的方式执行，可能让未经授权的用户访问，甚至直接窃取数据并将其渗出。
使用共享资源的更好方法
如果你的组织允许使用外部来源的代码，那么就必须制定程序，以确保安全地进行。当评估可能使用的外部代码时，要确保只使用安全链接从官方来源获得组件。即使如此，你也不应该链接到外部来源来拉动该代码，因为这使该过程脱离了你的控制。相反，经过批准的代码应该被带入一个安全的库中，并且只能从这个受保护的地方使用。因此，在Docker环境中，代码将看起来像这样。
复制 src/config/default-ssl.conf /etc/apache2/sites-available/。
这将取代对远程第三方配置文件的依赖，而是依靠这些文件的本地副本。这将防止任何意外或恶意的改变。
除了使用安全代码库外，还应该建立一个补丁管理程序，在整个软件生命周期内持续监控组件。所有客户端和服务器端的组件也应使用NVD或CVE等工具进行安全警报检查。最后，删除任何未使用或不必要的依赖和功能，这些功能可能与外部代码一起出现。
通过遵循这些步骤，开发人员可以更安全地利用外部资源，而不会意外地将漏洞诱发到他们的应用程序和代码中。
请查看 Secure Code Warrior博客页面，了解有关这一漏洞的更多见解，以及如何保护您的组织和客户免受其他安全缺陷的破坏。你也可以在Secure Code Warrior 培训平台上尝试演示IaC挑战，以保持你的所有网络安全技能得到磨练和更新。
