What Makes an SBOM Trustworthy? Why Provenance, Freshness, and Depth Matter for Embedded Automotive Software

Software Bills of Materials (SBOMs) are now a standard part of automotive cybersecurity programs. Most organizations are generating them, and many are integrating them into their development workflows.

But as adoption increases, a more practical question is emerging: how much can teams actually rely on the SBOMs they have?

For Hemanth Tadepalli, a veteran of software security at multiple startups, the industry has an opportunity to strengthen how SBOMs are generated and used. When SBOMs are accurate, up to date, and integrated into development, they can provide meaningful insight into both security and compliance.

We spoke with Hemanth about what separates trustworthy SBOMs from liability-generating documents, why license obligations remain widely misunderstood, and how organizations can embed compliance as infrastructure rather than inspection.

The industry has been talking about SBOMs for years now. Why are they especially critical in automotive compared to other industries?

SBOMs in automotive are foundational to managing the scale, complexity, and longevity that define modern vehicle software ecosystems. A typical vehicle ECU ecosystem today comprises 40 to 100-plus software components spanning infotainment, ADAS, telematics, and body control systems. Each of these has its own dependency tree, creating a massive open-source software footprint that includes Linux-based systems, open-source middleware, and thousands of third-party libraries embedded across the firmware.

One watershed moment for SBOMs came in 2021 with the Log4Shell vulnerability. Organizations scrambled to answer a simple question: “Do we have Log4j anywhere in our vehicle software?” Many could not answer that question with confidence, highlighting why SBOM visibility is paramount. It transforms incident response from a months-long investigation into something you can triage in hours.

The challenge is compounded by the vehicle product lifecycle, which typically runs 10 to 15 years. A component that is clean today may have a critical CVE in year seven. Without accurate, maintained SBOMs, you cannot triage or patch that incident because you do not even know where the vulnerability exists in your deployed fleet.

You mentioned the Log4Shell moment. But even before we get to vulnerability response, many teams struggle with open source license compliance. Where are the most common misunderstandings around license obligations?

The biggest misunderstanding is not monitoring license obligations at all during the scanning process. We have seen high-profile attacks like the 2015 Jeep Cherokee hack demonstrate that cybersecurity in vehicles is both an IT problem and a safety problem. Teams are starting to understand this is just the beginning, especially with AI introducing even more complexity to license compliance.

From a compliance and regulation standpoint, frameworks like UN R155 and R156 now mandate that OEMs maintain software inventories and manage vulnerabilities across the vehicle lifecycle. ISO 21434 has made SBOM-equivalent practices a core expectation of cybersecurity management. Organizations see that these are not just guidelines but are regulatory requirements with real enforcement mechanisms tied to global market access.

What is encouraging is that many tools now integrate license scanning directly into CI/CD pipelines, enabling developers and DevOps engineers to automate compliance checks. But this only works if the culture is embedded from the very beginning. You cannot retrofit compliance late in the development cycle without significant pain and cost.

The key insight is that GPL does not care about your ship date. In automotive systems, copyleft risk is exponentially more expensive to remediate later. GPL and AGPL are what I call the “toxic licenses” in embedded environments because the obligation to disclose source code—including proprietary modifications—is incompatible with most OEM and Tier 1 intellectual property strategies.

There is also widespread misunderstanding around static versus dynamic linking. Many engineers believe that dynamic linking insulates them from GPL obligations, but courts and legal interpreters do not consistently agree on this, especially with AGPL, which extends copyleft obligations to network-delivered software.

A pattern I’ve seen repeatedly is that a developer pulls in a GPL-licensed library to solve a specific sensor fusion or signal processing problem quickly. It works, gets merged, and travels downstream through the supply chain—sometimes all the way into production firmware—before anything is flagged. That is why embedding license compliance from a shift-left approach is so critical.

That brings us to the central question: What actually makes an SBOM trustworthy? We see SBOMs being generated across the industry, but clearly there's a wide variance in quality.

Trust in SBOMs is challenging, but there are three non-negotiable attributes that must all be true simultaneously: provenance, freshness, and depth.

Provenance means understanding how the SBOM was generated and by what system. A manually authored SBOM is not the same as one produced automatically from the actual build system. You need to know if it reflects reality, not someone's best recollection of what they think is in the codebase.

Freshness is about whether the SBOM reflects what is actually being shipped today. An SBOM generated six months ago for an actively developed codebase is essentially useless if you are scanning for vulnerabilities now. In development environments today, drift happens in days, not months.

Depth refers to whether the SBOM covers transitive dependencies, not just direct ones. A flat list of first-level libraries may look complete, but the real vulnerabilities typically live two or three layers down in the dependency tree.

If any of these attributes are misleading or missing, you do not have a trustworthy SBOM. What you have is a document that gives you false confidence. And false confidence during incident response is worse than knowing you have a gap, because it delays your response and compounds the risk.

Where do you see the biggest SBOM gaps?

Gaps emerge most commonly from three sources. First, SBOMs that do not capture the full dependency graph during compilation. Second, suppliers who provide SBOMs that are incomplete, outdated, or manually generated rather than automated. Third, legacy systems where SBOMs were never created in the first place, leaving blind spots in your software inventory that you only discover when a critical vulnerability forces you to ask, “Where is this component deployed?”

That supplier dimension seems particularly challenging. The automotive supply chain is famously complex, with Tier 1s, Tier 2s, Tier 3s. What does good supplier transparency actually look like when it comes to SBOMs?

Good supplier transparency starts with recognizing that Tier 1 suppliers are often in the same position as OEMs and lack full visibility into what their Tier 2 and Tier 3 suppliers are delivering. Asking a Tier 1 for a complete SBOM often surfaces this gap immediately.

Contract language is critical here. Vague language like “provide software inventory” is far less enforceable than specific requirements that spell out the format (SPDX, CycloneDX), the depth (including transitive dependencies), and the validation criteria. The specificity of the ask directly determines the quality of the answer you receive from suppliers.

Validation is just as important as receiving SBOMs. An SBOM that arrives in a non-machine-readable format, lacks version pinning, or is clearly auto-generated without transitive dependency coverage is not operationally useful. It is a checkbox exercise that does not support real security or compliance work.

This is where regulation becomes leverage. OEMs now have frameworks like the BIS Connected Vehicle Rule and ISO 21434 to point to when negotiating supplier contracts. Suppliers who cannot deliver defensible SBOMs will increasingly find themselves locked out of supply chains, particularly in safety-critical systems.

Good transparency between OEMs and suppliers looks like shared tooling, shared standards, and shared accountability. Both parties benefit when vulnerabilities are identified early and patched quickly, rather than discovered in production or, worse, during a regulatory audit.

What advice do you have for generating trustworthy SBOMs for automotive?

The SBOM you generate for a compliance audit and the SBOM you actually use during a midnight incident response are often two very different documents. The industry needs to close that gap, and the only way to do that is through automation, integration, and treating SBOMs as living infrastructure rather than point-in-time snapshots.

Modern SBOM programs need actionable SBOMs. Vulnerability triaging, license enforcement, and supplier validation are all part of the downstream process that depends on SBOM quality. If you are early enough in your journey, my advice is this is to pick a standard format (CycloneDX or SPDX), automate generation at build time for your highest-risk components, and embed contractual SBOM requirements into your next supplier agreement before you actually need them in a crisis.

The ultimate goal is to make SBOM generation invisible to developers while ensuring that every build produces a defensible, machine-readable artifact that supports both compliance and security operations. When that happens, SBOMs stop being a burden and start being a foundational asset.

Let's talk about a concern we hear frequently: teams worry that rigorous compliance will become a development bottleneck. How do you prevent that while still maintaining security and regulatory requirements?

The framing is the problem. The moment you position compliance as a gate that engineering has to pass through before shipping, you have already lost. Engineers will find workarounds, leadership will pressure timelines, and the whole program collapses under schedule pressure.

Teams that get this right treat compliance as infrastructure, not inspection. License scanning runs in the pipeline automatically. SBOMs are generated at build time without anyone having to ask. Enforcement is tiered: critical violations like GPL in proprietary code or known CVEs in safety-critical components are hard stops. Medium-risk issues generate warnings. Low-risk items get logged but do not block the build.

If everything is urgent, nothing is. Developers stop trusting a system that treats every flag as a crisis. You need intelligent prioritization that aligns with actual risk.

What metrics actually matter for embedded teams?

The metrics that matter focus on mean time to detection and mean time to remediation rather than how many tests you run. How quickly can you identify a new vulnerability in your deployed fleet? How quickly can you patch it? Those are the KPIs that actually correlate with reduced risk.

You also want to measure SBOM coverage and freshness to understand what percentage of your codebase has accurate, up-to-date SBOMs, and how old is the oldest SBOM in production? Finally, track supplier compliance rates: what percentage of your suppliers are delivering SBOMs that meet your quality bar without repeated requests?

Compliance should accelerate development by catching issues early, not slow it down by introducing bureaucratic overhead. When you build it as infrastructure, it becomes a competitive advantage, not a cost center.

Looking back on your experience across multiple software startups, what's one hard-earned lesson you wish you had known earlier about integrating compliance, software supply chain management, and risk?

Start early. I cannot emphasize this enough. Working at startups throughout my career, I have seen the same pattern repeat: teams build something, put it together, and only then discover all the CVEs and vulnerabilities lurking in their stack. At that point, you are hiring additional people just to dig yourself out of technical debt that could have been avoided.

If you embed the solution from the very beginning—automated license scanning, SBOM generation, dependency tracking—you will have a clean pipeline and a clean SBOM lifecycle from start to finish. The cost of retrofitting compliance is exponentially higher than building it in from day one.

The other lesson is that perfect is the enemy of good. Do not wait until you have a comprehensive, enterprise-grade compliance program to start generating SBOMs. Pick the highest-risk components, automate what you can, and iterate. Progress over perfection. The teams that succeed are the ones that treat this as a continuous improvement process.

And finally, recognize that this is not just a technical problem but also a cultural and organizational problem. You need executive buy-in, cross-functional collaboration between security, legal, and engineering, and incentives that reward proactive compliance rather than punishing failures. The organizations that treat the BIS Connected Vehicle Rule and similar regulations not as hurdles to clear, but as opportunities to build the software governance infrastructure that modern vehicles genuinely require, are the ones that will thrive.

‍

About Hemanth

Hemanth Tadepalli serves as the Senior Cybersecurity & Compliance Subject Matter Expert (SME) at May Mobility, a company revolutionizing transportation through advanced autonomous vehicle mobility. His career spans notable roles at prestigious organizations, including management consulting firm AlixPartners, cybersecurity leader Mandiant, tech giant Google, and Michigan-based cybersecurity startup SensCy. Hemanth’s research focuses on advancing cybersecurity in critical areas such as autonomous vehicle security, Internet of Things (IoT) security, threat intelligence, risk management, API security, and election security. He was appointed by Michigan Secretary of State Jocelyn Benson to the Advisory Task Force overseeing statewide election security and integrity.

In addition to his technical contributions, Hemanth has published numerous articles on cybersecurity and emerging technologies, showcasing his thought leadership. He is a sought-after speaker, invited to present at prominent cybersecurity conferences, serve as a distinguished panelist, and share insights on technology-focused podcasts. His impactful work has earned him accolades, including the 40 Under 40 recognition from Oakland County, Michigan, and the Governor’s Service Award for his philanthropic efforts and community service in the field of cybersecurity. He was also named one of the 2025 Top 20 Voices in Automotive. Hemanth also serves on the oversight committee for the University of Michigan’s Michigan Translational Research and Commercialization (MTRAC) program, specifically for the Advanced Transportation Innovation Hub, a statewide initiative that supports translational research projects with high commercial potential, aiming to launch new technologies into the mobility and transportation sectors.