Latest / Cybersecurity Business with Fexingo: Security Companies, Breaches, and Enterprise Defense / How Software Bill of Materials Improves Supply Chain Security
Transcript
- Lucas: So December 2021, Log4j hits. Every CISO in the world is asking: do we even have this library in our code? And the answer for too many companies was: we have no idea. Luna: Right, because they didn't have a clean inventory of all the dependencies buried in their applications. Lucas: Exactly. And that's where the Software Bill of Materials — SBOM — became more than just a buzzword. It's essentially an ingredient list for software. It tells you every component, every library, every dependency that makes up your application. Luna: So it's like when you buy packaged food — you want to know what's inside, especially if there's a recall. Lucas: Perfect analogy. And it's not a new concept — hardware has had bills of materials forever. But for software, especially with the explosion of open-source code, it's been shockingly absent. The Log4j moment changed that. Luna: What actually drove the adoption? Was it regulation? Lucas: Partly. In 2021, the Biden executive order on cybersecurity mandated that any software sold to the federal government must include an SBOM. That rippled through the entire software industry. Then CISA released guidance on SBOM formats, making it more practical. Luna: I've seen numbers that by 2025, over sixty percent of enterprise software buyers were requiring SBOMs from vendors. But actually implementing them is a different challenge. Lucas: It is. The industry has settled on three main formats: SPDX, CycloneDX, and SWID. They're all machine-readable, which is crucial because manual spreadsheets don't scale. Tools like Anchore, Snyk, and FOSSA automate SBOM generation from your source code and container images. Luna: So you can automatically generate an SBOM every time you build a new version of your application? Lucas: Exactly. And that's the key — it's not a one-time document. Software changes constantly, so the SBOM needs to be generated at each build. Companies like Capital One have built pipelines that generate SBOMs automatically in CI/CD and then cross-reference them against vulnerability databases. Luna: That's the dream scenario. But I imagine most organizations are still in the early stages — just getting a static SBOM for their main products. Lucas: You're right. A 2025 survey from the Linux Foundation found that while over seventy percent of organizations are aware of SBOMs, only about thirty percent have fully integrated them into their development lifecycle. The challenges are real: format fragmentation, lack of tooling maturity, and the sheer complexity of modern software stacks. Luna: And what about third-party software? If you're using a vendor's product, they need to give you their SBOM. That's a whole other layer. Lucas: Yeah, that's the supply chain part. You're only as secure as your least transparent vendor. There are now security ratings firms — like SecurityScorecard and BitSight — that are incorporating SBOM completeness into vendor risk scores. So there's increasing pressure on software vendors to provide them. Luna: That's interesting — it becomes a competitive differentiator. If you can show prospects a clean SBOM, you might win deals over a competitor that can't. Lucas: Exactly. Look, we do these deep dives every single day — exploring exactly these kinds of operational shifts — and we deliberately don't run ads. If you find these conversations useful for what you're building or running, the best way to support that choice is at buy me a coffee dot com slash fexingo. Luna: It really does make a difference. Keeps the whole thing independent and focused on what matters. Lucas: So back to that competitive angle — it's not just about risk reduction. Companies that embrace SBOMs are finding they can respond to vulnerabilities in hours instead of weeks. Luna: Because when a new CVE hits, you just run a diff against your SBOM database and know instantly if you're affected. Lucas: Right. And that's where automation really pays off. Instead of a human manually checking every library, you have a script that matches CVE identifiers against package names and versions in your SBOM. Some tools even automatically open a pull request to patch it. Luna: That's efficient. But I've heard that maintaining SBOMs for legacy applications is a nightmare — especially if you don't have the original build environment anymore. Lucas: It's definitely harder. There are reverse-engineering tools that can analyze compiled binaries to reconstruct dependency information, but it's not perfect. Some companies are taking a pragmatic approach: generate SBOMs for everything going forward, and for critical legacy apps, do a one-time effort to document them as best you can. Luna: What about the human side? I mean, developer culture — do developers actually like this? Lucas: Mixed. Some developers see it as overhead, especially if they have to manually tag dependencies. But others appreciate that it reduces stress about unknown vulnerabilities. If SBOM generation is built into their existing tools — like their integrated development environment or their CI pipeline — it becomes frictionless. Luna: So the key is embedding it into the developer workflow, not adding a separate process. Lucas: Exactly. And I think we're moving toward a world where SBOMs are as standard as unit tests. There's even talk about insurance companies requiring SBOMs as a condition for cyber insurance. If you can't prove what's in your software, you might not get coverage. Luna: That's a powerful motivator. So in a few years, an SBOM could be as important as a financial statement. Lucas: Maybe not that dramatic, but close. Regulators, customers, and insurers are all pulling in the same direction. The technology is maturing — there are open-source tools, commercial platforms, and industry standards. It's really just a matter of adoption velocity now.