Framework

OWASP MAS Checklist
the per-control row matrix for mobile verification

The OWASP Mobile Application Security (MAS) Checklist is the third deliverable of the OWASP MAS project alongside MASVS (the verification standard) and MASTG (the testing guide). It is the per-control per-test row matrix that turns the standard and the testing guide into an auditable artefact: one row per applicable MASVS control, paired to the MASTG tests that exercised it, recorded per platform with a named result, a finding reference, and a coverage and exclusion note. SecPortal operates a MAS Checklist engagement as one structured record across iOS, Android, and the backend the mobile applications call.

Get Started Free

No credit card required. Free plan available forever.

OWASP MAS Checklist: a per-control verification artefact, not just a chapter list

The OWASP Mobile Application Security (MAS) Checklist is the third deliverable of the OWASP MAS project, alongside MASVS (the verification standard) and MASTG (the testing guide). Where MASVS describes which controls have to be in place and MASTG describes how to test each control, the MAS Checklist is the per-control per-test row matrix that turns the standard and the testing guide into an auditable artefact: one row per applicable MASVS control, paired to the MASTG test identifiers that exercised it, recorded per platform with a named result, a finding reference, and a coverage and exclusion note. The checklist is published by the Open Worldwide Application Security Project, refreshed by the contributing community on GitHub, and is the OWASP MAS project deliverable assessors, auditors, and procurement reviewers read as the per-row verification record.

For internal AppSec teams running a mobile-application verification programme, product security teams owning a mobile feature surface, mobile engineering teams shipping iOS and Android applications, GRC and compliance teams mapping mobile verification to ISO 27001 Annex A, SOC 2, PCI DSS, NIST CSF 2.0, DORA, and NIS2, and CISOs carrying the audit-committee read on the mobile surface, the MAS Checklist is the per-row evidence artefact the mobile verification claim reads through. The value is the row-level traceability that turns mobile verification from a one-off pentest narrative into a durable per-control operating record.

This page covers what each MAS Checklist row carries, how the row relates to a MASVS control identifier and a MASTG test identifier, the per-platform discipline, the verification level applicability, how the row pairs to a workspace finding and a coverage statement, where the MAS Checklist sits next to MASVS, MASTG, the OWASP Mobile Top 10, PCI MPoC, and the internal-AppSec mobile checklists already in use, the buyer and operator read for AppSec, product security, GRC, and CISO functions, and how SecPortal operates a MAS Checklist engagement as one structured record.

What lives on a MAS Checklist row

A MAS Checklist row is not a generic finding entry. It is a per-control per-test record with a fixed column set that lets a reviewer reproduce the test, verify the result, and read the evidence without an evidence-request email. A row that drops any of the columns below is a diagnostic note, not a checklist row.

MASVS control identifier

The named MASVS-v2 requirement the row evidences (for example MASVS-STORAGE-1, MASVS-CRYPTO-2, MASVS-AUTH-3). The control identifier is the link to the OWASP Mobile Application Security Verification Standard and is the column the assessor, the auditor, and the procurement reviewer read first. Rows without a MASVS control identifier are general findings outside the verification claim, not MAS Checklist rows.

MASTG test identifier

The named MASTG test (for example MASTG-TEST-0001 keyboard cache, MASTG-TEST-0033 transport layer protection) that produced the evidence on the row. A row may cite more than one MASTG-TEST identifier when several techniques pair to verify one control; the checklist requires at least one named identifier so the row is reproducible against the OWASP Mobile Application Security Testing Guide.

Platform

iOS, Android, or both. The same MASVS control reads differently across iOS and Android (Keystore vs Keychain, ATS vs Network Security Configuration, intent filters vs URL schemes), so a checklist row is platform-scoped. A row marked both must cite the MASTG-TEST identifiers for both platforms separately rather than collapsing them into one mixed-evidence row.

Verification level applicability

AISVS-style L1, L2, or MASVS-R applicability. The row applies at the declared engagement level when MASVS marks the control as in scope for that level. Rows out of scope at the declared level are still recorded as out-of-scope for traceability, so the report can read both as a verification claim at the declared level and as a diagnostic against a deeper level.

Test result

Pass, fail, partial, deferred, or not-tested. A pass needs evidence; a fail produces a finding on the workspace; a partial reads against the documented deviation; a deferred lands as a finding override with named approver, expiry, and compensating control; a not-tested needs a coverage-statement entry naming why the control was excluded.

Finding record reference

The workspace finding identifier paired with the row when the result is fail, partial, or deferred. The finding carries the CVSS 3.1 vector, the CWE identifier, the OWASP Mobile Top 10 risk category, the evidence (request and response, screenshot, decompiled snippet, runtime hook output, storage path excerpt), and the remediation owner. The pair between the checklist row and the workspace finding is what lets the verification report be a record rather than a frozen PDF.

Evidence pointer

The location of the evidence the row reads against. Evidence lives on the engagement record (finding evidence, code-scan output, authenticated-scan output, bulk-import row, document-management artefact) rather than on a working file the assessor cannot share. The pointer is a workspace path so the reviewer can read the evidence directly without an evidence-request email.

Coverage and exclusion note

A one-line statement naming why a row is partial, deferred, or not-tested. The note is what holds the coverage statement together: programmes that skip the note read the same as programmes that did not exercise the control. A defensible row carries the named reason (typically scope, time, device unavailability, build flavour, or backend dependency) and the named owner.

For the workspace-side mechanics that hold each row to a real engagement record, see the engagement management feature, the findings management feature, and the finding overrides feature, which together carry the structured record each MAS Checklist row pairs against.

Three rows in context: what a defensible MAS Checklist entry looks like

The examples below are illustrative, not prescriptive: they show how a MASVS control identifier, a MASTG test identifier set, a platform scope, a level applicability claim, a result, a finding reference, an evidence pointer, and a coverage note read together as one row. A defensible checklist row carries each column explicitly, regardless of whether the result is pass, fail, partial, deferred, or not-tested.

1MASVS-STORAGE-1: the app does not store sensitive data in shared application storage. MASTG test references MASTG-TEST-0001 (Android internal-private directory check), MASTG-TEST-0002 (Android external storage check), MASTG-TEST-0003 (iOS sandbox container check), and MASTG-TEST-0005 (keyboard cache check). Platform both, with per-platform sub-rows for the platform-specific tests. Level L1 and L2. Result fail on Android (the keyboard cache retained a one-time password during the recovery flow), pass on iOS. Finding reference SEC-1043 carries the CVSS 3.1 vector, the CWE-922 reference, and the screenshot of the cache excerpt. Evidence pointer to the engagement-record finding plus the supporting decompiled snippet under document-management. Coverage note: Android v13 device matrix exercised on Pixel 7 stock build; iOS exercised on iPhone 14 Pro iOS 17.2.
2MASVS-NETWORK-2: the app verifies the digital signature of the TLS certificate against a pinned set. MASTG test references MASTG-TEST-0033 (transport layer protection) and MASTG-TEST-0040 (certificate pinning, when applicable). Platform both. Level L2. Result partial: pinning is implemented for the production backend but the staging backend trusts any-valid-CA; coverage note explains that staging is out of production scope but the divergent posture is recorded so the engineering team can read the gap. Finding reference SEC-1078 evidence the proxy-intercepted handshake and the network security configuration excerpt.
3MASVS-RESILIENCE-1: the app detects whether it is running on a rooted or jailbroken device. Applicable only when MASVS-R is in scope. MASTG test references MASTG-TEST-0050 (root detection bypass) and the matching iOS jailbreak detection test. Platform both. Level R. Result deferred: the engagement scope declared MASVS-L1 without R, so the row is recorded as not-in-scope with the rationale (consumer app, low binary-attack threat model). The deferred record is paired to the engagement-record decision rather than to a finding override, since the row was never in scope.

Verification level applicability: L1, L2, and R on the row record

The MAS Checklist row set scales with the declared MASVS verification level. The level decision is contractual and is named in the rules of engagement; the checklist row set applicable at the declared level is what the verification report and the audit reader read against. Rows out of the declared level are still recorded for traceability, so the report can read both as a verification claim at the declared level and as a diagnostic against a deeper level.

L1: the essential subset

L1 rows in the checklist cover the MASVS-v2 controls flagged for L1 applicability. The L1 row set is the minimum bar a consumer app should pass without additional threat-model justification. L1 rows that fail produce findings the engineering team can address inside the engagement window. L1 rows that pass evidence the consumer-grade verification claim.

L2: defence in depth

L2 rows in the checklist cover the broader MASVS-v2 control set flagged for L2 applicability. The L2 row set is the default for apps handling regulated or financial data: banking apps, healthcare apps, payment apps, and consumer apps whose backend holds regulated data. L2 rows that fail produce findings the engineering team can address inside the engagement window or scope through an override with a named compensating control.

R: resilience layer

R rows in the checklist cover the resilience controls layered on top of L1 or L2 when the threat model includes a motivated attacker willing to spend budget on the binary itself. R rows are scope-additive: they do not replace L1 or L2 rows, they add a resilience claim against the same engagement. R rows that fail produce findings that often pair to compensating controls (backend-side fraud detection, server-side attestation) rather than client-side remediation alone.

For the broader engagement scaffolding (pre-engagement, rules of engagement, scope, authorisation, retest mechanics) the verification level decision sits inside, see the penetration testing scope of work template and the penetration testing methodology guide, which together cover the engagement-side decisions the checklist row set reads against.

Reporting expectations: the checklist alongside the verification report

The MAS Checklist is the row-level audit artefact; the verification report is the narrative artefact. The two are paired deliverables, not alternates: the checklist supplies the per-control traceability the assessor and auditor read against, and the report supplies the executive narrative, the remediation roadmap, and the coverage statement. The expectation list below covers the minimum the paired deliverables need to carry to read defensibly.

Engagement record names the MASVS version, the MAS Checklist commit reference, the in-scope MASTG profiles (static, dynamic, network and backend, resilience), the iOS and Android binaries under test, the backend environment, the device matrix, the testing window, and the agreed retest scope, so the checklist rows are anchored to a versioned project state rather than a moving target.
Checklist row per applicable control at the declared level, plus the out-of-scope rows recorded for traceability. The row carries the MASVS control identifier, the MASTG test identifier set, the platform, the level applicability, the result, the finding record reference, the evidence pointer, and the coverage and exclusion note.
Findings on the engagement record carry a CVSS 3.1 vector, severity, evidence inline (request and response, screenshot, runtime hook output, decompiled snippet, storage path excerpt), owner, the OWASP Mobile Top 10 risk category, the CWE identifier, and a free-text mapping field for the MASVS control the finding evidences. The pair between the checklist row and the workspace finding is read both directions.
Coverage statement summarises which MASVS chapters were exercised, which were partially exercised, and which were not exercised, with a one-sentence reason per partial or excluded chapter (typically scope, time, device unavailability, or backend dependency). The coverage statement is the row-aggregate read of the per-row coverage and exclusion notes.
Verification level claim is declared up front (MASVS-L1, MASVS-L2, with or without MASVS-R) and reflected on every page of the verification report. The checklist row set matches the declared level; rows out of the declared level are present for traceability and labelled as such.
Retest scope agreed at kickoff (the retest count, the retest window, the verification method per finding) so the closure record can carry verified-fixed status on the same checklist row without renegotiation. Each retest cites the same MASVS control identifier and MASTG test identifier the original row carried.
Closure record covers the original finding, the proposed fix, the retest evidence on a clean device build, and the final outcome, so the verification claim is a record rather than a frozen PDF. The closure record updates the checklist row to verified-fixed and carries the link to the retest evidence on the engagement record.
Activity log captures every state change on the engagement, the findings, the override decisions, and the retests, with CSV export, so the auditor or regulator can reconstruct the row-by-row verification operating record without a multi-team excavation.

For deeper context on how to structure the narrative report alongside the checklist, see how to write a pentest report and the matching penetration testing report template. The AI report generation feature composes the executive summary, the technical body, the coverage statement, and the remediation roadmap from the underlying engagement, findings, and checklist row set, citing the MASVS controls and the MASTG tests that were exercised rather than starting from a blank template.

Recurring failure modes that weaken a MAS Checklist record

Programmes that struggle with the MAS Checklist typically hit a small set of recurring failure modes. Naming the failure modes up front lets the engagement design controls to avoid them rather than discovering them during the report review or the buyer-side comparison.

Treating the checklist as a chapter cover sheet. Rows that read at the chapter level (for example one row per MASVS-STORAGE without per-test identifiers) hide the depth the verification claim was supposed to evidence. A defensible checklist row pairs one MASVS control identifier with at least one MASTG test identifier, so a reviewer can reproduce the test rather than rely on chapter-level assertion.

Collapsing iOS and Android into one row. The two platforms expose different APIs, different signing chains, different network policy surfaces, and different storage primitives, so a row marked both with one MASTG-TEST identifier almost always evidences only one platform. Split the row per platform when both are in scope, even if the result is identical, so the evidence trail reads against the platform-specific test.

Letting partial pass quietly. A partial result without an explicit coverage and exclusion note reads as a pass to most readers and reads as a fail to a careful one. Programmes that skip the note ship an unstable verification claim. Either decide the row is pass with named limit, fail with named scope, or deferred with named override, and write the one-line reason on the same row.

Citing deferred without an override record. A deferred row that is not paired to a finding override (named approver, scope, expiry, compensating control, refresh trigger) reads as a silent risk acceptance. The finding overrides record is what holds the deferred row to a closure decision rather than a permanent unverified gap.

Skipping the resilience scope decision. MASVS-R is optional and the resilience rows in the checklist only apply when the engagement scope declares R. A checklist that includes resilience rows without R in scope reads inconsistently against the verification claim; a checklist that excludes resilience rows when R is in scope under-reports the engagement. Decide R inclusion at kickoff and reflect it on every row.

Treating the checklist as the deliverable rather than a record. The MAS Checklist is the audit artefact that pairs against the verification report; it is not the report itself. Programmes that ship the checklist alone lose the executive narrative and the remediation roadmap; programmes that ship the report alone lose the per-control traceability the assessor and auditor read against. The two are paired deliverables, not alternates.

Drifting from the live OWASP project version. The OWASP MAS project (MASVS, MASTG, MAS Checklist) is refreshed by the community on GitHub. Checklists pinned to an outdated MASVS v1 chapter map read incompatibly against MASVS v2-aligned engagements and against newer MAS Checklist row identifiers. Declare the MASVS version and the MAS Checklist commit reference up front, and refresh the row identifiers when the engagement reads across versions.

Mixing scanner output into the same row as the manual test. Mobile scanner output (MobSF, AndroBugs, QARK, Drozer, Needle, Objection runtime hooks, Frida sessions) is finding data, not a methodology. A row that cites MASTG-TEST-0001 with no clear distinction between automated scanner detection and manual reproduction reads inconsistently against a peer review. Cite the source of the evidence per row so the reproducibility is honest.

How the MAS Checklist sits next to MASVS, MASTG, the Mobile Top 10, PCI MPoC, and internal AppSec checklists

The MAS Checklist is rarely used in isolation. It is the row-level evidence artefact that the other OWASP MAS deliverables, the PCI mobile regimes, and the internal AppSec mobile checklists read into. The contrast below is a working view, not a buyer comparison: the practitioner question is which artefacts to pair the MAS Checklist with, not which to pick instead of it.

MAS Checklist vs MASVS

MASVS is the verification standard: it defines, control by control, what a verified secure mobile application looks like. The MAS Checklist is the per-control per-test row matrix that turns MASVS into an auditable spreadsheet-style artefact. MASVS answers what is verified; the MAS Checklist answers, row by row, whether each MASVS control was tested, by which MASTG technique, on which platform, with what result, and against what evidence.

MAS Checklist vs MASTG

MASTG is the testing guide: it describes how to verify each MASVS control with concrete tests, tooling, and platform notes (the MASTG-TEST identifiers, the static, dynamic, network and backend, and resilience profiles). The MAS Checklist is the deliverable that pairs each MASVS control to the MASTG tests that exercised it and records the result. MASTG answers how the test is done; the MAS Checklist answers what the test produced.

MAS Checklist vs OWASP Mobile Top 10

The OWASP Mobile Top 10 is the ranked list of common mobile risks, refreshed periodically. The MAS Checklist is a verification artefact that covers the broader MASVS requirement set at the declared level. A pentest scoped to the Mobile Top 10 covers headline risks; a MAS Checklist engagement covers the requirement set and produces an auditable row-by-row record. Strong engagements cite both: the Mobile Top 10 risk category on each finding, and the MASVS control identifier plus the MASTG test identifier on each checklist row.

MAS Checklist vs PCI MPoC and PSD2 SCA

PCI MPoC (Mobile Payments on COTS) is the payment-industry standard for mobile payment applications, operationalised through accredited assessor labs. PSD2 SCA is the EU regulatory expectation for payment-initiating mobile applications. The MAS Checklist is the technical evidence artefact assessor labs and regulators read alongside, because it converts the MASVS-aligned engagement into a row-level record that maps to PCI MPoC sub-control evidence and to the PSD2 SCA technical implementation evidence without rerunning the test.

MAS Checklist vs internal-AppSec mobile checklists

Many AppSec teams maintain an internal mobile-security checklist that captures the team-specific bar (the platform versions supported, the SDK inventory, the CI/CD hygiene rules, the threat model). The MAS Checklist sits underneath as the external reference checklist that maps to the OWASP MAS project, so the internal checklist can be cross-walked to a portable artefact other readers (regulators, customers, audit committees) understand without a team-by-team translation.

MAS Checklist vs scanner output dashboards

Mobile scanner output dashboards (MobSF, AndroBugs, QARK, Drozer, Needle) are useful as scanner-source views of finding data, but they are not verification artefacts. They do not enumerate controls, they enumerate detections; they do not pair to MASVS identifiers, they pair to detector names. The MAS Checklist is the verification artefact that converts the scanner data plus the manual test data plus the backend test data into one per-control row record, so the verification claim reads against the OWASP project rather than the scanner brand.

Buyers procuring a mobile verification engagement under a regulated framework should pair the MAS Checklist row record with OWASP ASVS for the wider backend tier of the same product, with the OWASP API Security Top 10 for the API surface the mobile app calls, with PTES or NIST SP 800-115 as the engagement-level methodology, and with ISO 27001 Annex A.8.8 and A.8.29 when the verification feeds an ISMS audit.

Adjacent OWASP, CISA, and regulator references

The MAS Checklist reads alongside several OWASP, CISA, and regulator references. Each one covers a different slice of the mobile-security operating model; the checklist is the per-row evidence artefact that converts the standards and regulations into a verifiable record.

MAS Checklist and the OWASP MAS project

The MAS Checklist is the third deliverable of the OWASP MAS project, alongside MASVS (the verification standard) and MASTG (the testing guide). The three documents are versioned together and refreshed by the community on GitHub; engagements cite the MASVS version, the MASTG version, and the MAS Checklist commit reference together so the verification claim is reproducible against a versioned project state.

MAS Checklist and CISA Secure by Design

CISA Secure by Design is the voluntary pledge framework for software producers committing to default-secure software products. Mobile product teams committing to Secure by Design read the MAS Checklist as the per-control evidence layer that backs the mobile-side commitment, because the checklist is the row-level artefact that turns a default-secure claim into an auditable record.

MAS Checklist and NIST SSDF

NIST SSDF (Secure Software Development Framework, SP 800-218) is the secure-development practices framework. The Verify practice category (PW.7 verify configuration, PW.8 reuse software securely, PS.3 verify intentional behaviour) expects a documented verification methodology for the mobile products a software producer ships. The MAS Checklist is the mobile-side row-level artefact programmes cite to satisfy the SSDF Verify practice expectation on mobile applications.

MAS Checklist and the EU Cyber Resilience Act

The EU Cyber Resilience Act (CRA) is the EU product cybersecurity regulation for products with digital elements, including mobile applications and embedded mobile-adjacent systems. The MAS Checklist reads as the technical verification artefact for the mobile-product surface under CRA, because the regulation expects documented vulnerability handling and security verification on each product release.

How auditors and regulators read a MAS Checklist citation

The MAS Checklist is not itself a regulator-issued standard; it is the open mobile verification artefact that regulator-issued standards, certification schemes, and procurement frameworks accept as the per-control evidence record for mobile applications. The list below maps the checklist row record to the regulator-side and audit-side references that read against it; the same engagement record satisfies several reads at once when the row coverage is honest.

ISO 27001 Annex A.8.8 (Management of technical vulnerabilities): the MAS Checklist supplies the per-control verification record the auditor reads when the ISMS scope includes a mobile application, because each row carries the named control, the named test, and the named result.
ISO 27001 Annex A.8.29 (Security testing in development and acceptance): the MAS Checklist row set is the per-release verification artefact the auditor reads to evidence that security testing was performed against a recognised standard before each acceptance gate.
SOC 2 Trust Services Criteria CC7.1 (Detection and monitoring) and CC7.2 (Incident response evaluation): the MAS Checklist row pair to the workspace findings supplies the verification-side detection evidence the SOC 2 auditor reads on the mobile-application sub-system.
PCI DSS Requirement 6.2 (Custom and bespoke software developed securely) and Requirement 11.3 (External vulnerability scans, internal vulnerability scans, penetration testing): the MAS Checklist row record on a payment-adjacent mobile application supplies the technical verification evidence the QSA reads against the Requirement 6 and Requirement 11 obligations.
PCI MPoC (Mobile Payments on COTS): assessor labs reading MPoC submissions accept the MASVS verification record (with the MAS Checklist row set as the per-control evidence) as the application-side technical evidence the standard depends on, when the engagement scope and the device matrix match the MPoC expectations.
HIPAA Security Rule technical safeguards (164.312): the MAS Checklist row record for a healthcare mobile application supplies the verification evidence the auditor reads against the access control, audit control, integrity, and transmission security implementation standards.
NIST CSF 2.0 PR.PS (Platform security) and PR.IR (Technology infrastructure resilience): the MAS Checklist is the mobile-side row record that evidences the platform-security and resilience outcomes the framework expects at the technical layer.
NIST SP 800-53 Rev 5 SA-11 (Developer testing and evaluation) and CA-8 (Penetration testing): the MAS Checklist row record is the per-control evidence the assessor reads to evidence SA-11 and CA-8 against the mobile application surface.
DORA Article 9 (ICT security policies) and Article 17 (Incident management): the MAS Checklist row record on a banking or payment mobile application supplies the per-control verification evidence the supervisory authority reads against the ICT security expectations.
NIS2 Article 21 (Cybersecurity risk-management measures): the MAS Checklist row record supplies the technical-control verification evidence the competent authority reads against the risk-management measures obligation for essential and important entity mobile applications.

For the broader audit-evidence story (how the same finding can satisfy multiple regulator reads without rebuilding the evidence pack per audit), see the vulnerability evidence reuse across audits research and the audit evidence half-life research.

The MAS Checklist read across mobile-shipping functions

The MAS Checklist is a cross-functional artefact. The same row record reads differently depending on which function holds the work. Programmes that run mobile verification as an engineering exercise alone lose the audit depth the checklist supports; programmes that run it as a procurement exercise alone lose the engineering depth. The named functions below own different parts of the same row record.

AppSec teams running mobile verification internally

AppSec teams use the MAS Checklist as the internal bar the mobile engineering team builds against, and as the structure that triages findings from SAST, SCA, dynamic mobile testing, and bulk-imported scanner output into one comparable per-control record. The team owns the engagement workspace, the MASVS version pin, the checklist commit reference, and the per-release retest scope; the engineering team owns the row-level remediation.

Product security teams operating mobile-product release gates

Product security teams use the MAS Checklist as the per-release verification gate before a mobile application ships, with the verification level claim (L1, L2, or L2 plus R) named on each release. The team reads the checklist row set as the evidence the release decision is anchored in, and the deferred rows are paired to finding overrides with named expiry so a release does not silently inherit unresolved verification gaps.

GRC and compliance teams reading mobile verification evidence

GRC and compliance teams use the MAS Checklist as the per-control evidence artefact that reads against ISO 27001 Annex A.8.8 and A.8.29, SOC 2 CC7.1, PCI DSS Requirement 6 and 11, PCI MPoC, HIPAA technical safeguards, NIST CSF 2.0, NIST SP 800-53, DORA Article 9, and NIS2 Article 21. The team consumes the row-level record on the workspace rather than rebuilding the evidence pack per audit.

CISOs and security leaders carrying the mobile-risk read

CISOs and security leaders use the MAS Checklist as the durable, version-anchored evidence layer that the mobile-risk read to the audit committee reads against. The leader-side question is no longer how many findings were on the report, it is which MASVS controls passed at which level, which were deferred with named compensating control, and which were excluded from scope and why. The checklist row record is the answer.

Mobile security consultancies running MAS Checklist engagements

Mobile security consultancies and the wider security consultancies that own mobile testing as one of several practices use the MAS Checklist as the deliverable that converts a mobile pentest into a verifiable artefact comparable across engagements and providers. The workspace carries the engagement, the checklist row record, and the branded client portal so the buyer reads the live record rather than a frozen PDF.

The persona-specific entry points are SecPortal for AppSec teams, SecPortal for product security teams, SecPortal for application security programme leads, SecPortal for GRC and compliance teams, and SecPortal for mobile security consultancies. Each anchors a different view of the same MAS Checklist engagement record.

Running a MAS Checklist engagement on SecPortal

SecPortal is the operating record for a MAS Checklist engagement. The engagement record captures the MASVS version, the MAS Checklist commit reference, the verification level claim, the in-scope MASTG profiles, the device matrix, the testing window, and the retest scope. The findings record carries each mobile finding with the MASVS control identifier, the MASTG test identifier, the OWASP Mobile Top 10 risk category, the CWE identifier, the CVSS 3.1 vector, and the evidence the test produced, so the per-row checklist record reads against the same workspace state the verification report reads against. The platform alignment below maps each verified SecPortal capability to the MAS Checklist column or evidence type it supports so the engagement is held on one operating record rather than reconstructed at report time.

Engagement management captures the MASVS version, the MAS Checklist commit reference, the verification level claim, the in-scope MASTG profiles, the iOS bundle identifier and Android package name, the build versions tested, the device matrix, the backend environment in scope, the testing window, and the agreed retest scope as one structured record so every checklist row reads against the same engagement scaffold rather than a contract attachment.
Findings management stores each finding paired to a checklist row with a CVSS 3.1 vector, severity, evidence inline, owner, the OWASP Mobile Top 10 risk category, the CWE identifier, and a free-text mapping field for the MASVS control identifier and the MASTG test identifier the row cites, so the verification report and the checklist read against the same per-row record.
Authenticated scanning runs DAST modules against the backend the mobile app calls on the same engagement record, with credentials stored encrypted at rest under AES-256-GCM, so MASVS-AUTH and MASVS-NETWORK rows on the checklist read against device-side and API-side evidence on the same record.
Code scanning runs SAST and SCA against the mobile codebase via the Git provider connection (GitHub, GitLab, Bitbucket), so MASVS-CODE rows on the checklist (dependency hygiene, hardening flags, secrets in CI/CD) read against the same engagement as the runtime testing.
Bulk finding import accepts mobile scanner output (MobSF, AndroBugs, QARK, Drozer for Android; Needle, Objection-based runtime checks for iOS) as CSV intake with column mapping, so scanner-produced rows land on the engagement ledger and pair to the checklist row that cites the relevant MASTG test reference, rather than living in a separate working file.
AI-assisted reports compose the executive summary, the technical body, the coverage statement, and the remediation roadmap from the live engagement, findings, and checklist row set, citing the MASVS controls and the MASTG tests that were exercised rather than starting from a blank template.
Document management holds the externally produced artefacts the platform does not generate inline (decompilation output, runtime hook session output, platform-specific compliance forms, MAS Checklist YAML or CSV export), with version history per artefact and named custodian per file, so the row-level evidence pointers land on durable storage rather than email attachments.
Compliance tracking lets one MAS Checklist run feed framework mappings to ISO 27001 Annex A.8.8 technical vulnerability management, SOC 2 Trust Services Criteria CC7.1 and CC7.2, PCI DSS Requirement 4 and Requirement 6 for the mobile-banking surface, and HIPAA technical safeguard evidence, without rebuilding the bundle per audit.
Retesting workflows pair each finding to a verification step on a clean device build, with the retest evidence carrying the same MASVS control identifier and MASTG test identifier the original row cited, so the closure record updates the checklist row directly.
Activity log with CSV export captures every state change on the engagement, the findings, the override decisions, and the retests, so the auditor or regulator can reconstruct the row-by-row verification operating record without a multi-team excavation.
Team management with role-based access keeps AppSec, mobile engineering, product security, security operations leaders, GRC and compliance, and the engaged mobile security firm on the same workspace with appropriate scoping per surface.
Multi-factor authentication enforcement at workspace level for the MAS Checklist operating records, so the identity assurance applies at access time as well as evidence time.
Finding overrides hold the deferred rows on the checklist with a named approver, named scope, cited reason, hard expiry, compensating control, and refresh trigger, so a deferred row is evidenced rather than silent.

Honest scope: what SecPortal does not do

The MAS Checklist work runs across multiple specialist tools and roles the SecPortal product does not replicate inline. The honest scope below names the boundaries so the engagement record reads against the verified product surface and the externally produced artefacts attach through document management rather than implying the platform performs analysis it does not perform.

SecPortal does not run a mobile binary scanner directly. The platform does not embed MobSF, AndroBugs, QARK, Drozer, Needle, Objection runtime hooks, Frida sessions, or any other mobile-specific binary or runtime analysis tool. The scanner-side evidence on the checklist rows is produced where the mobile testers run those tools and lands on the engagement record through bulk finding import as CSV intake with column mapping.
SecPortal does not host an Android or iOS device matrix. The device matrix (real or virtualised devices, the OS versions, the build flavours, the jailbroken or rooted devices) is run where the engagement testers run it. The platform captures the named device matrix in the engagement record so the row coverage statement reads against the device-side scope.
SecPortal does not operate a decompiler or runtime instrumentation framework. The decompiled snippets, the Frida hook output, the Objection runtime trace, the Burp Suite mobile traffic capture, the smali or DEX file excerpts land on the engagement record as document-management artefacts produced by the testers running those tools.
SecPortal does not replace the OWASP MAS project. The MASVS standard, the MASTG testing guide, and the MAS Checklist row matrix are maintained by the OWASP MAS project community on GitHub. SecPortal is the operating layer that runs an engagement against a versioned snapshot of the project, with the row record paired to the workspace findings and evidence.
SecPortal does not issue MASVS or MAS Checklist verification certificates. Verification claims at L1, L2, or L2 plus R are made by the engagement team and reviewed by the buyer; SecPortal supplies the operating record the claim is anchored in, not the certificate.
SecPortal does not ship packaged connectors into Jira, ServiceNow, Slack, Microsoft Teams, SIEM, SOAR, GRC platforms, MDM (Mobile Device Management), or EMM (Enterprise Mobility Management). The MAS Checklist findings live on the SecPortal workspace and the wider operational ticketing and device-management remain in the systems where the rest of the work is tracked.
SecPortal does not host, sign, distribute, or attest mobile binaries. The application binary is produced and signed in the CI/CD pipeline of the mobile engineering team; SecPortal captures the binary identifier (the iOS bundle identifier, the Android package name, the build version) on the engagement record as metadata, not as a hosted artefact.
SecPortal is not an MDM, an EMM, a mobile threat defence (MTD) platform, an app reputation service, or an app attestation service. The runtime mobile-security posture across a fleet is operated by the MDM, EMM, and MTD layers in place; SecPortal records the per-build verification evidence the MAS Checklist row record needs, not the per-device runtime posture.

The operational workstreams the MAS Checklist programme reads against already exist as named use cases on SecPortal. The security onboarding for new applications workflow covers the per-application onboarding the MAS Checklist engagement attaches to. The code review use case covers the SAST and SCA evidence the MASVS-CODE rows read against. The retesting use case covers the retest mechanics that pair each retest back to the original MASTG test identifier on the same row. The cross-framework control mapping workflow reads the same checklist row record across ISO 27001, SOC 2, PCI DSS, PCI MPoC, HIPAA, NIST CSF 2.0, NIST SP 800-53, DORA, and NIS2 so the cross-regime read is reconcilable rather than reconciled per audit.

Key control areas

SecPortal helps you track and manage compliance across these domains.

Column 1: MASVS control identifier

Each row anchors to a named MASVS-v2 requirement (MASVS-STORAGE-1, MASVS-CRYPTO-2, MASVS-AUTH-3, MASVS-NETWORK-2, MASVS-PLATFORM-1, MASVS-CODE-1, MASVS-RESILIENCE-1, MASVS-PRIVACY-1). The control identifier is the link to the standard and is what the assessor, the auditor, and the procurement reviewer read first.

Column 2: MASTG test identifier

Each row cites at least one MASTG-TEST identifier (for example MASTG-TEST-0001 keyboard cache check on Android, MASTG-TEST-0033 transport layer protection, MASTG-TEST-0050 root detection bypass when MASVS-R applies). A row may carry several MASTG-TEST citations when techniques pair to verify one control; rows without a named identifier are not checklist rows.

Column 3: Platform scope

iOS, Android, or both. Platform-collapsed rows hide the platform-specific evidence; defensible rows split per platform when both are in scope, even if the result is identical. The MASTG test identifier is platform-specific in most cases (Android internal-private directory vs iOS sandbox container, ATS vs Network Security Configuration, intent filters vs URL schemes).

Column 4: Verification level applicability

L1, L2, or MASVS-R. The row applies at the declared engagement level when MASVS marks the control as in scope for that level. Out-of-scope rows are recorded for traceability so the report can read both as a verification claim at the declared level and as a diagnostic against a deeper level.

Column 5: Test result

Pass, fail, partial, deferred, or not-tested. A pass needs evidence; a fail produces a workspace finding; a partial reads against a documented deviation; a deferred lands as a finding override with named approver, expiry, and compensating control; a not-tested needs a coverage-statement entry naming why the control was excluded.

Column 6: Finding record reference

The workspace finding identifier paired with the row when the result is fail, partial, or deferred. The finding carries the CVSS 3.1 vector, the CWE identifier, the OWASP Mobile Top 10 risk category, the evidence inline, and the remediation owner. The pair between the row and the finding is what lets the verification report be a record rather than a frozen PDF.

Column 7: Evidence pointer

A workspace path to the evidence the row reads against (finding evidence, code-scan output, authenticated-scan output, bulk-import row, document-management artefact). Evidence pointers replace evidence-request emails and let the reviewer reproduce the result directly.

Column 8: Coverage and exclusion note

A one-line statement naming why a row is partial, deferred, or not-tested, with the named owner. The coverage and exclusion notes aggregate into the report-level coverage statement, which is what makes the verification claim defensible against a careful read.

Related features

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

Finding overrides that survive every scan cycle

Test web apps behind the login

Find vulnerabilities before they ship

Bulk finding import bring your scanner data with you

Document management for every security engagement

AI-powered reports in seconds, not days

Compliance tracking without a full GRC platform

Verify fixes and track reopens on the same finding record

Every action recorded across the workspace

Collaborate across your entire team

Multi-factor authentication on every workspace

Run a MAS Checklist engagement on one workspace

Anchor each row to a MASVS control identifier, a MASTG test identifier, a platform scope, a level claim, a result, a finding reference, an evidence pointer, and a coverage note. Carry the row record across ISO 27001, SOC 2, PCI DSS, PCI MPoC, HIPAA, NIST CSF 2.0, DORA, and NIS2 without rebuilding the evidence pack per audit. Start free.