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.