Manage Open-Source Software Vulnerabilities Within The New PCI SSF

Let’s try this: equate your payment software to a batch of brownies.

To make brownies, you follow a recipe—a set of instructions— just as you would during software development. To avoid a dessert that tastes like bricks, you’ve got to have the correct ingredients and follow those instructions.

Similarly, you use different ingredients to create your software. In industry jargon, they’re called dependencies. But just as you cannot use year-old eggs and expect delicious brownies, the dependencies you include in your software need to be maintained if you want software to remain functional and secure.

This means accounting for vulnerabilities within your “ingredient” pieces because core, unpatched dependencies can render your other security controls ineffective. A bad batch of brownies is just a party foul, but the ramifications of “ineffective security controls” on your business could be much more severe.

Alright, enough with the baking analogy.

These past few months have highlighted just how big of a problem open-source vulnerabilities can be. The following are security concerns or vulnerabilities within software dependencies have serious knock-on effects in major ways:

• Purposefully corrupted code: Vulnerabilities introduced into two JavaScript dependencies by a contributor who did not feel recognized caused errors for the millions of users deploying those packages.
• End-of-Life/End-of-Support code: Known vulnerabilities were exploited for hundreds of ecommerce merchants using end-of-life software.
• Code not being actively maintained: Older code used to accept credit card payments continues to be downloaded thousands of times each week.

Unfortunately, these are not new or unique problems. And while the Open Source Security and Risk Analysis Report from Synopsys captures the extent of these concerns quite well, we want to drill down a bit. Schellman was a part of the PCI SSC’s taskforce to develop the Software Security Framework (SSF), and we want to help everyone else get up to speed on the details.

In this article, we will discuss—in particular—the SSF’s approach to these kinds of open-source vulnerabilities, and how you can avoid becoming just like those aforementioned victims.

How Do Security Standards Account for Dependencies?

Given how new the SSF still is, you may be more familiar with NIST 800-218 (Secure Software Development Framework v1.1), which addresses this same dependency concept when identifying the security requirements for maintaining software over time. NIST provides more clarity on their approach to this topic within NIST IR 8397.

Regarding open-source vulnerabilities, the current security standards within the SSF are clear:

Your potential scope will include the “coverage of all payment software components and dependencies, including supported execution platforms or environments, third-party and open-source libraries, services, and other required functions.”

At this point, we should note that not all dependencies impact the functionality or security of an application. You may have an open-source component within your software which contains a vulnerability that could cause software to crash but wouldn’t compromise the security of sensitive data.

While dependencies of these types do pose less potential security impact, that doesn’t make them less of a concern for you overall and you’re still responsible for mitigating them.

But as we talk about security and security frameworks, the SSF is more focused on those vulnerabilities that fall within your critical assets list.

• Critical assets are any of the hardware, components, resources, dependencies, etc. which are necessary for the software to function and protect the security of sensitive data.
• Not only will your independent third party use that list to do their own tests during your assessment, but that list establishes the baseline from where you can perform an accurate threat analysis to your software and establish repeatable processes to respond when vulnerabilities are identified.

Why Can’t Vulnerability Scans Can’t Find These Issues in Your Dependencies?

Given the name, you’d assume these scans could help you identify all your open-source problems, but that is not the case.

Application testing tools can usually identify vulnerabilities where there is a published CVE or vendor-provided details, but not all dependencies are catalogued in this way—this is particularly true for open-source software.

Understand that how payment software functions, how sensitive data is handled, and what can impact the security of sensitive data is an ongoing process that cannot be met with a single scanning tool. Even if the application scans do identify legitimate or suspected issues, the following steps are still a necessary part of the secure software development.

How to Account for Open-Source Vulnerabilities Ahead of SSF Compliance

So what are these steps can you follow to identify dependencies within your payment software? Ahead of your SSF assessment, here’s how to find and address these vulnerabilities:

• Consider how your payment software is built. Review language frameworks, open-source libraries, dependencies, third-party software elements, and how these functions can impact the security of the software. It may seem tedious now, but following through will likely become an eye-opening first step to your understanding the surface area that will be attacked you’re your software is deployed in merchant environments.
  
  
• Assign levels of criticality to these items. The elements that can impact the functionality or security objectives of payment software are a priority. For a more concrete starting point, check the critical asset list found in SSF Control Objective 1.3.
  
  
• Identify the attack scenarios. Threat modeling will seed your steps taken to either address or mitigate those risks through routine patching, changes to system configurations, security controls, etc.

Following these successive steps above is a great start. Not only will that procedure address your open-source risk areas, but it will also yield a foundation that addresses many control objectives in the SSF Standards. It won’t be a quick process, but sometimes the most challenging steps yield the greatest returns.

 Next Steps for Your PCI SSF Compliance

Recent history has taught us that while it may be tempting to just pull in open source directly from the repository into your payment software, doing so can introduce new risks from different types of sources that could make for devastating setbacks for your organization.

But now you understand more regarding how the PCI SSF will approach these specialized vulnerabilities. Using this basic procedure we laid out, you can go back and review your software for open-source dependencies and include them in threat modeling in preparation for your SSF compliance.

We understand that, like most compliance initiatives, this one represents quite a mountain to climb, so we'd be happy to speak with you so we can alleviate any lingering concerns or specific questions you may have. 

In the meantime, read our other articles on the PCI SSF. They'll provide even more clarity for your preparation process to help you have as streamlined of a process as possible:

• 5 Major Gaps to Avoid When Transitioning from PA-DSS to PCI SSF (and How to Avoid Them)
• What is Considered "Sensitive Data" Within the PCI SSF?