程序员以代码的形式征服安全基础架构系列——使用来自不可信来源的组件
我们的 “基础设施即代码” 系列已接近尾声，但能帮助像您这样的开发人员踏上 IaC 安全之旅真是太好了。
你玩过挑战赛吗？到目前为止你的分数是多少？在我们开始之前，让我们看看你已经对使用来自不可信来源的组件的陷阱了解了多少：
还有工作要做吗？继续阅读：
我们今天要重点关注的诱发漏洞的行为是使用来自不可信来源的代码，这种看似良性的做法会造成重大问题。使用开源代码和资源有很多好处。总的来说，它允许专家将他们的想法、工作甚至完成的代码贡献到像GitHub这样的存储库，供努力使程序或应用程序正常运行的其他人使用。使用完整的代码来管理程序函数，使开发人员不必在每次需要创建新应用程序时都重新设计轮子。
但是，使用来自不可靠、未经审查甚至潜在危险来源的代码片段会带来很大的风险。实际上，使用来自不可信来源的代码是主要和次要安全漏洞渗透到原本安全的应用程序中的最常见方式之一。有时，这些漏洞是由其创建者意外引起的。还存在潜在攻击者编写恶意代码的情况。然后共享该代码，希望能圈住受害者，他们会把它放到他们的应用程序中。
为什么使用来自不可信来源的代码很危险？
假设开发人员很着急，需要配置他们正在开发的应用程序。这可能是一个棘手的过程。因此，他们没有花费大量时间尝试找出所有可能的配置，而是进行谷歌搜索，找到已经完成看似完美的配置文件的人。尽管开发人员对编写代码的人一无所知，但将其添加到新应用程序中相对容易。可以在 Docker 环境中使用两行代码来完成：
运行 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 培训平台中存在的 IaC 挑战，让您的所有网络安全技能不断磨练并保持最新状态。
Matias Madou, Ph.D.是一位安全专家、研究员和CTO，也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位，主要研究静态分析解决方案。后来他加入了美国的Fortify公司，在那里他意识到，仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情，帮助开发人员，减轻安全的负担，并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时，他喜欢站在舞台上，在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
Secure Code Warrior可帮助您的组织在整个软件开发生命周期中保护代码，并营造一种将网络安全置于首位的文化。无论您是应用安全经理、开发人员、首席信息安全官还是任何与安全相关的人员，我们都能帮助您的组织降低与不安全代码相关的风险。
预约演示
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 环境中使用两行代码来完成：
运行 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 培训平台中存在的 IaC 挑战，让您的所有网络安全技能不断磨练并保持最新状态。
我们的 “基础设施即代码” 系列已接近尾声，但能帮助像您这样的开发人员踏上 IaC 安全之旅真是太好了。
你玩过挑战赛吗？到目前为止你的分数是多少？在我们开始之前，让我们看看你已经对使用来自不可信来源的组件的陷阱了解了多少：
还有工作要做吗？继续阅读：
我们今天要重点关注的诱发漏洞的行为是使用来自不可信来源的代码，这种看似良性的做法会造成重大问题。使用开源代码和资源有很多好处。总的来说，它允许专家将他们的想法、工作甚至完成的代码贡献到像GitHub这样的存储库，供努力使程序或应用程序正常运行的其他人使用。使用完整的代码来管理程序函数，使开发人员不必在每次需要创建新应用程序时都重新设计轮子。
但是，使用来自不可靠、未经审查甚至潜在危险来源的代码片段会带来很大的风险。实际上，使用来自不可信来源的代码是主要和次要安全漏洞渗透到原本安全的应用程序中的最常见方式之一。有时，这些漏洞是由其创建者意外引起的。还存在潜在攻击者编写恶意代码的情况。然后共享该代码，希望能圈住受害者，他们会把它放到他们的应用程序中。
为什么使用来自不可信来源的代码很危险？
假设开发人员很着急，需要配置他们正在开发的应用程序。这可能是一个棘手的过程。因此，他们没有花费大量时间尝试找出所有可能的配置，而是进行谷歌搜索，找到已经完成看似完美的配置文件的人。尽管开发人员对编写代码的人一无所知，但将其添加到新应用程序中相对容易。可以在 Docker 环境中使用两行代码来完成：
运行 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 培训平台中存在的 IaC 挑战，让您的所有网络安全技能不断磨练并保持最新状态。
点击下面的链接并下载此资源的PDF。
Secure Code Warrior可帮助您的组织在整个软件开发生命周期中保护代码，并营造一种将网络安全置于首位的文化。无论您是应用安全经理、开发人员、首席信息安全官还是任何与安全相关的人员，我们都能帮助您的组织降低与不安全代码相关的风险。
查看报告预约演示
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 环境中使用两行代码来完成：
运行 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 培训平台中存在的 IaC 挑战，让您的所有网络安全技能不断磨练并保持最新状态。
目录
Matias Madou, Ph.D.是一位安全专家、研究员和CTO，也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位，主要研究静态分析解决方案。后来他加入了美国的Fortify公司，在那里他意识到，仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情，帮助开发人员，减轻安全的负担，并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时，他喜欢站在舞台上，在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
Secure Code Warrior可帮助您的组织在整个软件开发生命周期中保护代码，并营造一种将网络安全置于首位的文化。无论您是应用安全经理、开发人员、首席信息安全官还是任何与安全相关的人员，我们都能帮助您的组织降低与不安全代码相关的风险。
预约演示下载帮助您入门的资源
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.
