British Airways spent the first few days of this week explaining a breach. Somewhere around 380,000 payment cards lifted from their website and app over a fortnight or so, ending on the 5th, complete with the three digits on the back that you're not even supposed to store. The mechanism, by all the early reporting, was a chunk of malicious JavaScript skimming the payment page: read the card number out of the form as the customer types it, post it off to a server you control, done. No exotic cryptography. No kernel exploit. A script tag.
What struck me wasn't the breach itself, which is grim but increasingly ordinary. It was the absence of a name. This thing has no logo. There's no website with a tasteful colour scheme and a witty paragraph explaining the flaw to journalists. There's no t-shirt. And because of all that, it'll get a fraction of the attention that the last branded vulnerability got, despite being a far more accurate picture of how people actually lose money online.
I want to talk about that gap, because I think we did it to ourselves, and I think it's quietly making us worse at our jobs.
how we got here
The patient zero for branded vulnerabilities was Heartbleed, back in April 2014. A serious bug in OpenSSL, genuinely deserving of attention, dressed up with a bleeding-heart logo and a clean explainer site at heartbleed.com. And it worked. It worked spectacularly. My non-technical relatives heard about Heartbleed. Patches went out faster than they ever would have for "CVE-2014-0160". For a bug that bad, the marketing was a public good.
The trouble is that it also worked as a template. Once the industry saw that a logo and a domain name could turn a CVE into a news cycle, the logo and the domain name became part of the deliverable. Shellshock got branding. POODLE got a dog. DROWN, KRACK, Spectre and Meltdown, each arrived fully merchandised, with a site and an icon and a press embargo timed for maximum coverage. Some of those genuinely warranted it. Spectre and Meltdown reshaped how a generation of processors get designed. But somewhere in there the branding stopped being a way to communicate severity and became a way to manufacture it.
what the branding does to your risk model
Here's my actual worry, and it's not that branded vulnerabilities are bad. It's that they train the wrong instincts.
A named vulnerability is, almost by definition, a single dramatic flaw in a widely-used component. It's the kind of risk that's easy to reason about: there's a CVE, there's a CVSS score, there's a patch, you apply the patch, you tick the box. It fits neatly into a spreadsheet. It gives a manager something concrete to approve a maintenance window for. I have, more than once, used a vulnerability's branding precisely this way: walked into a room, said the scary name, and walked out with the patching time I'd been refused for months.
But the British Airways breach doesn't fit that shape at all, and almost none of the breaches that actually cost people money do. There's no single CVE. There's no patch to apply. The "vulnerability", if you can even call it that, is a diffuse, boring failure of supply-chain hygiene: a payment page that loads scripts from places nobody is watching closely, on a site big enough that nobody owns the whole picture. You can't assign that a CVSS score. You can't tick a box for it. And so it falls straight through the gap in a risk model that's been quietly trained to only see the things with names.
This is the Magecart family, for what it's worth, the loose label people have started using for these web-skimming groups. The technique is depressingly simple. Modern checkout pages pull in third-party JavaScript by the handful: analytics, tag managers, A/B testing, live chat, fraud scoring, the lot. Each of those is a script you've personally invited onto the most sensitive page on your site. Compromise any one of them, or the CDN it lives on, and you can read the form. The card data is sitting right there in the browser, in plaintext, before it's encrypted to the payment processor. Your immaculate server-side handling and your PCI compliance and your tokenisation never get a look in, because the theft happens upstream of all of it.
the boring defences nobody ships
The maddening part is that the mitigations exist and have for years. They're just not exciting, so they don't get prioritised.
Subresource Integrity is the obvious one. You pin the hash of an external script in the tag itself, and if the file you get back doesn't match, the browser refuses to run it:
<script src="https://cdn.example.com/widget.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"></script>
Swap the file, and it simply won't execute. That alone defeats a whole class of CDN-tampering attacks.
A real Content Security Policy is the other half. Restrict where scripts can load from, and crucially where the page is allowed to send data, and you take away the attacker's ability to exfiltrate to wherever they like:
Content-Security-Policy: default-src 'self';
script-src 'self' https://cdn.example.com;
connect-src 'self' https://payments.example.com
And the simplest defence of the lot: don't load your marketing stack onto the checkout. The page where people type card numbers does not need a chat widget and four analytics tags. Strip it back to the minimum and you've removed most of the attack surface for free.
None of this is hard. None of it is new. It's just invisible work that prevents an invisible problem, and invisible-prevents-invisible is the single least fundable category of engineering there is. There's no logo at the end of it. You don't get to walk into the room and say a scary name. You get to ask for time to remove a script that currently works fine, to prevent an attack that hasn't happened yet, and watch it lose every prioritisation argument to the thing with the CVE number.
what I'd actually change
I'm not arguing we kill the branding. It clearly moves the needle, and for genuinely severe, widespread flaws, moving the needle is worth a daft logo. What I'd change is the instinct underneath it.
The named vulnerability should be the exception that gets the spotlight, not the only shape of risk we know how to see. Most of what will actually hurt your users this year is boring, diffuse, and nameless: a stale dependency, a third-party script nobody audits, a permission that was meant to be temporary, a payment page carrying more JavaScript than it has any business carrying. None of that will ever get a website. All of it is more likely to empty someone's account than the CVE everyone retweeted on Tuesday.
So when the next branded vulnerability lands, by all means patch it. Use the name to get your window if you have to. But then spend the quiet weeks afterwards on the unbranded stuff: the script inventory, the SRI hashes, the CSP you keep meaning to tighten. It won't trend. Nobody will make you a t-shirt. It'll just be the thing that quietly wasn't on the front page this week, which, if you do it right, is rather the point.