After Heartbleed: the audit you actually need to run

Nearly two months have passed since Heartbleed was publicly disclosed. The most acute phase - emergency patches, mass certificate revocation, a wave of coverage - is behind us. But in conversations with teams I keep seeing the same pattern: someone updated OpenSSL, got a new certificate, and considered the matter closed.

That is not always the right conclusion. Heartbleed was not just a vulnerability that needed patching. It was a signal about a broader management problem: companies often do not know what is actually running in their infrastructure or what state it is in.

What Heartbleed actually required

A complete response to Heartbleed involved several steps that followed the OpenSSL update, not substitutes for it.

Replacing SSL certificates. After updating the library, old certificates needed to be revoked and new ones issued - because private keys could theoretically have been compromised before the update. Many did this. Some did not.

Rotating sensitive credentials. If session data, passwords, or API keys were stored on or passed through a vulnerable server - they should have been rotated. This is a step that was often skipped.

Log analysis. Checking for signs of exploitation before the disclosure - theoretically possible, though not straightforward, because an attack via Heartbleed does not leave obvious traces in standard logs.

The deeper question

Heartbleed exposed a symptom: most organisations do not have a current inventory of their software components and versions. That means when the next vulnerability hits, they will again be in the position of "run around and check manually."

The audit worth running now is not only about OpenSSL. It is about readiness for the next incident.

A few questions that help assess this:

Do you have a current list of software components used in your critical systems, with version numbers? If not, that is a task worth putting on the plan.

Is there a process for monitoring public vulnerability disclosures? Not "someone occasionally reads the news", but a specific person or tool tracking CVE and other vulnerability databases against your stack.

Is there an incident response protocol for a critical vulnerability - who decides, on what timeline, who implements it?

What to do with limited resources

I understand that for small teams a full audit trail and monitoring processes are a difficult ideal. But there is a minimum viable set of actions.

Make sure server software is updated regularly. This does not solve the zero-day problem, but it significantly narrows the window for known vulnerabilities. One person responsible for updates and a monthly check schedule is already better than nothing.

Document where your "critical" is: which systems process payment data, personal user data, or authentication credentials. These are the systems to prioritise in any response.

Verify that every external access point to your systems uses current credentials with limited rights - not "one login for everything", but separated access.

A practical readiness test

One simple way to check the current state: ask your team to describe what they would do in the first two hours if tomorrow morning a critical vulnerability were announced in a component you use. If the team has a clear answer, a baseline process exists. If not, that is where to start.