Test Software Artefacts for Security Weaknesses
All software is tested for security issues before being added to the official software source.
Plain language
Before any software is officially used within our organisation, it's tested to catch any weaknesses that hackers might exploit. This matters because using software with hidden security flaws can lead to data breaches, financial loss, and reputation damage.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
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
All software artefacts are tested to detect known weaknesses using static application security testing (SAST), dynamic application security testing (DAST) or software composition analysis (SCA), depending on the software artefact type, before being imported into the authoritative source for software.
Why it matters
If we skip these tests, vulnerabilities in software could lead to costly data breaches, damaging the organisation's reputation and finances.
Operational notes
Regularly update testing tools and methodologies to keep up with emerging threats and ensure comprehensive software security evaluations.
Implementation tips
- Business owners should engage with a qualified IT specialist to ensure third-party software is checked for security flaws. The IT specialist can perform these checks known as static, dynamic, and composition tests using specific tools designed to identify vulnerabilities in software.
- Procurement teams should mandate security testing as part of the vendor selection process. They can include specific clauses in contracts that require vendors to provide evidence of security testing before any software is accepted.
- IT teams should schedule regular security testing at different stages of the software’s use. This means testing software not just when it's first brought in, but periodically after updates or changes, using the same security testing methods.
- Managers should set up a process to document all security test results. They can implement a system where each software’s test results and history are logged and reviewed regularly for compliance with the organisation’s security policies.
- HR teams should facilitate training for relevant staff on the importance of security testing software. They can organise workshops that explain the risks associated with untested software and outline the processes for ensuring software is secure.
Audit / evidence tips
- AskThe records of third-party software approvals: Request documentation that shows security testing was conducted before software was used GoodIs up-to-date records clearly showing software was tested and approved
- GoodIncludes a consistent schedule that covers all third-party software
- AskTest results from static, dynamic, and composition tests: Review the results for any noted issues and actions taken GoodIs a comprehensive report with no outstanding security issues
- GoodIncludes a matching list of software and test records
- AskAbout staff training on software security processes: Verify if recent training sessions were conducted and which staff attended GoodIncludes recent training sessions with most relevant staff attending and clear materials
Cross-framework mappings
How ISM-2028 relates to controls across ISO/IEC 27001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (2) expand_less | ||
| Annex A 8.25 | ISM-2028 requires that software artefacts undergo SAST/DAST/SCA-based testing for known weaknesses before being admitted into the organis... | |
| Annex A 8.29 | ISM-2028 requires all software artefacts to be tested for known weaknesses using SAST, DAST or SCA (as appropriate) before they are impor... | |
| handshake Supports (1) expand_less | ||
| Annex A 8.26 | ISM-2028 requires third-party software artefacts to be tested using SAST, DAST and SCA before being imported and throughout the SDLC | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.