SDL Research
What app teams and device makers publish about security flaws, and what common tools catch
We check what app publishers and connected-device makers publish for the people who find security flaws, and whether the advisory feeds, scanners and SBOMs app teams rely on see what is in their apps. Then we publish where the market falls short, so you can compare your own product. Every finding is dated, gives its sample size where it has one, and links to the full study and its method.
Dependabot has nothing to flag on 10 exploited flaws for native Android and iOS projects
Ten exploited flaws sit in libwebp, WebRTC and four other libraries that app packages bundle. On 25 October 2026, neither OSV.dev nor the GitHub Advisory Database had an advisory for any of the 10 naming a Maven, Swift or Flutter (pub) package, so for a native Android or iOS project, or a Flutter one, no GitHub-reviewed advisory gave Dependabot anything to alert on.
What it means for you: if your app bundles one of these libraries through a third-party package, a quiet Dependabot is not evidence that you are unaffected. The 10 are every entry for those six libraries in CISA’s Known Exploited Vulnerabilities catalogue, a list of flaws known to have been exploited. The study tests the advisory feeds, not whether any app is exposed today.
Evidence under EU law
The EU Cyber Resilience Act requires an SBOM in a product’s technical documentation and a contact address for reporting vulnerabilities from 11 December 2027. Separately, for products placed on the market or put into service after 9 December 2026, the EU’s revised Product Liability Directive keeps a manufacturer liable for damage when a defect is due to a lack of software updates needed to maintain safety, where that is within its control (Directive (EU) 2024/2853, Articles 2(1) and 11(2)(c)).
Dated, sized and sourced
We check what common tools and published pages actually show, and publish where they fall short. How we measure sets out what each figure counts and its limits, and each study explains its own method. Where we find a bug in a tool, we report it upstream.
Cyber Resilience Act readiness
What app publishers publish today for the people who find security flaws in their apps.
-
Only about 1 in 8 small publishers in Europe’s App Store charts publish a way to report a vulnerability
Published 26 September 2026: of the 5,682 reachable app publishers we checked across 30 European App Store storefronts, 5,076 had a measurable result: 12.1% of small publishers publish any way to report a vulnerability, against 49.2% of large publishers, a fourfold gap. The 3 October 2026 run (5,036 publishers with a measurable result) gave 12.1% and 47.9%.
-
Report a flaw to a top-grossing app: we found a stated response time at 14 of 144 publishers
On 25 October 2026, of the 144 publishers behind the top-grossing iPhone apps in the UK, German, French and Dutch App Stores, we found a vulnerability disclosure policy or bug bounty programme for 45, and a stated time for responding to a report for 14.
Connected devices
Whether the makers of smart devices, and the chip makers they depend on, publish what a buyer or a lab will ask for.
-
Found a smart-device flaw? For 306 of 438 apps, we found no published way to report it
On 21 October 2026 we checked the makers’ websites behind 550 connected-device companion apps on Google Play: for 306 of the 438 whose result we could determine (69.9%), we found no published way to report a security flaw. Recognised device brands: 75 of 137 (54.7%) have one; the long tail: 57 of 301 (18.9%).
-
Will your chip maker warn you about a flaw? We found public advisory pages for at least 6 of 40
On 25 October 2026 we checked the 40 chip makers whose microcontrollers, system-on-chips or FPGAs have a port in the open-source Zephyr RTOS: none of the 33 websites we could check offered machine-readable CSAF advisories where the CSAF standard tells tools to look, and at least 6 of the 40 publish a list of security advisories on a web page anyone can read.
-
About 1 in 8 connected-device makers with a UK-facing website publish a PSTI statement of compliance we could find
On 23 October 2026 we checked the websites of 127 connected-device makers with a UK-facing site: of the 117 whose result we could determine, 14 (12.0%) publish a PSTI statement of compliance we could find. It’s a lower bound: as we read the law, the statement must come with the product, not necessarily online.
-
Check your own device: report routes and DMARC for 534 connected-device apps
On 5 October 2026 we scored 534 connected-device apps from their own public listings and websites: whether each publishes a route to report a security flaw, whether its domain has DMARC, and a readiness score. Filter the dataset and every figure recomputes. That run used an earlier version of the route check, so its rates differ from the 21 October figures above.
Vulnerability management
Whether the feeds, scanners and SBOMs app teams rely on actually see what is in their apps.
-
Dependabot has nothing to flag on 10 exploited flaws for native Android and iOS projects
CISA’s Known Exploited Vulnerabilities catalogue lists 10 flaws in six open-source native libraries that third-party packages bring into iOS, Android or React Native app builds; on 25 October 2026, none of the 10 had an advisory in OSV.dev or the GitHub Advisory Database that names a Maven, Swift or Flutter (pub) package.
-
Your mobile SBOM is wrong in three specific ways
- If your iOS app uses CocoaPods, an OSV lookup sees nothing. On our 4 October 2026 sample of 21 CocoaPods components, an OSV-backed vulnerability check covered 0 of 21: OSV.dev has no CocoaPods ecosystem, and the GitHub Advisory Database covers Swift but not CocoaPods. Update, 25 October 2026: at least one free, open-source CRA tool has started checking CocoaPods dependencies through the GitHub Advisory Database’s Swift ecosystem, though pods with no advisory there still show nothing.
- An open-source SBOM generator lists a dependency that doesn’t exist. Reported upstream on 2 October 2026 with a four-line reproduction: the version we tested reads the comment header Gradle writes into every lockfile it generates as a package called
./gradlew, so any Gradle project with dependency locking enabled is affected when scanned with that version. - A correct SBOM can look broken. In our 4 October 2026 sample, the SBOM listed CocoaPods subspecs individually and never a bare GoogleUtilities component, so a coverage check against Podfile.lock reported gaps on an SBOM that was completely correct.
Is your app in scope?
Our free CRA scope checker for app teams answers that in five questions and lists what you’ll need.
Engineering notes, not legal advice.