Teams building innovative new products do so on the shoulders of giants. Let me explain. When you build on top of the latest boards from NXP, ST Micro, Texas Instruments or others, you will be using their Software Development Kit (SDK) to base your code on.
SDKs contain a lot of content around board bring-up, device management, graphics, power management, communication, Bluetooth, WiFi, you name it. And in the latest generations of these boards, AI will be included on top of that.
Similar, if you are building software on top of Android or Apple phones, you will use their SDK to link your software against. Even if you are using cameras in your product for computer vision, you will have an SDK that you use for that.
Another Layer of Complexity
The use of SDKs certainly enables teams to get to market faster. However, they also add more challenges in regards to meeting new regulations.
For example, in Europe, the Cyber Resiliency Act requires organizations to generate, maintain and provide an SBOM for all software for products that they put in the EU market. In the USA, SBOMs are mandated as part of federal government procurement processes and are slowly making their way downstream from there. The U.S. Food and Drug Administration (FDA) also requires an SBOM as part of the pre-market approval process for medical devices.
More often than not, you are unlikely to get an SBOM from with your SDK. Some vendors provide one, but the vast majority do not. Additionally, significant amounts of the SDK are only delivered as binary. If you do not have the source code, you do not have an SBOM. So, how can you satisfy your regulatory needs for visibility into the SDK via SBOM? Lastly, even if you have an SBOM from your vendor, the SBOM will cover the entire SDK even though you may only use a small part of it.
Seeing Into Your SDK
This is where Binary Composition Analysis (BCA) comes in. When you scan your product deliverable through a BCA tool like CodeSentry by CodeSecure, it generates an accurate SBOM for you, specifically tailored to your product and only that part of the SDK that you use. Instead of waiting until the product release date, which is too late in the cycle, you can generate an SBOM at relevant points during your software development cycle.
The SBOM will also include license information, which helps to make sure that your product aligns with the licenses you can support and does not include any viral licenses.
Example of SDK Data in SBOMs
Generating an SBOM from the product binary saves time. And, with the proper BCA tools, it should be quick and easy to do at the necessary stages of development, with immediate feedback.
As an example, I was working with a global conglomerate recently who uses CodeSentry as part of their security review process. One of their teams was getting ready to release a new product. When we scanned the product with CodeSentry, we quickly discovered that there were a couple of major problems to resolve. The first one being an unacceptable number of known vulnerabilities due to older open-source components being used. The second problem being that the product relied on components with GPL licenses.
After a quick review, we discovered that these dependencies were due to reliance on an older vendor SDK. The team took two actions. First, they immediately reduced scope, which allowed them to release critical content to their customers. Next, they worked with the SDK vendor to upgrade to newer versions of the required open-source components.
This example shows the importance of scanning the toolkits just as you would any other third-party code.
In summary, if you are building your products with third-party SDKs and your products fall under regulatory SBOM requirements, you should look into Binary Composition Analysis to ensure your products support that regulation. For now, this includes systems developed for the US Federal Government, Medical Devices, Automotive, and other critical infrastructure, as well as the wider European Market.
