CWE-1103, Use of Platform-Dependent Third Party Components, applies when a product relies on third party components that do not provide equivalent functionality across all the platforms you want to support.
MITRE marks it as a quality issue with no direct security implications and prohibits it for mapping real vulnerabilities.
How it happens
A team picks a library on one platform and it works. Later the product ships elsewhere, and the library has a different feature set, a different version, or no port at all. Workarounds appear, often as platform branches in your own code.
A cryptography or networking library is a typical case. If the Linux build uses one implementation and the Windows build uses another, defaults and supported options may differ without anyone noticing.
What an attacker gains
Nothing directly. MITRE lists reduced maintainability, with the indirect effect of making vulnerabilities harder and slower to find and fix. The security problem is uneven coverage: a flaw may exist in the component on one platform only, and a fix may land on another platform first.
How to find it
The record lists no detection methods. Make a dependency inventory per platform build, and compare them. Differences in component or version are the findings.
How to fix it
- List every third party component for each supported platform.
- Prefer components with equivalent behavior everywhere, or wrap them behind your own interface.
- Test security relevant behavior on each platform.
- Track vulnerabilities per platform build, not only for the main one.
Try it yourself
Build a dependency inventory and see what a scan reports.
Click through it at your own pace, or open it full screen.
You can also run the free in browser dependency scan at gold.safeguard.sh/scan. No login, the file stays on your machine, up to 100 dependencies.
Quick check
Why compare dependency lists per platform?
Different platforms can pull different components or versions, so a vulnerability may affect one build and not another.
