编码员征服安全基础设施即代码系列--使用来自不信任来源的组件
我们的 "基础设施即代码 "系列已接近尾声，但能帮助像你这样的开发者在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挑战，以保持你的所有网络安全技能得到磨练和更新。
Matias Madou, Ph.D.是一位安全专家、研究员和CTO，也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位，主要研究静态分析解决方案。后来他加入了美国的Fortify公司，在那里他意识到，仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情，帮助开发人员，减轻安全的负担，并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时，他喜欢站在舞台上，在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
Secure Code Warrior 我们在这里为您的组织提供服务，帮助您在整个软件开发生命周期中确保代码安全，并创造一种将网络安全放在首位的文化。无论您是应用安全经理、开发人员、CISO或任何涉及安全的人，我们都可以帮助您的组织减少与不安全代码有关的风险。
预定一个演示
Matias Madou, Ph.D.是一位安全专家、研究员和CTO，也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位，主要研究静态分析解决方案。后来他加入了美国的Fortify公司，在那里他意识到，仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情，帮助开发人员，减轻安全的负担，并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时，他喜欢站在舞台上，在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
马蒂亚斯是一名研究员和开发人员，拥有超过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挑战，以保持你的所有网络安全技能得到磨练和更新。
我们的 "基础设施即代码 "系列已接近尾声，但能帮助像你这样的开发者在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挑战，以保持你的所有网络安全技能得到磨练和更新。
点击下面的链接，下载本资料的 PDF 文件。
Secure Code Warrior 我们在这里为您的组织提供服务，帮助您在整个软件开发生命周期中确保代码安全，并创造一种将网络安全放在首位的文化。无论您是应用安全经理、开发人员、CISO或任何涉及安全的人，我们都可以帮助您的组织减少与不安全代码有关的风险。
查看报告预定一个演示
Matias Madou, Ph.D.是一位安全专家、研究员和CTO，也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位，主要研究静态分析解决方案。后来他加入了美国的Fortify公司，在那里他意识到，仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情，帮助开发人员，减轻安全的负担，并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时，他喜欢站在舞台上，在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
马蒂亚斯是一名研究员和开发人员，拥有超过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挑战，以保持你的所有网络安全技能得到磨练和更新。
目录
Matias Madou, Ph.D.是一位安全专家、研究员和CTO，也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位，主要研究静态分析解决方案。后来他加入了美国的Fortify公司，在那里他意识到，仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情，帮助开发人员，减轻安全的负担，并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时，他喜欢站在舞台上，在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
Secure Code Warrior 我们在这里为您的组织提供服务，帮助您在整个软件开发生命周期中确保代码安全，并创造一种将网络安全放在首位的文化。无论您是应用安全经理、开发人员、CISO或任何涉及安全的人，我们都可以帮助您的组织减少与不安全代码有关的风险。
预定一个演示下载资源
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
OpenText 应用程序安全性的强大功能 + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
安全代码培训主题和内容
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peek of what our content catalog has to offer by topic and role.
资源
Observe and Secure the ADLC: A Four-Point Framework for CISOs and Development Teams Using AI
While development teams look to make the most of GenAI’s undeniable benefits, we’d like to propose a four-point foundational framework that will allow security leaders to deploy AI coding tools and agents with a higher, more relevant standard of security best practices. It details exactly what enterprises can do to ensure safe, secure code development right now, and as agentic AI becomes an even bigger factor in the future.
