Preparing Our Response to the OpenSSL Security Flaw

Summary

Heroku prepared for an announced high-severity OpenSSL vulnerability whose details were embargoed until patch release. The team began by mapping exposure and system criticality, considering SSL clients, possible man-in-the-middle attacks, encrypted database connections, and worst-case remote code execution, then created stack-image update actions and priorities. Engineers were assigned responsibilities under the existing incident-response process, with communication rules, escalation criteria, paging, and availability planned in advance. When the OpenSSL update and vulnerability details arrived on July 9 at about 8am Central, triage showed it was neither an RCE nor server-side issue, and Ubuntu reported that neither LTS version was affected; because Heroku production used LTS, no remediation or all-hands response was needed. The preparation still exercised exposure review and response coordination for future incidents.

Takeaways

1. 1

   Heroku's SSL endpoints for hosted applications were ELBs provided by AWS, so potential ELB patching would be coordinated with Amazon.

2. 2

   The response plan assigned explicit ownership, defined all-hands criteria, established communication procedures, and arranged for the security team to monitor information through the patch release.

3. 3

   The released vulnerability was neither remote code execution nor server-side, and Ubuntu reported that neither LTS version was affected; because Heroku production used LTS, no remediation was required.