The Beauty of the SBOM: Why It’s Essential for CRA Compliance

The beauty of an SBOM. What is an SBOM? Why do we need one? And how does it help me with CRA? Frankly, without an SBOM, all you're really doing is an outside in assessment. It's not much better than if I were to Google your product and maybe download your latest firmware and just look at it. It's really not going to tell me a lot of information about what risks you're bringing into my organization as a buyer of your software defined product. And SBOM allows me to look under the hood as an OEM or as a a manufacturer of these products and actually identify during the build process of this product, what pieces of code actually ended up in the binary. So there's source code analysis, there's binary analysis, and both of those are kind of irrelevant languages to an auditor. All an auditor wants to know is are there vulnerabilities inside of the product that you're bringing to the market? So you're kind of trying to translate multiple different outcomes from different starting points. And SBONG gives you a unified starting point to work with across many, many, many different types of products, across many different types of markets. So that then you can go from what is this bill of materials, what is the actual supply chain that is reliant on these bill of materials, how are the vulnerabilities associated with these supply chain components potentially introducing additional risks. And then you also probably need to contextualize those risks. So how is it that my particular product has implemented this particular set of code, and does that actually pose a risk to a user to the security posture of that product? That's something where the threat intelligence feeds can come in very handy, being able to identify whether or not that vulnerability has been weaponized in the wild. So, might be a CVE five. So, you've already kind of disregarded it. It is not that relevant, but they found a new way to leverage it. So, identifying that a vulnerability has been weaponized is something that can really escalate your prioritization. So now you know it exists. It exists in your code. It's exploitable. It's weaponized. And then the last bit though is with your particular architecture, is it reachable? Is it something that you can actually get to as an adversary? So perhaps this particular vulnerability relies on an x86 architecture and you're on an ARM processor, so it's not reachable. So you can do that attestation. So let's take CE red for instance. You can do that attestation with a document a certificate of conformance stating that, but you might be challenged to go a step further and actually have a third party attestation to that from a technical perspective. So being able to say, I did a binary analysis and within my binary analysis, I've identified that this particular vulnerability, despite existing in my code, is not reachable. It is not possible to be executed. So I can now just no longer need to worry about this. And there might still be a vulnerability disclosure that gets published, but it'll be low priority because it's not actually exploitable. And without that intelligence at the SBOM layer and all the other bits and pieces that lead up to it, you're guessing.