To keep a forked vendor SDK patched, store the vendor's pristine drop in your repo, keep your edits as a separate patch series, record the vendor version in your SBOM, and subscribe to the vendor's advisories. Review upstream releases on a fixed schedule and merge the ones that touch code you ship.
Why forks fall behind
A chip vendor ships a board support package or SDK. You edit it to fix a driver, add your board, or trim size. A year later the vendor releases a security fix. Your tree no longer matches theirs, so the fix does not apply cleanly, and nobody has time. That is how a known issue stays in shipped devices.
Under the Cyber Resilience Act recitals, manufacturers should check whether a component receives regular security updates and whether it is free from known vulnerabilities (Recital 34). A heavily edited fork is a component whose updates you now have to carry yourself.
A structure that survives staff changes
- Pristine drop first. Commit the vendor's release, unmodified, with the version in the commit message.
- Patches on top. Keep each of your changes as a small, named patch with a reason. Do not mix formatting changes with fixes.
- A change log table.
| File area | Why we changed it | Upstream equivalent? | Owner |
|---|---|---|---|
| Radio driver | Power fix on our board | No | Firmware lead |
| Bootloader glue | Our flash layout | No | Firmware lead |
| TLS config | Disabled old protocol | Partly | Security owner |
- Version in the SBOM. Record the vendor name, version and your patch level. A scanner cannot see this, so add it by hand.
- Advisory intake. Subscribe to the vendor's security notices. Put one named person in charge of reading them.
A review rhythm for a small team
Check for new vendor releases monthly. For each release, ask three questions: does it fix a security issue, does it touch code we ship, does it conflict with our patches? If the answer to the first two is yes, schedule the merge. If a merge is too large, write down why you decided to carry a local fix instead.
Decide when to stop forking
Some edits are worth upstreaming to the vendor. Others are signs the SDK does not fit your product. If most of your tree is patches, consider reducing the footprint by moving to a more actively maintained base, which is a build decision with real cost and should be made deliberately.
Where Safeguard fits
Safeguard's dependency scanning and reachability analysis work on the package ecosystems in your app and backend repositories, helping you separate vulnerabilities in code that is actually called from noise. For vendor SDK source copied into a firmware tree, keep the hand-written record described above.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how calls into a vulnerable function change the priority.
Quick check
Should we rebase our fork onto every vendor release?
Not necessarily. Merge releases that fix issues in code you ship, and record the ones you skip with a reason.
Who owns a CVE in code the vendor wrote but we shipped?
In practice, you are the one who has to get the fix onto your devices. The vendor fixes their code, but your customers run your product. Ask your counsel about formal responsibility.
Sources
Last reviewed: 19 October 2026.
