If your product ships it, you own the risk in your product, even when the library arrived inside a chip vendor SDK. The vendor may own the fix, but you own the decision to ship, patch or mitigate. Find the bundled libraries, ask for their status, and record what you decided.
Ownership has two parts
Think of ownership as two questions.
- Who can fix the code? Often the SDK vendor, or the library's own project.
- Who is accountable to the customer? The company that sells the product.
ETSI EN 303 645 supports the second view. Its note on provision 5.2-3 expects manufacturers to exercise due care for all software and hardware components used in the product. NIST's Secure Software Development Framework, SP 800-218, is published as a core set of high-level secure development practices to integrate into each software lifecycle, which is the right place to write down how you handle third party code.
Step by step
- Unpack the SDK and list every third party library inside, with version and license.
- Compare with what you ship. Many SDKs bundle more than a product uses. Only what lands in your image matters for exposure.
- Check the status of each. Is it current, patched upstream, or end of life?
- Ask the vendor. Request the component list, their patch policy, and their support dates in writing.
- Decide per finding. Update, patch locally, mitigate, or document why it does not apply.
- Record it. Keep the decision and date with the release.
What to ask the SDK vendor
| Question | Why |
|---|---|
| Which third party components are included, with versions? | Starting inventory |
| Do you publish a component list or SBOM? | Saves manual work |
| How do you handle security fixes, and for how long? | Support horizon |
| Can we replace a bundled library with a newer one? | Your options |
| Where do we report problems? | Disclosure path |
When the vendor is slow
Sometimes the SDK is frozen on an old library. Your options are to patch your copy and take on its maintenance, replace the library, isolate the affected feature, or turn it off. Whichever you choose, write down the reason and the review date, because the decision will be questioned later.
Keep a paper trail
A short record per component is enough: name, version, source, owner, last review, current status. That record is what you will reach for when a customer asks about a new advisory.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning, reachability analysis, and policy gates for the source repositories and manifests it supports, and you can run a free scan at gold.safeguard.sh/scan. Check coverage for your build system before relying on it.
Try it yourself
Click through to see how a finding in a library can matter less when your code never calls the affected function.
Click through it at your own pace, or open it full screen.
Quick check
Does using a vendor SDK move liability to the vendor?
Contracts vary, so check yours. For the purposes of security practice, assume you are accountable for what ships in your product.
Should I delete unused SDK libraries?
If they are not needed, removing them from the shipping image reduces what you have to track and patch.
Sources
Last reviewed: 19 October 2026.
