MASVS-CODE-3 says a mobile app only uses software components without known vulnerabilities. The way to meet it is to inventory every library in each release build, match the list against vulnerability data, and fix or justify what you find. Do it in the build pipeline, not once a year.
What the control covers
The control description is modest on purpose. It acknowledges that a full whitebox assessment of every component is usually not feasible, and says the control covers low-hanging fruit: cases that can be detected "just by scanning libraries for known vulnerabilities".
That is a good framing. You do not need to audit every line of every library. You do need to know what is in the app and whether any of it has a published problem.
Step 1: get the real list
A manifest file lists what you asked for. The build lists what you got. Direct dependencies pull in transitive ones, and some SDKs bundle their own copies of other libraries. Generate the inventory from the built artifact or the resolved dependency graph, and store it as an SBOM for each release.
Ask three questions of each entry: what is it, which version, and who added it.
Step 2: match against known vulnerabilities
Compare each component and version against vulnerability databases. A match is not automatically an emergency. For each one, check:
- Is a fixed version available, and is the upgrade small?
- Does the app actually call the vulnerable code? Reachability analysis helps answer this, and many findings in mobile apps sit in code paths the app never uses.
- Is the issue relevant on a phone? A server-side flaw in a library may not apply in a client app.
Record the decision for each: upgrade, mitigate, or accept with a reason and a review date.
Step 3: put it in the pipeline
- Run the scan on every pull request that changes dependencies.
- Block a release on rules you have agreed in advance, such as no known vulnerabilities of a given severity that are reachable.
- Re-scan old releases when new advisories appear. A build that was clean when it shipped may not be clean now.
- Keep the SBOM with the release record so you can answer which versions were affected when an advisory lands.
Step 4: keep the set small
Every library is future maintenance. Before adding one, ask whether the platform already offers the feature, and whether the library is actively maintained. Remove unused dependencies when you find them. This also helps MASVS-PRIVACY-1, which asks you to be aware of the supply chain of SDKs.
Tie it to forced updates
Finding a vulnerable library in a shipped app is only useful if you can ship a fix and get users onto it. That is where a version gate comes in. See forced updates and minimum OS versions.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning and reachability analysis, and policies and gates that can block a build that breaks your rules. You can try a free scan on a project.
Quick check
Is a clean scan proof the app is secure?
No. CODE-3 covers known vulnerabilities in components. It does not cover flaws in your own code or in unreported library bugs.
How often should I rescan?
On every dependency change, and on a schedule for shipped versions, since new advisories appear after release.
Sources
Last reviewed: 19 October 2026.
