Mobile apps ship their dependencies inside the binary, so a vulnerable library stays on users' devices until they update the app. Scanning for known vulnerabilities is the low-hanging fruit OWASP expects at least.
- Keep an inventory of the libraries and SDKs in each release, ideally as an SBOM.
- Scan dependencies for known vulnerabilities in CI and triage findings by what the app actually uses.
- Update vulnerable components and ship the fix with an app update.
MASTG tests in the local projects
Neither local project runs a MASTG test for MASVS-CODE-3. The guides below explain the platform mechanisms, and the control’s page on mas.owasp.org links the MASTG tests and weaknesses OWASP maps to it.
Closest guides
These guides cover the nearest controls and techniques; use them with the references below.
Triage new dependency vulnerability findings
Turn a weekly batch of Dependabot, OSV-Scanner or npm audit findings into a short list of distinct, shipped, reachable issues, each routed to one outcome: fix, not affected, accept or escalate.
Generate an SBOM for the software you actually release
Define the inventory boundary, compare build and artifact evidence, and connect the resulting SBOM to an immutable release.
Practice
- SBOM completeness lab: Find the dependencies missing from a release SBOM · Browser lab
- Build and verify a signed software release · Local project
Gaps on this site
No guide here covers dependency scanning for mobile build systems such as Gradle, Swift Package Manager or CocoaPods; the dependency guides use server-side ecosystems.
References
List data from the publisher. A guide is listed as the main subject when the weakness or risk is what the guide is about, and as covering it when a dedicated section or worked example addresses it.
Control statements are quoted from OWASP MASVS v2.1.0, licensed CC BY-SA 4.0; the rest is this site's summary. MASTG tests are those the iOS and Android projects here run, with their titles from mas.owasp.org. License.