Alon and I come from a military computer security background so we're well aware of the risks. Security is always on our minds. I mean that in the sense that a security breach would be devastating to our reputation so we try very hard to make sure that doesn't happen. In fact, we recently beefed up security measures on the Hub just in case.

PCI DSS stands for Payment Card Industry Data Security Standard. It's targeted at organizations holding or transmitting credit card information. It doesn't strictly apply to a service like the Hub because we don't have our own billing system. Amazon handles that sort of thing.

Despite that the security measures we use in practice are actually quite a bit more strict than PCI compliance requires. IMHO, PCI guarantees a minimum level of sanity with regards to security measures but not enough to prevent a breach, which is why you see so many happening in practice even at organizations that are supposed to know better. It's better than nothing but it's not good enough. In most organizations there are so many moving parts that it can be very difficult to fully understand the complexity of the risks involved.

Usually what happens is that whomever is responsible (e.g., in-house or outside contractor) focuses on mitigating the visible risks (e.g., strength of encryption protocols) that are very unlikely to lead to a real-world compromise while neglecting the the less visible risks that do.

For example, in the real world rather than attacking the target server directly or trying to break the encryption an attacker is much more likely to compromise your organization by exploiting a client-side (e.g., PDF/flash) vulnerability to take over one of your staff members PCs and then exploit trust relationships to worm their way through your internal network. That's how RSA was recently compromised.

That's a real world risk scenario that PCI DSS doesn't mitigate and is nearly impossible to prevent if staff is using proprietary software that has a poor security record. Anything developed by Adobe for example (e.g., PDF, Flash, etc.). Adobe's software is ubiquitous yet their track record is terrible. There's no doubt in my mind that for every known security vulnerability there are dozens of 0-day security vulnerabilities lurking.

Unfortunately due to political reasons you'll never see a recommendation to only use open source software with a good security track record in all systems (client and server) that have may be used as stepping stones in an attack, but that's one of the things you need to do to mitigate real-world attacks.

Then it will depend on the company that you choose to audit your site and how they test for vulnerabilities. From my understanding, most (if not all) do simple software version checks. Currently an unmodified TKL appliance will not pass those sort of tests as the versions are technically too old. However the security issues affecting the software would generally have been patched (via auto installed backported security patches). That is not always the case as software such as Magento is installed from upstream (and as such will not auto update).

So short answer: Do TKL appliances suffer from security vulnerabilities that PCI compliance requires? No, generally not. Does this automatically mean that my TKL site will be 'PCI compliant'? Probably not...