ASD ISM 0971 Use OWASP standards in web application development
What it says
The OWASP Application Security Verification Standard is used in the development of web applications.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishDevelopers must use OWASP standards for building secure web applications.
Using the OWASP standards in web development means building your websites or online services in a way that protects them from being hacked or misused. If this isn't done, the risk is that attackers could steal sensitive information, damage your reputation, or disrupt your business operations.
Free. Save your status, tasks and notes.
Why it matters
Without using OWASP ASVS, web apps are more exposed to common flaws, leading to data theft and loss of trust.
How to implement
Developers should familiarise themselves with the OWASP standards.
This can be done by visiting the official OWASP website, downloading the documentation, and participating in online training sessions to ensure they understand how to apply these standards.
Project managers should ensure OWASP guidelines are included in project plans.
This involves reviewing project documentation to confirm that security measures align with OWASP's key principles, such as protecting against common web vulnerabilities.
IT leads should integrate OWASP testing into the development lifecycle.
They can achieve this by scheduling regular code reviews and vulnerability assessments that specifically check for OWASP compliance before any software release.
Business owners should prioritise security in their budget.
This means allocating funds to purchase tools or hire experts that help implement and verify OWASP standards during development projects.
Team leaders should hold regular training sessions for developers.
This includes organising workshops where developers practice coding securely and understanding real-world attack prevention based on OWASP guidelines.
Keep it running
Apply OWASP ASVS requirements in design and code reviews, and verify with testing before each release.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The web application development checklist: Request the checklist that was used during development to ensure OWASP standards are followed.
Look at
The specific OWASP principles listed and check if each development task is marked as completed.
Good evidence
A checklist that shows a thorough application of OWASP standards with no unchecked items.
- Check 2 of 5What an auditor asks for
Ask for
The training records on OWASP standards: Request documentation showing when and what OWASP training developers have completed.
Look at
The frequency and content of training sessions listed.
Good evidence
A detailed log showing regular training sessions with all developers attending.
- Check 3 of 5What an auditor asks for
Ask for
Vulnerability assessment reports: Request the reports from any security testing related to OWASP compliance.
Look at
The types of vulnerabilities identified and the actions taken.
Good evidence
Reports showing no major unaddressed OWASP-defined vulnerabilities.
- Check 4 of 5What an auditor asks for
Ask for
To see the project plans with security alignment: Request the project plans referencing OWASP guidelines. Look to see how security checkpoints are integrated into the timeline.
Good evidence
Clearly laid out stages with specific OWASP security goals at each point.
- Check 5 of 5What an auditor asks for
Ask for
Documentation of security incidents: Request records of any security incidents and how they were managed with reference to OWASP guidelines.
Look at
How incidents were identified and resolved in line with OWASP practices.
Good evidence
Detailed incident logs showing effective use of OWASP to prevent reoccurrence.
Mappings
Closest match in ISO/IEC 27001: A.8.25, Secure development lifecycle, which this control partially meets.
ISO/IEC 27001: 5 mappings
This control partially meets A.8.25.
Annex A 8.25 requires defined and consistently applied secure development rules across the lifecycle. ISM-0971 mandates using the OWASP Application Security Verification Standard when developing web applications, which is one way to operationalise secure development requirements. Annex A 8.25 is broader as it applies to all software/systems and does not prescribe a specific standard or only web scope.
This control partially meets A.8.26.
Annex A 8.26 requires organisations to identify, specify and approve security requirements for applications during development or acquisition. ISM-0971 supports this by requiring use of the OWASP Application Security Verification Standard, which provides a concrete baseline and structure for defining and assessing web application security requirements. ISM-0971 is limited to web applications and a particular standard, while Annex A 8.26 is technology-agnostic and includes procurement as well as development.
This control partially meets A.8.27.
ISM-0971 focuses on building web applications to a recognised OWASP verification standard (ASVS). Annex A 8.27 requires secure system architecture and engineering principles to be established and applied to development activities. OWASP ASVS includes architectural and design requirements for web applications, but Annex A 8.27 is broader, applying to all information systems engineering, not only web apps or OWASP-specific criteria.
This control partially meets A.8.28.
Annex A 8.28 requires the application of secure coding principles in software development. ISM-0971 supports this by requiring use of the OWASP ASVS for web applications, which provides detailed secure coding and verification requirements that operationalise secure coding principles. ISM-0971 is scoped to web applications and includes assurance criteria beyond coding, whereas Annex A 8.28 is a general coding practice requirement.
This control partially meets A.8.29.
ISM-0971 requires web applications to be developed against OWASP ASVS, which defines verification requirements and associated testing expectations. Annex A 8.29 requires security testing processes to be defined and implemented in the development life cycle. Implementing OWASP ASVS under ISM-0971 directly strengthens Annex A 8.29 by providing concrete testable controls and acceptance criteria, though Annex A 8.29 also covers broader testing processes beyond web applications.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.