While OpenSSL downgraded the criticality of its 3.0.7 security patch from Critical to High (CVE-2022-3786 and CVE-2022-3602), and it’s fair to say that this is not the next Heartbleed, many organizations still need to treat this as critical. For example, OpenSSL cites the use of stack overflow protections in modern software as a reason for the downgrade. Yet, many critical applications are not modern, such as those that run ATMs, utilities, and other critical infrastructure. Furthermore, there is ample evidence of difficult vulnerabilities being exploited such as the NSO’s iMessage exploit.
Ultimately, the primary lesson here is that well-documented and maintained SBOMs provide agility to security postures that is now essential. Yet, SBOMs require two things to be effective:
- They must be built and maintained before you need them.
- They must be comprehensive because addressing 99% of vulnerable dependencies still leaves the door open for attackers who only need to find one way in.
The OpenSSL 3.0.7 patch demonstrates both of these points because of OpenSSL’s ubiquity. Organizations without SBOMs have been scrambling to identify vulnerable OpenSSL usage since last week’s announcement. This is a prioritization issue that most organizations would seemingly be equipped to solve. However, getting cross-functional buy-in to prioritize anything that is not immediately urgent remains challenging for most application security teams.
Going deeper into SBOMs is even more difficult. Looking at package managers is not enough as dependencies (especially widespread libraries like OpenSSL) can be linked and compiled in various configurations that affect exploitability. However, creating comprehensive SBOMs for OpenSSL is no easy task because virtually all programming language ecosystems embed OpenSSL; it may be part of the operating system, and many other programs could include and use it. Unfortunately, existing SBOMs tend to focus too narrowly on source code.
In addition, an extended attestation that includes build information would significantly improve the capability to identify exposed software. For example, this is part of SLSA attestation as suggested by Google. The build information would contain the specific configuration used which affects the exploitability.
The fact that OpenSSL is so widespread means that today’s reality requires a “Pipeline Bill of Materials” (PBOM) approach because OpenSSL is commonly used beyond the application’s source code but also in the infrastructure used to build and deliver the application. PBOMs expand on SBOMs in two key ways to better reflect how dependencies are used today.
- PBOMs take into account third-party code that could lead to a breach regardless of whether or not it’s in the application itself. While SBOMs focus on open source libraries, SDKs, programming languages and frameworks, PBOMs also look at development tools (e.g. Jenkins), development tool ecosystems (e.g. Jenkins plugins) build modules (e.g. GitHub Actions), etc.
- PBOMs take into account where dependencies are actually deployed in runtime environments. When you have widespread complex security updates, knowing where each instance is deployed (e.g. the exact Kubernetes pod) greatly reduces response times. Moreover, a list of production deployment locations also serves as a checklist to ensure comprehensiveness because again, the attacker only needs to find one way in.
So while CVE-2022-3786 and CVE-2022-3602 are not as critical for as many organizations as Heartbleed was back in 2014, they easily could have been. Still, we should treat this exercise seriously to poke holes and find weaknesses in our SBOMs and PBOMs as recent history (Heartbleed, Struts, Jackson-databind, LodDash Log4Shell, Log4Text, etc.) demonstrates there’s always another major dependency just over the horizon.
To learn more about implementing NIST/CISA’s SBOM requirements sign-up for the upcoming webinar and to see how Cycode creates and maintains PBOMs, schedule a demo today.
—
This post was co-authored by Alex Ilgayev and Andrew Fife.
