Comprehensive Software Vulnerability Testing
Software undergoes thorough vulnerability testing both before and after release to spot undiscovered security issues.
Plain language
Testing software for vulnerabilities means checking it for weaknesses that hackers could exploit before it goes out into the world and regularly after that. If this isn't done, there could be serious risks like data breaches that can harm your business's reputation and cost a lot of money.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
May 2025
Control Stack last updated
19 Mar 2026
E8 maturity levels
N/A
Guideline
Guidelines for software developmentOfficial control statement
Software is comprehensively tested for vulnerabilities, using SAST, DAST and SCA prior to its initial release, any subsequent releases and periodically in order to attempt to identify any previously unidentified vulnerabilities.
Why it matters
Without comprehensive SAST, DAST and SCA before each release, exploitable flaws may ship to production, leading to breaches, outages and costly remediation.
Operational notes
Run SAST, DAST and SCA pre-release and on each subsequent release; schedule periodic scans post-release and triage findings into patches and retesting.
Implementation tips
- The IT team should schedule regular vulnerability testing on all software before any release. This involves setting up automatic tests that look for security flaws and running them on every update.
- Managers should ensure the use of Static Application Security Testing (SAST) tools to find vulnerabilities in the software’s code during its development stage. Arrange for regular training sessions to keep the team updated about these tools.
- Procurement officers should require suppliers to provide evidence of software vulnerability testing as part of the contract agreements. This can be done by asking for past testing records or certifications before purchasing any software.
- System owners should work with security specialists to conduct Dynamic Application Security Testing (DAST) after the system is operational to find vulnerabilities under real-world conditions. This can be done by simulating scenarios where the software is attacked.
- The IT team should perform Software Composition Analysis (SCA) to identify vulnerabilities in third-party components that make up the software. Conduct this analysis periodically to ensure new vulnerabilities are not overlooked as components update.
Audit / evidence tips
- AskVulnerability testing reports before any software release. Check these reports for details on the types of tests conducted and their outcomes GoodIs a comprehensive report indicating all identified vulnerabilities were addressed
- GoodIs a documented plan with clear dates indicating previous and upcoming vulnerability tests
- AskHow often they run these tools during development GoodIs staff showing confidence in using these tools and providing routine examples of detected vulnerabilities
- GoodIs the completion of testing cycles with recorded results pointing to fixed vulnerabilities
- GoodIs documentation listing all third-party components with notes on vulnerability status and resolution
Cross-framework mappings
How ISM-0402 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (2) expand_less | ||
| Annex A 8.25 | ISM-0402 requires comprehensive vulnerability testing (including SAST, DAST and SCA) prior to release and periodically thereafter | |
| Annex A 8.29 | ISM-0402 requires comprehensive software vulnerability testing using SAST, DAST and SCA before initial release, subsequent releases, and ... | |
| handshake Supports (2) expand_less | ||
| Annex A 8.28 | Annex A 8.28 requires secure coding principles to be applied to prevent vulnerabilities during software development | |
| Annex A 8.30 | ISM-0402 requires comprehensive vulnerability testing (SAST, DAST, SCA) before release and periodically to identify previously unknown vu... | |
E8
| Control | Notes | Details |
|---|---|---|
| handshake Supports (1) expand_less | ||
| E8-PA-ML1.2 | E8-PA-ML1.2 requires that organisations use a vulnerability scanner with an up-to-date vulnerability database for vulnerability scanning ... | |
ISO 42001
| Control | Notes | Details |
|---|---|---|
| sync_alt Partially overlaps (1) expand_less | ||
| Annex A 6.2.4 | Annex A 6.2.4 requires documented AI system verification and validation measures and criteria for their use | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.