Validating Third-Party SBOMs: Trust, Verify, Comply

When you're looking at third party SBOMs and trying to kind of correlate what SBOM you've received, let's say you're an automotive OEM and you've received an SBOM from your tier one supplier and you want to identify if this SBOM is actually correct and you'd like to do an internal scan of the same binary, This allows you to kinda implement the tried and trusted approaches to security. Right? So you go first with defense in-depth. So we go with multiple layers of potential defenses. This is old school. It's been around forever. The next one is trust but verify. So I trust my tier one. I believe that they have an up and up security program, paying them for it. But I also want to verify that it is correct and is working. That can cause a little bit of friction inside of the organization, especially with the long term relationships. I look at something like the various AutoSAR relationships that are in the ecosystem. You really can't get away from the provider that you have chosen for that as a tier one developer. So kind of asking them if you can do that scan can be a tricky conversation. But at the end of the day, it's you as the tier one who will need to attest to the OEM that after start of production, you're going to maintain ten years of security continuous monitoring. So if you can't make that attestation confidently, then you can't really make that attestation. So I think it's extremely important to not only improve compliance posture, but also kind of require in order to meet the requirements of something like a twenty one thousand four thirty four or an R155, you actually need to have some external validation, or else you're kind of running the risk of, building a house of cards where you're building, like, layers of I promise you I'm secure on top of I promise you I'm secure without really verifying that bottom most foundational layer.