Periodically Test Software Artefacts for Weaknesses
Regularly test software for weaknesses using different analysis tools during its development.
🏛️ Framework
ASD Information Security Manual (ISM)
🧭 Control effect
Detective
🔐 Classifications
NC, OS, P, S, TS
🗓️ ISM last updated
Mar 2026
✏️ Control Stack last updated
23 Mar 2026
🎯 E8 maturity levels
N/A
Guideline
Guidelines for software developmentTopic
Software ArtefactsExisting 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.
Source: ASD Information Security Manual (ISM)
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.
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 at: reports 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
-
Ask: test schedules: Request to see the calendar or schedule for regular software testing
Look at: how frequently tests are planned and how they are spaced throughout the development process
Good: a detailed, recurring schedule showing consistent testing intervals
-
Ask: test reports: Request recent reports from software testing tools used in the past six months
Look at: evidence of detected vulnerabilities and subsequent actions taken
Good: clear documentation of findings and follow-up actions
-
Ask: tool usage records: Request documentation on what testing tools are employed
Look at: a variety of tools being used regularly
Good: a log showing diverse tools used on different software components
-
Ask: improvement plans: Request any plans or records showing how test findings are addressed
Look at: actions executed and improvements made
Good: a structured plan with timelines and outcomes outlined
-
Ask: compliance checks: Request proof of compliance checks with ACSC guidelines
Look at: records that demonstrate conformity with national security standards
Good: a compliance checklist with dates and signatures
Cross-framework mappings
How ISM-2102 relates to controls across ISO/IEC 27001, Essential Eight, and ASD ISM.
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| Partially meets (1) | ||
| Annex A 8.29 | ISM-2102 requires organisations to periodically test existing software artefacts in the authoritative source to detect known weaknesses u... | |