Coders Conquer Security Infrastructure as Code Series - Using Components From Untrusted Sources
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.
The vulnerability-inducing behavior that we are going to focus on here is using code from untrusted sources, a seemingly benign practice that is causing big problems.
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demo
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.
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.
Click on the link below and download the PDF of this resource.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demo
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.
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.
Table of contents
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
Secure by Design: Defining Best Practices, Enabling Developers and Benchmarking Preventative Security Outcomes
In this research paper, Secure Code Warrior co-founders, Pieter Danhieux and Dr. Matias Madou, Ph.D., along with expert contributors, Chris Inglis, Former US National Cyber Director (now Strategic Advisor to Paladin Capital Group), and Devin Lynch, Senior Director, Paladin Global Institute, will reveal key findings from over twenty in-depth interviews with enterprise security leaders including CISOs, a VP of Application Security, and software security professionals.
Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise
Finding meaningful data on the success of Secure-by-Design initiatives is notoriously difficult. CISOs are often challenged when attempting to prove the return on investment (ROI) and business value of security program activities at both the people and company levels. Not to mention, it’s particularly difficult for enterprises to gain insights into how their organizations are benchmarked against current industry standards. The President’s National Cybersecurity Strategy challenged stakeholders to “embrace security and resilience by design.” The key to making Secure-by-Design initiatives work is not only giving developers the skills to ensure secure code, but also assuring the regulators that those skills are in place. In this presentation, we share a myriad of qualitative and quantitative data, derived from multiple primary sources, including internal data points collected from over 250,000 developers, data-driven customer insights, and public studies. Leveraging this aggregation of data points, we aim to communicate a vision of the current state of Secure-by-Design initiatives across multiple verticals. The report details why this space is currently underutilized, the significant impact a successful upskilling program can have on cybersecurity risk mitigation, and the potential to eliminate categories of vulnerabilities from a codebase.
Secure code training topics & content
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 peak of what our content catalog has to offer by topic and role.
Resources to get you started
Revealed: How the Cyber Industry Defines Secure by Design
In our latest white paper, our Co-Founders, Pieter Danhieux and Dr. Matias Madou, Ph.D., sat down with over twenty enterprise security leaders, including CISOs, AppSec leaders and security professionals, to figure out the key pieces of this puzzle and uncover the reality behind the Secure by Design movement. It’s a shared ambition across the security teams, but no shared playbook.
Is Vibe Coding Going to Turn Your Codebase Into a Frat Party?
Vibe coding is like a college frat party, and AI is the centerpiece of all the festivities, the keg. It’s a lot of fun to let loose, get creative, and see where your imagination can take you, but after a few keg stands, drinking (or, using AI) in moderation is undoubtedly the safer long-term solution.
Developer-driven coding.
Securely.
Contact us today and make software security an intrinsic part of your development process.
