When the Heartbleed Bug in OpenSSL emerged in 2014, I was head of Software Engineering at a medium-sized company and responsible for a team of 40 software engineers. We were implementing contract projects for our customers. Our customers were large corporations for whom we designed and developed digital products and services.
When the bug was published, many companies panicked. And it didn’t take long before we were also affected by the shockwaves and the debris that the bug had triggered. Customers were calling us. Even those we haven’t heard from in a long time have called us and asked for our help.
We had to quickly identify which of our customers’ systems used the affected software and were thus affected by the bug and vulnerable to the security risks. The big challenge was that this was often not easy, as we had customers on the line that we had no contact for years.
Because of this, we had no updated records of the components that were used in these systems and didn’t know which version they had installed. We needed to spend a lot of time painstakingly gathering this information manually. This meant searching through old documentation, and GIT-repositories and analyzing the used components.
If we had created a software bill of materials (SBOM) for each product we developed, we would have saved a lot of work and stress for us and our customers. Even better, we could have used existing SBOMs to proactively contact our customers and sell a better professional service to our customers.
The Heartbleed Bug was a serious security vulnerability in the OpenSSL cryptographic library, which is widely used to secure communication on the internet. It was discovered in April 2014 and received widespread attention due to its potential impact on the security of websites, web applications, and various networked services.
The vulnerability in OpenSSL, specifically in the implementation of the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols, allowed an attacker to read sensitive data from the memory of a server or client that was running a vulnerable version of OpenSSL. This data could include usernames, passwords, cryptographic keys, and other confidential information exchanged during the SSL/TLS handshake process, which is used to establish secure connections between clients and servers.
The name “Heartbleed” came from the way the vulnerability was exploited. It occurred in the “heartbeat” extension of the SSL/TLS protocol, used to keep a connection alive by periodically sending a “heartbeat” message. Unfortunately, due to a programming error in OpenSSL, an attacker could send a specially crafted heartbeat request to a vulnerable server, tricking it into responding with a chunk of its memory, which could contain sensitive information.
A software bill of materials (SBOM) could have helped by providing the necessary information in an inventory of all software components and their versions, making it easier to identify systems that were using the vulnerable version of OpenSSL affected by the Heartbleed Bug.
A software bill of materials is a structured, often hierarchical list of components, libraries, and dependencies that are used in a software system. It is very similar to the concept of a bill of materials in manufacturing physical products, which lists all the materials and components used to build such a product.
The purpose of an SBOM is to provide transparency and visibility into the software supply chain, thus helping product managers understand and manage what software components, open-source libraries, and dependencies are used in the application. A typical SBOM contains the following elements:
Why should your organization use SBOMs? And why should you as a product manager create an SBOM? Every modern software development team in the world uses open source tools, and open source libraries to develop a product.
Software systems are becoming more and more complex and managing these software components is an even more challenging task. Because with every new component and all these different components, it is very hard to manage licenses, ensure a secure and steady supply chain, and protect your system from known vulnerabilities.
But let’s look at the benefits of an SBOM in detail:
Especially when your software uses external components you have to consider licenses. There are different types of open-source licenses and every license demands different things from you and your team to consider. An open-source license usually describes how the software can be used, modified, and distributed. Often it demands that you make it publicly visible which open source library you use.
Keeping an overview of these licenses, rules, and dependencies is crucial for the success of your product. With the help of an SBOM, you can stay compliant with these demands of the license.
Understanding the licensing obligations can help you as a product manager to make informed decisions about the distribution and use of these components while avoiding any legal or compliance issues.
Some public sectors like the United States, European Union, United Kingdom, and Japan are regulating or recommending the use of SBOMs. Large tech companies like Google, Microsoft, and IBM are also using SBOMs to protect their systems from vulnerabilities.
Especially in the automotive and healthcare sector companies like Ford and General Motors, are demanding SBOMs from their suppliers, and with a 2022 regulation the Food and Drug Administration is demanding SBOMs from medical device manufacturers.
SBOMs provide transparency into the software supply chain, helping product managers to understand the origins of their software components. Software supply chain security has become a significant concern in recent years and examples like the Heartbleed Bug show how important it is to understand the supply chain of software components. An SBOM also allows product managers to assess the trustworthiness of component vendors.
With an SBOM, you create transparency. This information can be used to collaborate with open-source providers and the community. The SBOM thereby assists in coordinating patch management efforts by clearly identifying the components that require updates or fixes.
The Heartbleed Bug example above best describes how SBOMs can help manage vulnerabilities. With SBOMs product managers can track components and versions of these components and identify Software Systems that are exposed to security vulnerabilities. This enables software development teams to proactively manage vulnerabilities by promptly applying patches or updates to mitigate and report any security concerns.
With every added third-party component your development team builds a dependency on someone outside the team. This is a piece of viable information for you as a product manager.
An SBOM helps you keep an overview of all these dependencies. This includes frameworks, open-source libraries, external platforms, and tools, along with their specific versions. As a product manager, it is often not that easy to keep that overview.
Adding an open-source library is quite easy for a developer and a dependency is created often without the interference and notice of the product manager. Keeping the focus on an SBOM helps the team to avoid this.
In a real-world scenario, a product development team would use automated tools or scripts to generate and maintain an SBOM for a software product. This ensures accuracy and completeness.
The following example provides a basic structure to demonstrate the concept of an SBOM. But SBOMs can be tailored to the specific needs and requirements of your software product and the needs of your organization.
Here is an example of a simple SBOM:
Software Bill of Materials (SBOM) for “Awesome Webshop”
Components:
1. Frontend:
2. Backend:
3. Database:
4. Authentication:
5. Dependencies:
6. Development Tools:
7. Operating System:
8. Libraries:
9. Additional Components:
Certificates, Hashes and Signatures:
Vulnerabilities:
License Compliance:
The majority of components in this SBOM use the MIT License, except for MongoDB, which uses the Server Side Public License (SSPL) v1. Ensure compliance with license terms.
As a product manager, you should strive to have an SBOM tool in place. Maintaining SBOMs manually is an impossible task. But the generation of SBOMs can be automated easily, even with simple scripts you can reach quite good results.
The choice of an SBOM tool depends on the specific needs of your development team and the organization, such as the programming language, development environment, and the level of automation and integration required in your software development and supply chain management processes.
It’s important to select a tool that aligns with your organization’s goals for transparency, security, and compliance with software components and dependencies.
There are two standards for SBOM generation which are widely used in the Software Industry:
There are multiple open-source tools, commercial tools, and other sources that may help you and your development team analyze your software systems and create SBOMs. Here are some sources and tools you can use:
Creating SBOMs can have several benefits, but it does come with certain challenges and limitations. A major limitation in SBOM creation is fetching the right data and keeping up to date with the rapid changes. This leads to incomplete or inaccurate SBOMs.
This is why automation and tool support is such an important topic when it comes to SBOM creation. Besides this major challenge here are some other things you should look out for:
Software bills of materials are essential documents that list all software components and dependencies within an application or system. They hold significant importance for several reasons. They greatly enhance cybersecurity by providing a clear inventory of software components, helping organizations identify and address vulnerabilities effectively.
This proactive approach reduces the risk of cyberattacks and data breaches. SBOMs also promote supply chain transparency by revealing the origins of software components. This transparency aids in making informed decisions about software procurement and evaluating the security of third-party components and helps with managing licenses of these components.
However, using proper tool support is essential for efficient SBOM creation. These SBOM generation tools automate the process, reducing manual effort and ensuring accuracy. They often also offer vulnerability scanning capabilities, allowing product managers to prioritize and address security issues promptly.
Finally, there may be resource investments required for tool adoption and staff training. Despite these challenges, the benefits of enhanced cybersecurity and supply chain management make SBOMs a valuable asset in today’s interconnected digital landscape.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
At its core, product lifecycle management (PLM) software is a tool designed to manage every aspect of a product’s lifecycle.
Scenario analysis is a strategic planning tool that helps you envision a range of possible future states and the forces behind them.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
As a product manager, you express customer needs to your development teams so that you can work together to build the best possible solution.
Learn more →
