Evan Schuman's StorefrontBacktalk

The big advantage to open-source software is that anyone can change it. And the big disadvantage to open source? Anyone can change it. Case in point: osCommerce, one of the applications on the PCI “Bad Apps” list. It’s not a surprise that this open-source app hasn’t passed PCI’s validation. Considering that it can be changed so easily, would you really want it to?

Most of the software packages on the Bad Apps list come from conventional commercial software vendors. If there’s a problem with their applications–specifically, if those apps keep sensitive authentication data after a transaction has been authorized–the vendors are usually quick to create a new version or a patch that solves the problem. Result: Only older versions of the software contain the security problem that makes PCI unhappy. And next to the bad version of the app is a note listing the later versions that don’t have the problem.

But there’s no such notation next to the osCommerce entry on the Bad Apps list. And that’s not all: The osCommerce entry lists a version that was obsoleted seven years ago. What’s going on? Does PCI have it in for open-source software?

Probably not. More likely is that some of the quirks of open source make it harder for PCI to figure out just how to handle it. For example, the current widely used version of osCommerce has been a “release candidate” for years. In commercial software, that means “not ready for production use.” In some open-source projects, however, it means “not obsolete yet.”

Another challenge for PCI is the fact that the people working on open-source software, even the ones who are producing commercialized packages, often just aren’t interested in getting certifications from groups such as PCI. No one is riding herd on the process, making sure patches and upgrades are submitted to PCI for testing.

Here’s the biggest problem for PCI with open source, though: Because anyone can customize the code, its testing process may not help much anyway. A PCI assessor wants to look for specific versions of specific software packages to cut the effort required to make sure a retailer’s systems are PCI compliant. That approach works well for conventional commercial apps, where the source code is locked down. For endlessly customizable open source, it’s practically useless.

If there are dozens of customized versions of a software package available, how much sense does it make to try to get PCI to OK every one of them? This is especially true when any of those versions can be modified again by anyone who implements them, so another dozen or two could appear next month.

It’s as if this is custom code. And that’s the best way to handle open-source software for PCI assessment purposes. It’s designed to be easily customized. If you’ve decided to use open source, treat it that way. Then, as with other software that’s not on the “Good Apps” list, it’s up to your assessor to determine whether the software meets PCI requirements.

If it doesn’t, you can choose between either changing it yourself or finding another package that can do the job and is already PCI-certified. After all, that’s what the “Good Apps” list is for.