Coders Conquer Security Infrastructure as Code Series - Using Components From Untrusted Sources
Coders Conquer Security Infrastructure as Code Series - Using Components From Untrusted Sources
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/6022b6a5a0ae7d9df6508088_601104ec63827c55cba0ab23_SCW-Coders-Conquer-badge-2020-FA.png)
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/6022b6a5a0ae7d9df6508088_601104ec63827c55cba0ab23_SCW-Coders-Conquer-badge-2020-FA.png)
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.
Resources to get you started
Trust Agent by Secure Code Warrior
Discover SCW Trust Agent, an innovative solution designed to enhance security by aligning developer secure code knowledge and skills with the work they commit. It provides comprehensive visibility and controls across an organization's entire code repository, analyzing each commit against developers' secure code profiles. With SCW Trust Agent, organizations can strengthen their security posture, optimize development lifecycles, and scale developer-driven security.
Resources to get you started
Women in Security are Winning: How the AWSN is Setting Up a New Generation of Security Superwomen
Secure-by-Design is the latest initiative on everyone’s lips, and the Australian government, collaborating with CISA at the highest levels of global governance, is guiding a higher standard of software quality and security from vendors.
Women in Security are Winning: How the AWSN is Setting Up a New Generation of Security Superwomen
Secure-by-Design is the latest initiative on everyone’s lips, and the Australian government, collaborating with CISA at the highest levels of global governance, is guiding a higher standard of software quality and security from vendors.
SCW Trust Agent - Visibility and Control to Scale Developer Driven Security
SCW Trust Agent, introduced by Secure Code Warrior, offers security leaders the visibility and control needed to scale developer-driven security within organizations. By connecting to code repositories, it assesses code commit metadata, inspects developers, programming languages used, and shipment timestamps to determine developers' security knowledge.
Coders Conquer Security Infrastructure as Code Series - Using Components From Untrusted Sources
![](https://cdn.prod.website-files.com/5fec9210c1841a6c20c6ce81/6022b6a5a0ae7d9df6508088_601104ec63827c55cba0ab23_SCW-Coders-Conquer-badge-2020-FA.png)
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.
Resources to get you started
Women in Security are Winning: How the AWSN is Setting Up a New Generation of Security Superwomen
Secure-by-Design is the latest initiative on everyone’s lips, and the Australian government, collaborating with CISA at the highest levels of global governance, is guiding a higher standard of software quality and security from vendors.
SCW Trust Agent - Visibility and Control to Scale Developer Driven Security
SCW Trust Agent, introduced by Secure Code Warrior, offers security leaders the visibility and control needed to scale developer-driven security within organizations. By connecting to code repositories, it assesses code commit metadata, inspects developers, programming languages used, and shipment timestamps to determine developers' security knowledge.
Trust Agent by Secure Code Warrior
Discover SCW Trust Agent, an innovative solution designed to enhance security by aligning developer secure code knowledge and skills with the work they commit. It provides comprehensive visibility and controls across an organization's entire code repository, analyzing each commit against developers' secure code profiles. With SCW Trust Agent, organizations can strengthen their security posture, optimize development lifecycles, and scale developer-driven security.