The Next Heartbleed?

Heartbleed (CVE-2014-0160) in 2014 left the industry in a scramble...

Parth Patel

October 31, 2022

Heartbleed (CVE-2014-0160) in 2014 left the industry in a scramble to patch one of the most prominently used open-source projects in the ecosystem today, OpenSSL. Major operating system vendors, software publishers, email providers, and technology companies all utilize OpenSSL in some form or another. They first had to work quickly to determine where OpenSSL was being used in their environment (internally built or vendor-supplied), and then take the necessary actions to remediate the vulnerability.

We fast forward to a couple of days ago (Oct 26th) when another “critical” vulnerability in version 3.0 of the OpenSSL project was announced. Though there are few details on the actual flaw and its criticality, the project is set to release a new version of OpenSSL (3.0.7) on Nov 1st to patch the defect.

Where do I start?

While the criticality of this new vulnerable version of OpenSSL is yet to be determined, just the fact that it is used so widely in the tech industry is a cause for concern. Organizations will have to move quickly to determine if and where they are vulnerable. Adding more scanners is not the answer. Scanning has always been reactive and the industry needs to move toward a more proactive approach. With the introduction of SBOMs and the signing of artifacts, companies are moving in the right direction but these alone do not solve the issue.

To start, having your own internal inventory to track your software that maps out your environment is a must to remove the stress of finding a needle in a haystack. Whether it is OpenSSL, log4j, text4shell, or various other vulnerabilities that have been discovered in the past year, this issue is set to amplify. Having a robust and accurate inventory management system can start to ease the burden of answering what exactly is running in your environment and where.

Continued Risk

This will not be the last critical vulnerability that causes a stir in the ecosystem. As the reliance on open-source software grows, this need for understanding what you are consuming and where it is located in your environment needs to be answered.

The open-source project GUAC (Graph for Understanding Artifact Composition), headed up by Kusari in collaboration with Google, aims to help answer hard security questions. One main question that continually arises: “How and where am I affected by a vulnerability?”. Through ingesting various metadata documents (such as SBOMs, SLSA attestation, OSV, and VEX), GUAC aims to provide a rich interface to quickly answer where OpenSSL is used and if it needs to be remediated. We have written an extensive blog to describe this project in detail. While the project is very much in the pre-alpha stage, having an accurate inventory and CMDB can be a start to ensure vulnerable systems do not fall through the cracks.

Beginning the Journey

It can be daunting to start down the path to understanding your supply chain. There is no single solution to this problem. All the pieces from generating accurate SBOMs, valid attestations, and signing artifacts, need to come together equally to truly make this a proactive approach to security. If you are struggling to get started or just have questions on the path forward, contact us below and we can start the journey together.

‍

Like what you read? Share it with others.