ASD ISM 2102Periodically 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
18 June 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 testingLook athow frequently tests are planned and how they are spaced throughout the development processGooda detailed, recurring schedule showing consistent testing intervals
- Asktest reports: Request recent reports from software testing tools used in the past six monthsLook atevidence of detected vulnerabilities and subsequent actions takenGoodclear documentation of findings and follow-up actions
- Asktool usage records: Request documentation on what testing tools are employedLook ata variety of tools being used regularlyGooda log showing diverse tools used on different software components
- Askimprovement plans: Request any plans or records showing how test findings are addressedLook atactions executed and improvements madeGooda structured plan with timelines and outcomes outlined
- Askcompliance checks: Request proof of compliance checks with ACSC guidelinesLook atrecords that demonstrate conformity with national security standardsGooda compliance checklist with dates and signatures
Cross-framework mappings
How ISM-2102 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(1)expand_less | ||
| Annex A 8.29 | ISM-2102 necessitates the periodic testing of software artefacts using SAST, DAST, or SCA throughout the SDLC | |
handshakeSupports(1)expand_less | ||
| Annex A 8.30 | ISM-2102 outlines the necessity for periodic software weakness testing using SAST, DAST, and SCA throughout the SDLC | |
ISO 42001
| Control | Notes | Details |
|---|---|---|
sync_altPartially overlaps(1)expand_less | ||
| Annex A 6.2.4 | ISM-2102 requires organisations to periodically test software artefacts using SAST, DAST, and SCA throughout the SDLC to detect known wea... | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in Software development
See all Guidelines for software development controls, or browse the full ASD ISM library.