コーダーがセキュリティインフラストラクチャをコードシリーズで制覇-信頼できないソースからのコンポーネントを使う
We're nearing the end of our Infrastructure as Code series, but it has been great to help developers like you on their IaC security journey.
Have you been playing the challenges? What's your score so far? Before we get started, let's see how much you already know about the pitfalls of using components from untrusted sources:
Still have some work to do? Read on:
The vulnerability-inducing behavior that we are going to focus on today is using code from untrusted sources, a seemingly benign practice that is causing big problems. There are many advantages to using open source code and resources. In general, it allows experts to contribute their ideas, work and even completed code to repositories like GitHub to be used by others struggling to make a program or an app behave properly. Using completed code to govern program functions saves developers from having to reinvent the wheel every time they need to create a new application.
However, using code snippets from unreliable, unvetted or even potentially dangerous sources carries a lot of risk. In fact, using code from untrusted sources is one of the most common ways that both major and minor security vulnerabilities creep into otherwise secure applications. Sometimes, those vulnerabilities are accidentally induced by their creators. There have also been instances where malicious code was written by potential attackers. The code is then shared with the hope of ensnaring victims who will drop it into their applications.
Why is using code from untrusted sources dangerous?
Let's say a developer is in a hurry and needs to configure an application they are developing. That can be a tricky process. So instead of spending a lot of time trying to work out every possible configuration, they do a Google search and find someone who has already completed a seemingly perfect configuration file. Even though the developer knows nothing about the person who wrote the code, adding it to a new application is relatively easy. It can be done in the Docker environment using two lines:
RUN cd /etc/apache2/sites-available/ && \
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Now the Docker image will dynamically pull in the third party config file. And even if the file is tested and found to be okay at the time, the fact that the pointer is now embedded in the new application's code means that there is a permanent dependency in place. Days, weeks or months later, the file could be altered by the original author or an attacker who compromised the code repository. Suddenly, the shared config file can tell the application to perform very differently than intended, possibly giving access to unauthorized users or even directly stealing data and exfiltrating it.
A better way to use shared resources
If your organization allows the use of code from outside sources, then processes must be put in place to ensure that it is done safely. When evaluating outside code for potential use, be sure to acquire components from official sources only using secure links. And even then, you should never link to an outside source to pull in that code, as that removes the process from your control. Instead, approved code should be brought into a secure library and only used from that protected location. So in a Docker environment, the code would look like this:
COPY src/config/default-ssl.conf /etc/apache2/sites-available/
Instead of relying on remote third party configuration files, this would instead rely on a local copy of those files. This will prevent any unexpected or malicious changes from being made.
In addition to using a secure code library, a patch management process should be put in place to continually monitor components throughout the software lifecycle. All client and server-side components should also be checked for security alerts using tools like NVD or CVE. Finally, remove any unused or unnecessary dependencies and features that might come along for the ride with the outside code.
By following these steps, developers can more safely make use of external resources without accidentally inducing vulnerabilities into their applications and code.
Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the IaC challenges in the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.
マティアス・マドゥ博士は、セキュリティ専門家、研究者、CTO、セキュア・コード・ウォリアーの共同創設者です。Matias はゲント大学で静的分析ソリューションを中心にアプリケーションセキュリティの博士号を取得しました。その後、米国のFortifyに入社し、開発者が安全なコードを書くのを手伝わずに、コードの問題を検出するだけでは不十分であることに気づきました。これがきっかけで、開発者を支援し、セキュリティの負担を軽減し、顧客の期待を超える製品を開発するようになりました。Team Awesome の一員としてデスクにいないときは、RSA カンファレンス、BlackHat、DefCon などのカンファレンスでプレゼンテーションを行うステージでのプレゼンテーションを楽しんでいます。
Secure Code Warriorは、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする文化を築くお手伝いをします。アプリケーションセキュリティマネージャ、開発者、CISO、またはセキュリティ関係者のいずれであっても、安全でないコードに関連するリスクを軽減するお手伝いをします。
デモを予約
マティアス・マドゥ博士は、セキュリティ専門家、研究者、CTO、セキュア・コード・ウォリアーの共同創設者です。Matias はゲント大学で静的分析ソリューションを中心にアプリケーションセキュリティの博士号を取得しました。その後、米国のFortifyに入社し、開発者が安全なコードを書くのを手伝わずに、コードの問題を検出するだけでは不十分であることに気づきました。これがきっかけで、開発者を支援し、セキュリティの負担を軽減し、顧客の期待を超える製品を開発するようになりました。Team Awesome の一員としてデスクにいないときは、RSA カンファレンス、BlackHat、DefCon などのカンファレンスでプレゼンテーションを行うステージでのプレゼンテーションを楽しんでいます。
Matiasは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者および開発者です。フォーティファイ・ソフトウェアや自身の会社であるセンセイ・セキュリティなどの企業向けにソリューションを開発してきました。マティアスはキャリアを通じて、複数のアプリケーションセキュリティ研究プロジェクトを主導し、それが商用製品につながり、10件以上の特許を取得しています。デスクから離れているときには、マティアスは上級アプリケーション・セキュリティ・トレーニング・コースの講師を務め、RSA Conference、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどのグローバルカンファレンスで定期的に講演を行っています。
マティアスはゲント大学でコンピューター工学の博士号を取得し、そこでアプリケーションの内部動作を隠すためのプログラムの難読化によるアプリケーションセキュリティを学びました。
We're nearing the end of our Infrastructure as Code series, but it has been great to help developers like you on their IaC security journey.
Have you been playing the challenges? What's your score so far? Before we get started, let's see how much you already know about the pitfalls of using components from untrusted sources:
Still have some work to do? Read on:
The vulnerability-inducing behavior that we are going to focus on today is using code from untrusted sources, a seemingly benign practice that is causing big problems. There are many advantages to using open source code and resources. In general, it allows experts to contribute their ideas, work and even completed code to repositories like GitHub to be used by others struggling to make a program or an app behave properly. Using completed code to govern program functions saves developers from having to reinvent the wheel every time they need to create a new application.
However, using code snippets from unreliable, unvetted or even potentially dangerous sources carries a lot of risk. In fact, using code from untrusted sources is one of the most common ways that both major and minor security vulnerabilities creep into otherwise secure applications. Sometimes, those vulnerabilities are accidentally induced by their creators. There have also been instances where malicious code was written by potential attackers. The code is then shared with the hope of ensnaring victims who will drop it into their applications.
Why is using code from untrusted sources dangerous?
Let's say a developer is in a hurry and needs to configure an application they are developing. That can be a tricky process. So instead of spending a lot of time trying to work out every possible configuration, they do a Google search and find someone who has already completed a seemingly perfect configuration file. Even though the developer knows nothing about the person who wrote the code, adding it to a new application is relatively easy. It can be done in the Docker environment using two lines:
RUN cd /etc/apache2/sites-available/ && \
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Now the Docker image will dynamically pull in the third party config file. And even if the file is tested and found to be okay at the time, the fact that the pointer is now embedded in the new application's code means that there is a permanent dependency in place. Days, weeks or months later, the file could be altered by the original author or an attacker who compromised the code repository. Suddenly, the shared config file can tell the application to perform very differently than intended, possibly giving access to unauthorized users or even directly stealing data and exfiltrating it.
A better way to use shared resources
If your organization allows the use of code from outside sources, then processes must be put in place to ensure that it is done safely. When evaluating outside code for potential use, be sure to acquire components from official sources only using secure links. And even then, you should never link to an outside source to pull in that code, as that removes the process from your control. Instead, approved code should be brought into a secure library and only used from that protected location. So in a Docker environment, the code would look like this:
COPY src/config/default-ssl.conf /etc/apache2/sites-available/
Instead of relying on remote third party configuration files, this would instead rely on a local copy of those files. This will prevent any unexpected or malicious changes from being made.
In addition to using a secure code library, a patch management process should be put in place to continually monitor components throughout the software lifecycle. All client and server-side components should also be checked for security alerts using tools like NVD or CVE. Finally, remove any unused or unnecessary dependencies and features that might come along for the ride with the outside code.
By following these steps, developers can more safely make use of external resources without accidentally inducing vulnerabilities into their applications and code.
Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the IaC challenges in the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.
We're nearing the end of our Infrastructure as Code series, but it has been great to help developers like you on their IaC security journey.
Have you been playing the challenges? What's your score so far? Before we get started, let's see how much you already know about the pitfalls of using components from untrusted sources:
Still have some work to do? Read on:
The vulnerability-inducing behavior that we are going to focus on today is using code from untrusted sources, a seemingly benign practice that is causing big problems. There are many advantages to using open source code and resources. In general, it allows experts to contribute their ideas, work and even completed code to repositories like GitHub to be used by others struggling to make a program or an app behave properly. Using completed code to govern program functions saves developers from having to reinvent the wheel every time they need to create a new application.
However, using code snippets from unreliable, unvetted or even potentially dangerous sources carries a lot of risk. In fact, using code from untrusted sources is one of the most common ways that both major and minor security vulnerabilities creep into otherwise secure applications. Sometimes, those vulnerabilities are accidentally induced by their creators. There have also been instances where malicious code was written by potential attackers. The code is then shared with the hope of ensnaring victims who will drop it into their applications.
Why is using code from untrusted sources dangerous?
Let's say a developer is in a hurry and needs to configure an application they are developing. That can be a tricky process. So instead of spending a lot of time trying to work out every possible configuration, they do a Google search and find someone who has already completed a seemingly perfect configuration file. Even though the developer knows nothing about the person who wrote the code, adding it to a new application is relatively easy. It can be done in the Docker environment using two lines:
RUN cd /etc/apache2/sites-available/ && \
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Now the Docker image will dynamically pull in the third party config file. And even if the file is tested and found to be okay at the time, the fact that the pointer is now embedded in the new application's code means that there is a permanent dependency in place. Days, weeks or months later, the file could be altered by the original author or an attacker who compromised the code repository. Suddenly, the shared config file can tell the application to perform very differently than intended, possibly giving access to unauthorized users or even directly stealing data and exfiltrating it.
A better way to use shared resources
If your organization allows the use of code from outside sources, then processes must be put in place to ensure that it is done safely. When evaluating outside code for potential use, be sure to acquire components from official sources only using secure links. And even then, you should never link to an outside source to pull in that code, as that removes the process from your control. Instead, approved code should be brought into a secure library and only used from that protected location. So in a Docker environment, the code would look like this:
COPY src/config/default-ssl.conf /etc/apache2/sites-available/
Instead of relying on remote third party configuration files, this would instead rely on a local copy of those files. This will prevent any unexpected or malicious changes from being made.
In addition to using a secure code library, a patch management process should be put in place to continually monitor components throughout the software lifecycle. All client and server-side components should also be checked for security alerts using tools like NVD or CVE. Finally, remove any unused or unnecessary dependencies and features that might come along for the ride with the outside code.
By following these steps, developers can more safely make use of external resources without accidentally inducing vulnerabilities into their applications and code.
Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the IaC challenges in the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.
以下のリンクをクリックして、このリソースのPDFをダウンロードしてください。
Secure Code Warriorは、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする文化を築くお手伝いをします。アプリケーションセキュリティマネージャ、開発者、CISO、またはセキュリティ関係者のいずれであっても、安全でないコードに関連するリスクを軽減するお手伝いをします。
レポートを表示デモを予約
マティアス・マドゥ博士は、セキュリティ専門家、研究者、CTO、セキュア・コード・ウォリアーの共同創設者です。Matias はゲント大学で静的分析ソリューションを中心にアプリケーションセキュリティの博士号を取得しました。その後、米国のFortifyに入社し、開発者が安全なコードを書くのを手伝わずに、コードの問題を検出するだけでは不十分であることに気づきました。これがきっかけで、開発者を支援し、セキュリティの負担を軽減し、顧客の期待を超える製品を開発するようになりました。Team Awesome の一員としてデスクにいないときは、RSA カンファレンス、BlackHat、DefCon などのカンファレンスでプレゼンテーションを行うステージでのプレゼンテーションを楽しんでいます。
Matiasは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者および開発者です。フォーティファイ・ソフトウェアや自身の会社であるセンセイ・セキュリティなどの企業向けにソリューションを開発してきました。マティアスはキャリアを通じて、複数のアプリケーションセキュリティ研究プロジェクトを主導し、それが商用製品につながり、10件以上の特許を取得しています。デスクから離れているときには、マティアスは上級アプリケーション・セキュリティ・トレーニング・コースの講師を務め、RSA Conference、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどのグローバルカンファレンスで定期的に講演を行っています。
マティアスはゲント大学でコンピューター工学の博士号を取得し、そこでアプリケーションの内部動作を隠すためのプログラムの難読化によるアプリケーションセキュリティを学びました。
We're nearing the end of our Infrastructure as Code series, but it has been great to help developers like you on their IaC security journey.
Have you been playing the challenges? What's your score so far? Before we get started, let's see how much you already know about the pitfalls of using components from untrusted sources:
Still have some work to do? Read on:
The vulnerability-inducing behavior that we are going to focus on today is using code from untrusted sources, a seemingly benign practice that is causing big problems. There are many advantages to using open source code and resources. In general, it allows experts to contribute their ideas, work and even completed code to repositories like GitHub to be used by others struggling to make a program or an app behave properly. Using completed code to govern program functions saves developers from having to reinvent the wheel every time they need to create a new application.
However, using code snippets from unreliable, unvetted or even potentially dangerous sources carries a lot of risk. In fact, using code from untrusted sources is one of the most common ways that both major and minor security vulnerabilities creep into otherwise secure applications. Sometimes, those vulnerabilities are accidentally induced by their creators. There have also been instances where malicious code was written by potential attackers. The code is then shared with the hope of ensnaring victims who will drop it into their applications.
Why is using code from untrusted sources dangerous?
Let's say a developer is in a hurry and needs to configure an application they are developing. That can be a tricky process. So instead of spending a lot of time trying to work out every possible configuration, they do a Google search and find someone who has already completed a seemingly perfect configuration file. Even though the developer knows nothing about the person who wrote the code, adding it to a new application is relatively easy. It can be done in the Docker environment using two lines:
RUN cd /etc/apache2/sites-available/ && \
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Now the Docker image will dynamically pull in the third party config file. And even if the file is tested and found to be okay at the time, the fact that the pointer is now embedded in the new application's code means that there is a permanent dependency in place. Days, weeks or months later, the file could be altered by the original author or an attacker who compromised the code repository. Suddenly, the shared config file can tell the application to perform very differently than intended, possibly giving access to unauthorized users or even directly stealing data and exfiltrating it.
A better way to use shared resources
If your organization allows the use of code from outside sources, then processes must be put in place to ensure that it is done safely. When evaluating outside code for potential use, be sure to acquire components from official sources only using secure links. And even then, you should never link to an outside source to pull in that code, as that removes the process from your control. Instead, approved code should be brought into a secure library and only used from that protected location. So in a Docker environment, the code would look like this:
COPY src/config/default-ssl.conf /etc/apache2/sites-available/
Instead of relying on remote third party configuration files, this would instead rely on a local copy of those files. This will prevent any unexpected or malicious changes from being made.
In addition to using a secure code library, a patch management process should be put in place to continually monitor components throughout the software lifecycle. All client and server-side components should also be checked for security alerts using tools like NVD or CVE. Finally, remove any unused or unnecessary dependencies and features that might come along for the ride with the outside code.
By following these steps, developers can more safely make use of external resources without accidentally inducing vulnerabilities into their applications and code.
Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the IaC challenges in the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.
目次
マティアス・マドゥ博士は、セキュリティ専門家、研究者、CTO、セキュア・コード・ウォリアーの共同創設者です。Matias はゲント大学で静的分析ソリューションを中心にアプリケーションセキュリティの博士号を取得しました。その後、米国のFortifyに入社し、開発者が安全なコードを書くのを手伝わずに、コードの問題を検出するだけでは不十分であることに気づきました。これがきっかけで、開発者を支援し、セキュリティの負担を軽減し、顧客の期待を超える製品を開発するようになりました。Team Awesome の一員としてデスクにいないときは、RSA カンファレンス、BlackHat、DefCon などのカンファレンスでプレゼンテーションを行うステージでのプレゼンテーションを楽しんでいます。
Secure Code Warriorは、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする文化を築くお手伝いをします。アプリケーションセキュリティマネージャ、開発者、CISO、またはセキュリティ関係者のいずれであっても、安全でないコードに関連するリスクを軽減するお手伝いをします。
デモを予約[ダウンロード]始めるためのリソース
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
