Standards and evidence
OWASP, secure development and the evidence behind controls.
Defining application protection scope with OWASP MASVS
MASVS provides a shared requirements framework that extends beyond reverse-engineering resistance.
Read the guideOWASP MASTG: planning mobile security tests
MASTG helps turn security requirements into concrete test questions. Defined packages, device conditions and expected outcomes make reports reproducible.
Read the guideOWASP MASWE: a common language for mobile weaknesses
MASWE provides consistent terminology for mobile weaknesses. Classification still needs the application's actual impact and remediation context.
Read the guideTurning a mobile security checklist into evidence
A checked box does not show that a control works. Connect every item to a design decision, executed test and examined artifact.
Read the guideMASVS-RESILIENCE-1: platform integrity and device signals
Platform-integrity assessment explains which environment signals the application trusts. Review scope, unsupported conditions and false-positive effects together.
Read the guideMASVS-RESILIENCE-2: evidence of application integrity
Writing an integrity requirement and assessing tampering in a final package are separate tasks.
Read the guideMASVS-RESILIENCE-3: measuring resistance to static analysis
Success does not mean making all code invisible. Set realistic objectives around specific assets and the effort required to understand them.
Read the guideMASVS-RESILIENCE-4: resistance to dynamic analysis
Dynamic analysis examines interference with a running application. Blocking one research tool does not establish that the entire business risk is controlled.
Read the guideUsing the OWASP Mobile Top 10
The Mobile Top 10 is a starting point for discussing common risks, not an exhaustive acceptance standard for every application.
Read the guideOWASP ASVS and the mobile back end
A mobile application's back end has its own requirements. ASVS helps assess that layer; client protection does not remove server controls.
Read the guideAPI Security Top 10 and application protection signals
APIs can expose abuse paths independently of the mobile package. Assess object, function and resource-consumption controls alongside client evidence.
Read the guideBuilding scenarios with MITRE ATT&CK Mobile
ATT&CK Mobile helps describe threat behavior. Mapping a technique name to a product feature does not prove effectiveness in an application.
Read the guideClassifying mobile security findings with CWE
CWE provides a shared weakness vocabulary. Classification does not replace an explanation of reachable code and business impact.
Read the guideApplying CVSS v4.0 to mobile findings
CVSS helps describe technical severity consistently. Product priority also depends on data value, reachability and business impact.
Read the guideNIST SSDF: placing RASP in secure development
SSDF addresses security across the development lifecycle. A protection product can contribute a control but does not assume responsibility for source, supply chain or…
Read the guideNIST CSF and application protection governance
CSF connects technical controls with organizational risk management. Evaluate mobile protection through ownership, measurement and improvement plans.
Read the guideSLSA and mobile build provenance
SLSA supports discussion of build and supply-chain trust. Keep source provenance connected to the final protected mobile artifact.
Read the guideSPDX for mobile component and license inventories
SPDX supports sharing component and license information. Matching inventories to final packages makes dependency decisions traceable.
Read the guideVEX: explaining whether a vulnerability affects a product
VEX communicates whether a particular vulnerability affects a particular product. An unaffected statement needs technical reasoning and evidence.
Read the guideMobile application security in a PCI DSS context
A protection SDK is only one part of a payment-data architecture. Assess data flows, scope and operational controls against applicable requirements.
Read the guidePCI MPoC and accepting payments on phones
Phone-based payment acceptance includes monitoring and solution components beyond application code. MPoC assessment cannot be reduced to one RASP feature.
Read the guideDesigning RASP telemetry with KVKK in mind
Mobile security events may contain personal data. Technical design should clarify necessity, access and retention, with legal assessment handled separately.
Read the guideMobile security data in a GDPR context
Telemetry linked to a person or device can raise data-protection questions. Assess fields, purpose, transfers and retention against actual application behavior.
Read the guideISO/IEC 27001 and managing mobile security controls
Control ownership, implementation and evidence matter in an ISO/IEC 27001 context. Buying a protection product does not complete a management system.
Read the guideWhat a SOC 2 report says about a RASP supplier
A SOC 2 report provides information about a defined system and period. Its existence does not mean your mobile application passed an independent security test.
Read the guide