程序员以代码的形式征服安全基础架构系列——使用来自不可信来源的组件
我们的 “基础设施即代码” 系列已接近尾声，但能帮助像您这样的开发人员踏上 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., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior kann Ihrem Unternehmen dabei helfen, Code während des gesamten Softwareentwicklungszyklus zu schützen und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, Chief Information Security Officer oder in einem anderen sicherheitsrelevanten Bereich tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu minimieren.
Demo buchen
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.
我们的 “基础设施即代码” 系列已接近尾声，但能帮助像您这样的开发人员踏上 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 挑战，让您的所有网络安全技能不断磨练并保持最新状态。
Klicken Sie auf den folgenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior kann Ihrem Unternehmen dabei helfen, Code während des gesamten Softwareentwicklungszyklus zu schützen und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, Chief Information Security Officer oder in einem anderen sicherheitsrelevanten Bereich tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu minimieren.
Bericht anzeigenDemo buchen
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.
我们的 “基础设施即代码” 系列已接近尾声，但能帮助像您这样的开发人员踏上 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 挑战，让您的所有网络安全技能不断磨练并保持最新状态。
Verzeichnis
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior kann Ihrem Unternehmen dabei helfen, Code während des gesamten Softwareentwicklungszyklus zu schützen und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, Chief Information Security Officer oder in einem anderen sicherheitsrelevanten Bereich tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu minimieren.
Demo buchen下载Ressourcen, die Ihnen den Einstieg erleichtern
Themen und Inhalte der Sicherheitsschulung
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um sich an die sich wandelnde Softwareentwicklungslandschaft anzupassen und gleichzeitig Ihre Rolle zu berücksichtigen. Die Themen reichen von KI bis hin zu XQuery-Injection und sind für verschiedene Positionen geeignet, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA-Mitarbeitern. Verschaffen Sie sich einen ersten Überblick nach Themen und Rollen und erfahren Sie, was unser Inhaltsverzeichnis zu bieten hat.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
%20(1).avif)
.avif)
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Ressourcen, die Ihnen den Einstieg erleichtern
Cybermon ist zurück: Die KI-Mission zum Besiegen des Bosses ist jetzt auf Abruf verfügbar.
Cybermon 2025: Der Kampf gegen den Boss hat nun in SCW ganzjährig begonnen. Der Kampf um die Sicherheit von KI/LLM auf Stammesebene, die Entwicklung von Sicherheits-KI wird durch groß angelegte Modelle verstärkt.
Auslegung des Gesetzes zur Netzresilienz: Was bedeutet es, durch die Entwicklung von Design-Software Sicherheit zu erreichen?
Verstehen Sie die Anforderungen des EU-Gesetzes zur Netzresilienz (CRA), für wen es gilt und wie sich Ingenieurteams durch Designpraktiken, Schwachstellenprävention und Kompetenzaufbau für Entwickler darauf vorbereiten können.
Treibende Faktoren 1: Klare und messbare Erfolgskriterien
Enabler 1 ist der Auftakt zu unserer 10-teiligen Reihe über Erfolgsfaktoren. Er zeigt, wie sichere Codierung mit Geschäftsergebnissen wie Risikominderung und schnellerer Reifung langfristiger Pläne in Verbindung gebracht werden kann.
