Yes, they can. A scanner that reads manifests sees what a package manager declares. A prebuilt native library, such as an Android .so file or an iOS binary framework, may carry C or C++ code that no manifest names or versions. You find it by inspecting the built app and recording it by hand.
Why they slip through
Package manager scanning works from declared names and versions. Native code complicates that in three ways:
- A vendor may bundle a library, such as a compression or crypto library, inside its own binary without listing it.
- A
.sofile or framework may be copied into the project directly, with no lockfile entry. - A library name in a binary may not match the name advisories use.
None of this means scanning is useless. It means the list from the package manager is the start of an inventory, not the end.
Where native code lives
On Android, Google's documentation says your app uses native code if it uses C or C++ code, links third-party native libraries or SDKs that use native code, or is built by a third-party app builder using native libraries on device. To check, open the APK in Android Studio's APK Analyzer and look for .so files in the lib folder.
On iOS, binary frameworks and XCFramework packages ship compiled. Swift Package Manager supports binary targets that point to an archive by URL with a checksum, and the checksum applies to the archive, not to the binary inside it.
Steps to bring native code into view
- Build the release artifact and open it with the platform tools.
- List every native library and framework by file name.
- Match each one to a vendor and version, using release notes or the vendor.
- Ask each vendor what open source code is bundled inside, and for an SBOM.
- Add the answers to your inventory.
- Repeat on each release, because a vendor update changes the contents.
unzip -l app-release.apk | grep '\.so$'
What helps and what does not
| Method | Helps with |
|---|---|
| Manifest and lockfile scanning | Declared libraries and their transitive packages |
| Inspecting the built artifact | Finding native files that no manifest lists |
| Vendor SBOMs and questionnaires | What is inside a prebuilt library |
| Binary composition analysis | Identifying code inside binaries, a separate tool category |
Binary composition analysis is a different kind of tooling from manifest scanning. Be clear about which one you have.
Why this matters now
Google's 16 KB page size requirement means many teams are already auditing native libraries in their Android builds. Use that exercise to start a permanent list. See 16 KB page size support.
Quick check
Does an SBOM from my build tool list native libraries?
Only those the build tool knows about. Check the built artifact for the rest.
Who should I ask about bundled code?
The vendor that supplied the library. Ask for an SBOM or a list of bundled components.
Safeguard works from dependency manifests and SBOMs, and SBOMs you supply, and does not do mobile binary analysis. That is why the steps above matter. A free scan covers the declared side.
Sources
Last reviewed: 19 October 2026.
