Heartbleed, Shellshock and the fragile foundations of the internet

A missing bounds check, a global scramble

On 7 April 2014 the OpenSSL project disclosed CVE-2014-0160 — quickly nicknamed Heartbleed — a missing bounds check in the handling of the TLS heartbeat extension that allowed attackers to read up to 64 kilobytes of a server's memory per request, potentially exposing private keys, passwords and session data. OpenSSL secures a majority of the web's encrypted traffic, and the flaw had sat undetected in the codebase since 2012.

Five months later, on 24 September 2014, a second foundational bug surfaced: Shellshock, a family of vulnerabilities in the GNU Bash shell that let attackers execute arbitrary commands via crafted environment variables. Because Bash sits underneath countless web servers, routers and embedded devices, Shellshock's blast radius rivalled Heartbleed's within days of disclosure.

“The internet's encryption and shell infrastructure was found to rest on the unpaid labour of a handful of engineers — a risk the industry could no longer ignore.”

The maintenance gap

What alarmed the engineering community was not just the bugs themselves but what they revealed: OpenSSL, then securing an estimated two-thirds of active websites, was maintained by a small team with limited full-time resources, while security-critical review had not kept pace with the code's spread into mission-critical systems.

The response was rapid and instructive. The Linux Foundation launched the Core Infrastructure Initiative later in 2014, pooling funding from major technology firms to support audits and paid maintenance of critical open-source projects — a direct acknowledgement that widely depended-upon software cannot be secured on volunteer goodwill alone.

• Heartbleed (CVE-2014-0160): disclosed 7 April 2014, present in the codebase since 2012.
• Shellshock (CVE-2014-6271 and related): disclosed 24 September 2014, affecting Bash going back decades.
• Core Infrastructure Initiative launched by the Linux Foundation in 2014 to fund audits of critical open-source projects.

Why this matters beyond one bug fix

Both incidents forced enterprises to patch systems, revoke and reissue certificates and rotate credentials at a scale rarely seen before. They also exposed a governance blind spot: organisations routinely build products on open-source components without funding, auditing or even inventorying those dependencies — a practice that later matured into software composition analysis and, eventually, the software bill of materials.

For the profession the lesson was less about a specific coding error than about due diligence: knowing what is in your software supply chain, and treating unpaid maintainers of critical infrastructure as a systemic risk rather than a free resource.

What the Society recommends

The Society urges organisations and practitioners to treat dependency management as a core competence rather than an afterthought.

• Maintain an accurate inventory of third-party and open-source components in every deployed system.
• Support financially, not just technically, the open-source projects an organisation depends upon.
• Build patch-and-rotate procedures for credentials and certificates into incident response plans before a disclosure, not after.
• Treat open-source stewardship as within the ethical remit of the profession — accountability does not end at a company's own code.