Skip to content
Software development
ASD ISMISM-1922

ASD ISM 1922 Use OWASP standards in mobile app development

What it says

The OWASP Mobile Application Security Verification Standard is used in the development of mobile applications.

Quoted as published. Everything else on this page is written by Control Stack.

What it means

In plain English

Developers use OWASP standards to enhance security in mobile app creation.

Using OWASP standards in mobile app development means following a set of guidelines created to keep mobile apps safe from hackers and other bad actors. This is important because mobile apps often contain sensitive information like personal data or financial details, and a security breach could lead to data theft, financial loss, or harm to your organisation's reputation.

Why it matters

Failure to apply the OWASP MASVS in mobile app development can leave common flaws exploitable, causing data breaches and loss of user trust.

How to implement

  1. IT managers should ensure developers are familiar with OWASP standards.

    They can do this by organising training sessions or workshops where developers learn about these standards in detail. Encourage the use of OWASP's Mobile Security Testing Guide as a practical resource during these sessions.

  2. Developers should incorporate OWASP standards into their development process.

    They can do this by using checklists from the OWASP Mobile Application Security Verification Standard (MASVS) during app design and coding stages. This helps ensure security is built into the app from the start.

  3. Project managers should require regular security reviews.

    These can be conducted by setting up a timeline for periodic code evaluations against the OWASP Mobile Top Ten security risks. This helps catch potential security issues early.

  4. The quality assurance team should conduct regular security testing.

    They can use tools and techniques mentioned in OWASP's standards to test the app for vulnerabilities before each release. This helps ensure the app is secure before it reaches users.

  5. Management should support ongoing security education.

    This involves providing resources for developers to stay updated on the latest OWASP guidelines and other best practices in mobile security. Continuous learning prevents knowledge gaps that could lead to security oversights.

Keep it running

Apply OWASP MASVS requirements in design, coding and testing; review each release against MASVS and update libraries to address new risks.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Training records: Request documents showing that developers received training on the OWASP standards.

    Look at

    Attendance records and training materials used.

    Good evidence

    Would be a sign-in sheet and a training agenda or slides.

  2. Check 2 of 5What an auditor asks for

    Ask for

    The OWASP checklist: Request the checklist used by developers during app development.

    Look at

    Whether it is comprehensive and includes items relevant to OWASP standards.

    Good evidence

    Would be a completed checklist for each mobile app developed.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Security review schedules: Request a record of planned and past security reviews.

    Look at

    Dates and the scope of reviews to ensure they follow OWASP guidance.

    Good evidence

    Would be a document with regular review entries that align with app updates.

  4. Check 4 of 5What an auditor asks for

    Ask for

    Test results: Request results of security tests based on OWASP standards.

    Look at

    Detailed reports on vulnerabilities found and how each was addressed.

    Good evidence

    Would be a report indicating tests were passed or that issues were fixed.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Evidence of ongoing learning: Request information on how developers keep up-to-date with security practices.

    Look at

    Proof of subscriptions to security bulletins, additional training sessions, or attending relevant conferences.

    Good evidence

    Would be certificates, email subscriptions, or conference flyers.

Mappings

Closest match in ISO/IEC 27001: A.8.25, Secure development lifecycle, which this control partially meets.

ISO 27001

ISO/IEC 27001: 3 mappings

  • A.8.25Secure development lifecyclePartially meets
  • A.8.28Secure coding practices in software developmentPartially meets
  • A.8.29Security testing in development and acceptancePartially overlaps

Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.