How hospitals spent the OpenSSL week waiting for ‘not affected’
A week’s warning of a critical OpenSSL flaw should have made the answer easy. For health systems, it depended on suppliers saying their products were not affected, and few could get that statement quickly, in usable form, or at all.
Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.
The week
On October 25, 2022, the OpenSSL project announced that it would release a fix on November 1 for a vulnerability it rated critical, affecting only OpenSSL 3.0, a version released in September 2021. OpenSSL is among the most widely used cryptographic libraries, embedded in operating systems, applications, network devices and medical equipment. The advance notice set off a week of inventory work. On November 1 the project released version 3.0.7, fixing two buffer overflows in certificate verification, CVE-2022-3602 and CVE-2022-3786. It downgraded the severity to high, explaining that exploitation conditions and common platform protections made remote code execution less likely than first feared. Systems running the still-common OpenSSL 1.1.1 were not affected.
Earlier in this series, Log4Shell showed that finding a vulnerable component is a search problem before it is a patching problem, and Spring4Shell tested whether hospital teams could triage without panic. The OpenSSL week was a cleaner experiment. The project gave seven days’ notice and an exact scope: version 3.0 only. Hospitals could search their own servers and code quickly. The hard part was everything they did not build: commercial applications, appliances, cloud services and medical devices. For those, the answer most of them needed was a supplier saying, credibly, that the product was not affected.
Most suppliers were not affected, because 1.1.1 was far more common in shipped products. That made the negative answer the bottleneck. A health system with hundreds of suppliers needed hundreds of statements, most of them reassuring, before it could focus on the few that mattered. Three things decided how fast that happened: knowing whom to ask, getting answers in a form that could be processed, and having a rule for suppliers who stayed silent.
Knowing whom to ask
A question cannot be sent without a recipient. Many health systems found that their supplier records named a sales contact or a support portal, not a security team. Medical device inventories often listed manufacturer and model but not the software version or the security contact. Some products had reached the hospital through resellers or as part of larger systems, so the actual producer was not recorded at all.
The fix is a supplier security contact map, maintained like any other critical register. For each product it records the producer, the version in use, where the producer publishes security advisories and who to contact when no advisory appears. Clinical engineering should own the device portion, since it already tracks service contracts and recalls. The map also needs a notification subscription for each supplier’s advisory feed, so statements arrive without being chased.
Cloud and software-as-a-service suppliers belong on the map too. Hospitals cannot scan a vendor’s hosted environment, so a statement is the only evidence available. Many large providers publish status pages for major vulnerabilities; smaller ones often need a direct question.
Group purchasing organizations and information sharing bodies can help. A question asked once on behalf of many hospitals is cheaper for the supplier to answer and faster for everyone.
Getting answers in usable form
Suppliers that did respond did so in every possible format: web pages updated several times, PDF letters, support portal notices, emails to account managers. Each had to be read by a person and matched by hand to the hospital’s inventory. A statement that a product line was not affected rarely said which versions it covered.
Machine-readable formats existed for this purpose. The Common Security Advisory Framework, approved as a standard in November 2022, structures advisories so tools can parse them. Vulnerability Exploitability eXchange statements, which federal agencies had been promoting that year, let a supplier say for a specific product and version whether it is affected, not affected, fixed or under investigation. A software bill of materials says what components a product contains. A VEX statement says whether a particular flaw in one of them matters. The two together turn a week of email into a query.
Even without standard formats, hospitals could control their own intake. Logging every supplier statement in one place, against the product and version it covers, with a status of affected, not affected, fixed or no answer, turns scattered emails into a dashboard. The security team can then report a single number to leadership each day: products still without a statement. That number is the honest measure of exposure during an event like this.
Hospitals had little ability to require these in October 2022. They could start asking for them in new purchases and at renewal, and give preference to suppliers who provided them. The payoff is greatest for medical devices, where scanning is often unsafe and the supplier’s statement is the only practical source.
Deciding what silence means
Some suppliers never answered. Others answered late. The health system needed a default for products without a statement, and few had one written down.
A sensible default treats a silent product as potentially affected if it plausibly uses the component and is exposed to the risk path. For this flaw, that path was a product verifying certificates from untrusted sources, such as a system accepting connections from the internet. Silent products on that path received compensating controls: tighter network restrictions, monitoring and, for devices, a check with clinical engineering on whether isolation would affect care. Silent products off the path were tracked and chased but not disrupted.
Silence should also have consequences in the supplier relationship. Response time to security inquiries is a measurable service level. Recording it for each supplier during events like this, and raising it at renewal, turns an annoyance into contract terms. The OpenSSL week was low stakes in the end. Treating it as a drill and recording which suppliers answered, how fast and in what form gave health systems evidence for the next, less forgiving event.
With hindsight
Two months later Congress gave the FDA new authority. The Consolidated Appropriations Act, 2023, signed in December 2022, required manufacturers of cyber devices to include cybersecurity information, including a software bill of materials, in premarket submissions. They must also maintain processes for addressing vulnerabilities after market. The FDA began applying those requirements to new submissions in 2023. CISA published minimum requirements for VEX documents in 2023, and supplier use of machine-readable advisories grew, though unevenly. The backdoor discovered in the XZ Utils library in 2024 tested the same capability again. By 2026, SBOMs and VEX statements are more common for new medical devices and major software products. Older devices and smaller suppliers still often require manual inquiries, so supplier contact maps and silence rules remain the controls hospitals can apply to their whole fleet.