Most of your app is code you didn't write. Know what's in it.
A modern mobile app is mostly third-party SDKs, analytics, payment and ad libraries, and the dependencies those bring with them. Mobexa reads the shipped artifact, inventories every component and version it actually contains, and matches each against known vulnerabilities - so a CVE in a library you forgot you bundled is a finding, not a future incident.
Every component, where it lives, and what it drags in
Bundled SDKs & libraries
The third-party code merged into your build, identified by component and version from the artifact itself.
Transitive dependencies
The libraries your libraries brought along - the layer where most undeclared, unpatched risk hides.
Matched advisories
Known CVEs mapped to the exact component and version in your app, with severity and reference.
Native components
Bundled .so libraries and embedded binaries that package managers never see.
Version drift
Outdated components carried release after release, so you can see what is aging inside the app over time.
Release evidence
An exportable record of what shipped, ready to attach to a release or hand to a reviewer.
What a supply-chain view looks like
A sample inventory slice - component, version, where it was found, and the advisory matched against it.
| Component | Version | Origin | Advisory | Severity |
|---|---|---|---|---|
| net-lib | 1.7.0 | transitive | CVE-listed | Critical |
| crypto-util | 0.9.3 | direct | CVE-listed | Medium |
| analytics-sdk | 4.2.1 | direct | none matched | Clear |
| image-loader | 2.0.0 | transitive | none matched | Clear |
| libnative.so | bundled | native | review | Info |
Risk in context, not a list of CVEs
A vulnerable component is not automatically an exploitable app. Mobexa shows where each component sits and how it is reached, so your team can separate a genuine exposure from a dependency that is present but never used on a dangerous path - and spend remediation effort where it changes your risk.
Supply-chain risk, answered plainly
Why does a mobile app need an SBOM if we already track dependencies in our build?
Your build file lists what you intended to include. The shipped artifact contains what actually got bundled - transitive dependencies, SDKs pulled in by other SDKs, and native libraries that never appear in a package manifest. Mobexa builds the inventory from the binary, so it reflects what is really in users' hands, not what your build script believes.
How do you match components to vulnerabilities?
Each identified component and version is matched against known CVE data. A finding tells you the component, the version, the advisory and where it sits in your app, so you can decide whether you are exposed to that specific issue or shielded by how the component is used.
Can you see dependencies the developer did not declare?
That is the point. Composition analysis works from the compiled artifact, so it surfaces the SDKs and libraries that were merged in without ever appearing in a dependency file - exactly the blind spot that supply-chain incidents exploit.
What format does the inventory come in?
A structured, exportable inventory of components, versions, evidence and matched advisories, ready to attach to a release record or hand to a procurement or compliance reviewer who needs to know what is inside the app.
Find out what your app actually ships - dependency by dependency.
Send us a build and we will return its component inventory with matched advisories and supply-chain context.