When news about Heartbleed broke, many in the security community rolled their eyes. Not at the bug or the potential attack surface it exposed, but the fact that a software bug had a name, a logo, and its own website.
Most documented bugs are cataloged already with a CVE number and detailed technical description. That this bug required its own branding seemed ridiculous and, since then, has heralded the age where just about every bug disclosure requires a marketing effort.
But it's not actually a bad thing.
Just before Heartbleed broke, another critical security bug had been discovered in Apple's products. Now known as "goto fail," this was a coding mistake in Apple's TLS implementation that allowed a potential attacker to trick a computer into skipping verification of certificates.
As a developer, I understand how easy this kind of mistake can be. It also yielded several rounds of updates to various best practices documents to help developers avoid exactly this kind of error in the future. As a developer, I also saw easily how a bug like this could be exploited.
In fact, I learned about the bug when a friend demonstrated against my machine how it could be used to bypass proper security checks. I immediately encouraged everyone to update their systems to apply the patch.
Not everyone listened.
Consumers have a certain amount of upgrade fatigue. They're bombarded with application, OS, and other updates on an almost daily basis. Many of these updates either add unwanted features, remove heavily used ones, or break expected functionality entirely. It's not uncommon for end users to ignore an update notification for months to avoid the frustration that comes with trying to fix something that worked before the update.
The patch for "goto fail" was one such update. A couple of friends of mine - who happen to be fairly tech savvy on their own - ignored the update. It didn't make sense and the last update for their computers had broken some of the apps they used for work. Why upgrade?
Over coffee, they explained how they'd seen my "please update" email and, though they respected my opinion, couldn't risk their workday productivity. They did, however, want to know how much of an impact Heartbleed would have. Why hadn't I told them to patch that bug? Could I upgrade their machines in the cafe?
Heartbleed affects servers. Goto fail affects consumer desktops/laptops and phones. One had branding, one did not. Consumers were more aware of the one that hand branding - the one that didn't affect the machines for which they are directly responsible.
Heartbleed was fixed almost immediately. The more recently disclosed Meltdown and Spectre bugs also had patches available for most systems almost immediately. Apple's latest #iamroot bug had a patch deployed the same day as the disclosure - then another patch the next day to fix the new bugs introduced by the previous one.
As laughable as it might be from a security engineering perspective, good marketing around an exploit is vital to getting it addressed in a timely manner. I'm personally aware of several critical bugs that have gone unpatched for years because the development team thinks no one cares.
Every time I show someone a proof-of-concept exploit against a known issue, they can't believe it hasn't been fixed. When I point out the age of the first disclosure (usually a blog post heavily criticized for not contacting security@wherever directly), they shake their heads in frustration.
Still, until we as developers can get better at not breaking things when we release an update, consumers won't fully trust us with silent, background upgrades. Software should always be a transparent aid to the end user, not a cumbersome tool non-developers need to maintain.