Why Open Source Drives PCI Nuts

Written by Frank Hayes
June 10th, 2010

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.


5 Comments | Read Why Open Source Drives PCI Nuts

  1. Marc Says:

    Open Source and PCI can match well together: just to mention upcoming Magento PA-DSS compliance or CRESecure solution.

  2. Juan David Says:

    Hi everyone, I think that if an open source package is modified in any way, that software must be considered, automatically, a custom made application, and must comply with all requirement 6.

  3. Evan Schuman Says:

    That’s the danger. With any kind of modification, the app vendor is no longer responsible and the duty falls directly on the merchant, just as it had been a fully homegrown app.

  4. Shiva Says:

    Reminds me on a similar question on custom vendor ( again it was a customized oscommerce solution ). The vendor was asked on the PCI compliance and it was well put in that the bridge may not be established between PCI and software untill the software was finalized ( up and ready for the market ). I think that is the case with most open source software… after Os software is the clay and it can moulded anyway for that matter :).

  5. Greg McGraw Says:

    From a customization standpoint, open source software is great. But, paractically speaking, there is no way to audit the software for PA-DSS for that very same reason. We continue to preach ‘outsourcing’ payment acceptance to our open source merchants exclusively to one or more certified 3rd parties which effectively takes the software out of the scope of PCI and the categorization as a payment application. Level 4 merchants should research hosted payment pages, alternative payments, etc. and not rely solely on scans to claim that they are PCI compliant or rely on the shopping cart maker to PA DSS their software, which is clearly not in their basket of expertise.


StorefrontBacktalk delivers the latest retail technology news & analysis. Join more than 60,000 retail IT leaders who subscribe to our free weekly email. Sign up today!

Most Recent Comments

Why Did Gonzales Hackers Like European Cards So Much Better?

I am still unclear about the core point here-- why higher value of European cards. Supply and demand, yes, makes sense. But the fact that the cards were chip and pin (EMV) should make them less valuable because that demonstrably reduces the ability to use them fraudulently. Did the author mean that the chip and pin cards could be used in a country where EMV is not implemented--the US--and this mis-match make it easier to us them since the issuing banks may not have as robust anti-fraud controls as non-EMV banks because they assumed EMV would do the fraud prevention for them Read more...
Two possible reasons that I can think of and have seen in the past - 1) Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code. 2) Also, in offline chip countries the card determines whether or not a transaction is approved, not the issuer. In my experience, European issuers haven't developed the same checks on authorization requests as US issuers. So, these cards might be more valuable because they are more likely to get approved. Read more...
A smart card slot in terminals doesn't mean there is a reader or that the reader is activated. Then, activated reader or not, the U.S. processors don't have apps certified or ready to load into those terminals to accept and process smart card transactions just yet. Don't get your card(t) before the terminal (horse). Read more...
The marketplace does speak. More fraud capacity translates to higher value for the stolen data. Because nearly 100% of all US transactions are authorized online in real time, we have less fraud regardless of whether the card is Magstripe only or chip and PIn. Hence, $10 prices for US cards vs $25 for the European counterparts. Read more...
@David True. The European cards have both an EMV chip AND a mag stripe. Europeans may generally use the chip for their transactions, but the insecure stripe remains vulnerable to skimming, whether it be from a false front on an ATM or a dishonest waiter with a handheld skimmer. If their stripe is skimmed, the track data can still be cloned and used fraudulently in the United States. If European banks only detect fraud from 9-5 GMT, that might explain why American criminals prefer them over American bank issued cards, who have fraud detection in place 24x7. Read more...

Our apologies. Due to legal and security copyright issues, we can't facilitate the printing of Premium Content. If you absolutely need a hard copy, please contact customer service.