Periodically Test Software Artefacts for Weaknesses
Regularly test software for weaknesses using different analysis tools during its development.
Plain language
Testing software regularly for weaknesses is like checking for holes in a fence that protects your property. If weaknesses are not found and fixed, they could be exploited by cyber criminals, leading to data breaches or system failures.
Framework
ASD Information Security Manual (ISM)
Control effect
Detective
Classifications
NC, OS, P, S, TS
ISM last updated
Mar 2026
Control Stack last updated
24 Mar 2026
E8 maturity levels
N/A
Guideline
Guidelines for software developmentTopic
Software artefactsOfficial control statement
Existing software artefacts in the authoritative source for software are periodically tested to detect known weaknesses using SAST, DAST or SCA, depending on the software artefact type, throughout the software development life cycle.
Why it matters
Neglected software tests allow weaknesses to go unnoticed, potentially leading to breaches or operational disruptions.
Operational notes
Establish a routine for testing your software with a variety of tools; this helps minimise the risk of missing vulnerabilities.
Implementation tips
- IT team should schedule regular testing: Use established tools to test software for vulnerabilities at different stages of development. Set up a calendar reminder to ensure these tests happen consistently.
- Development team should use diverse tools: Different tools might find different issues, so make sure static analysis (checking code), dynamic analysis (running software), and software composition analysis (checking libraries) are all used.
- Manager should allocate resources: Ensure the team has time and budget to use software testing tools throughout development. Prioritise this in your project planning to avoid last-minute rushes.
- Look atreports from each test to see where weaknesses were found and ensure they are fixed promptly. Keep a checklist of actions taken for future reference
- Security officer should ensure compliance: Regularly check that the software is being tested according to Australian Cyber Security Centre (ACSC) guidelines. Use a tracking system to log tests and outcomes.
Audit / evidence tips
- Asktest schedules: Request to see the calendar or schedule for regular software testing Look athow frequently tests are planned and how they are spaced throughout the development process Gooda detailed, recurring schedule showing consistent testing intervals
- Asktest reports: Request recent reports from software testing tools used in the past six months Look atevidence of detected vulnerabilities and subsequent actions taken Goodclear documentation of findings and follow-up actions
- Asktool usage records: Request documentation on what testing tools are employed Look ata variety of tools being used regularly Gooda log showing diverse tools used on different software components
- Askimprovement plans: Request any plans or records showing how test findings are addressed Look atactions executed and improvements made Gooda structured plan with timelines and outcomes outlined
- Askcompliance checks: Request proof of compliance checks with ACSC guidelines Look atrecords that demonstrate conformity with national security standards Gooda compliance checklist with dates and signatures
Cross-framework mappings
How ISM-2102 relates to controls across ISO/IEC 27001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (1) expand_less | ||
| Annex A 8.29 | ISM-2102 requires organisations to periodically test existing software artefacts in the authoritative source to detect known weaknesses u... | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.