As cyber threats evolve, the 2025 Verizon Data Breach Investigations Report (DBIR) reinforces a hard truth that many in cybersecurity have come to accept: your risk surface is only as strong as your weakest third-party link. This year’s report paints a striking picture—third-party involvement in data breaches doubled, accounting for 30% of all breaches, up from just 15% the previous year.
I’ll save the readers from going into a shameless pitch about how Fortress can help manage third-party risk but as an individual that spends his time specifically dedicated to researching the vulnerabilities 3rd party software libraries introduce, this number doesn’t surprise me. This also feels like an opportunity to discuss how some of these risks can be mitigated by introducing Software Bill of Materials (SBOMs) early into the procurement process.
First, a quick primer on what third party software is. The status quo for software development is that developers often (read: always) fulfill several engineering requirements by importing, or copying, third party software libraries. Software libraries that they themselves did not write but instead write supporting code to use and leverage those libraries. You may have seen the image below that at this point has become a commonly circulated meme, but it perfectly sums up how software is built; by stacking blocks (third party software libraries) together to build the final product.
Figure 1: source? who knows, I've seen it float around so many times.https://www.explainxkcd.com/wiki/index.php/2347:_Dependency
On one hand, this is fantastic! We wouldn’t have the software products we enjoy today without the widespread sharing of software libraries. It simply wouldn’t be economically possible to build complex software without standing on the shoulders of giants. On the other hand, as the DBIR report illuminated, it introduces a massive vector for security risks. We’ve seen over and over again the security incidents that are caused by vulnerabilities introduced by third-party software: Heartbleed, Log4j, etc.
As software users/customers, this presents a serious problem. Firstly, we are completely beholden to the vendor patching the libraries they use. Secondly, we have NO idea what’s included in the black box we just bought and if we’re all being perfectly honest, the vendor doesn’t always know 100% what’s in every nook and cranny of their software product. One example comes to mind; I was performing some static analysis on a piece of software for one of our utility customers to build an SBOM. One of the pieces of third-party software I found was zlib, which had some vulnerabilities. The vendor swore up and down they weren’t using zlib. In the end we were both wrong, sort of. What they were using was InstallShield which relied on the zlib library and in this case, a vulnerable version. The version of InstallShield they were using did prove to have a vulnerability, which they subsequently patched. I considered this a win and a textbook use-case for SBOMs.
Now, while I wasn’t 100% correct in my finding, this illuminates the problem. If the vendor knew they were using a vulnerable version of InstallShield, why did they keep using it? The answer of course is they didn’t ‘really know’ what version of InstallShield they were using, the only time it was used is at compile time. InstallShield sat innocuously for years, quietly working without issue so why would it garner any attention? This is the case throughout industry, and who can cast the first stone? Code is sometimes more fragile than we all want to acknowledge and patching third party libraries is often at the bottom of priorities. Dev teams don’t have a patch Tuesday to update all libraries used in their code. They also don’t want to spend the remainder of the week fixing all the issues introduced from blindly patching.
Alright, enough of the same ‘sky is falling’ story we’ve all heard at every security-oriented conference. Instead, I want to discuss a concept that I think is gaining traction in industry. Push the SBOM responsibility onto the vendor at the time of procurement or alternatively, make SBOM generation part of your procurement process. Both will send a clear message that transparency into the ingredient list of the software and the risks they introduce is a priority for your organization.
As it currently stands, I normally see that the majority of the time vendors don’t readily have SBOMs available and are unwilling nor contractually obligated to participate in providing an SBOM. This is problematic because the vendor is best positioned to generate an SBOM. While SBOMs can be produced from the software files using static analysis, it’s either out of technical reach for a customer to do so, or it’s expensive to hire another provider to do it for them. More importantly, generating an SBOM using static analysis isn’t as accurate as doing so from the source code.
Not only are vendors in the best position to produce the SBOM but they are in the best position to gain a win from the SBOM. A security win for a vendor is a security win for all of their customers! When vendors produce their own SBOMs it usually signifies that they care about the ingredients going into their own software product. This is reflected in what I see on a weekly basis when working with vendors on behalf of my utility customers. Usually, the most transparent vendors are running the most up-to-date versions of software libraries, are aware of the risks introduced, and have addressed them because they know they can’t just push the outdated security-burdened software library into the corner and hope no one notices.
When introducing SBOMs as part of the procurement process it also affords the opportunity to evaluate the maturity of a vendor. When evaluating similar software products, requesting an SBOM at procurement can also help separate the wheat from the chaff. A software vendor that produces SBOMs, and is willing to share with potential or existing customers, shows a dedication to software supply chain security.
Does having an SBOM provided by the vendor at the time of procurement solve all security risks introduced from third-party software libraries? Of course not! But it solves a significant problem of visibility into the product that can be monitored. Not if, but WHEN new vulnerabilities are discovered, SBOMs can provide valuable insight into determining if the black box operating in a substation somewhere is, or is not, affected.
Conclusion
The 2025 DBIR makes one thing clear: third-party software risk is no longer peripheral—it’s central. While SBOMs may not be name-checked in the report, the challenges it lays bare are precisely what SBOMs are built to mitigate. If organizations are serious about turning the tide against software supply chain threats, adopting and operationalizing SBOMs must be a core part of that strategy.
It's time to stop flying blind. SBOMs offer the map we need to navigate an increasingly dangerous software landscape.
