ASD ISM 1849 Implement OWASP Top 10 in web development
What it says
The OWASP Top 10 Proactive Controls are 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 EnglishUse OWASP Top 10 controls to secure web applications during development.
When building a website or online service, it is important to use known security practices to protect against common threats. The OWASP Top 10 is a list of the most common web application security risks, and by using it, developers can avoid serious issues like data breaches that could harm customers and damage the company's reputation.
Free. Save your status, tasks and notes.
Why it matters
If OWASP Top 10 Proactive Controls are not implemented, web apps are more likely to ship with common flaws, increasing risk of compromise and data loss.
How to implement
Developers should incorporate secure coding principles: Educate your development team on the OWASP Top 10 and ensure they understand each risk involved.
They can start by attending workshops or reviewing resources and examples on how to avoid these vulnerabilities during coding.
Managers should facilitate regular security check-ins: Schedule meetings with your development and security teams to discuss progress on implementing OWASP recommendations.
Use real-world examples of threats to emphasise the importance and provide clear objectives for incorporating security measures into the development lifecycle.
Quality assurance teams should include security testing in their checklists: Add tests for the top 10 OWASP risks as part of the regular testing process for new application updates.
This can involve using automated scanning tools or manual checks where testers attempt to exploit known issues.
IT teams should establish a secure development environment: Ensure that the development servers and tools are configured to prevent unauthorised access and include security protocols.
For example, make sure that only authorised personnel have access to the code repositories.
Business owners should prioritise security reviews before launch: Before launching any new web application, conduct a final security review that includes an assessment against the OWASP Top 10.
This review can be done by hiring experts or using online tools that offer security assessment services.
Keep it running
Embed OWASP Top 10 Proactive Controls in requirements, code review checklists and CI testing (SAST/DAST), and track remediation of findings each sprint.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
A list of security requirements based on the OWASP Top 10: Request documentation that outlines how each of the top 10 risks is being addressed in the development process.
Look at
Details on specific measures being taken to mitigate these risks.
Good evidence
Is a comprehensive document that maps each OWASP risk to specific controls or practices applied.
- Check 2 of 5What an auditor asks for
Ask for
Developer training records: Check whether the development team has undergone training on OWASP Top 10 risks.
Look at
Certificates or internal training records verifying participation.
Good evidence
Includes recent training records and a plan for ongoing education.
- Check 3 of 5What an auditor asks for
Look at
Evidence of tests being conducted on recent code releases.
Good evidence
Would be a detailed report showing tests performed, findings, and remediation actions taken.
- Check 4 of 5What an auditor asks for
Ask for
Evidence of management involvement in security review meetings.
Look at
Meeting minutes or action points showing discussions of OWASP risks.
Good evidence
Includes regular reviews with clear outcomes on improving web application security.
- Check 5 of 5What an auditor asks for
Good evidence
Is logs showing controlled and monitored accesses, with any irregular access being investigated.
Mappings
Closest match in ISO/IEC 27001: A.8.25, Secure development lifecycle, which this control partially meets.
ISO/IEC 27001: 3 mappings
This control partially meets A.8.25.
Annex A 8.25 requires secure development lifecycle rules to be established and applied. ISM-1849 requires using the OWASP Top 10 Proactive Controls in web application development, providing a concrete set of secure coding/development controls. Annex A 8.25 is broader because it applies to all software and lifecycle phases and does not limit itself to web proactive controls.
This control partially meets A.8.28.
Annex A 8.28 requires secure coding principles to be applied to prevent vulnerabilities in developed software. ISM-1849 supports this by mandating use of the OWASP Top 10 Proactive Controls in web application development, translating secure coding principles into concrete developer actions. ISM-1849 is web-specific and prescriptive, while Annex A 8.28 is broader and principle-based.
This control depends on A.8.26.
ISM-1849 requires the use of OWASP Top 10 Proactive Controls as a practical security baseline during web application development. Annex A 8.26 requires information security requirements to be identified, specified, and approved for applications, and OWASP controls can be used as a source of explicit non-functional security requirements (e.g. access control, data protection, logging). ISM-1849 is one prescriptive set of requirements, whereas Annex A 8.26 is broader and covers the full requirements lifecycle and approval process.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.