ASD ISM 0402 Software vulnerability testing using SAST, DAST and SCA
What it says
Software is comprehensively tested for vulnerabilities using SAST, DAST and SCA prior to its initial release, any subsequent release, and periodically to help identify any previously unidentified vulnerabilities.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishSoftware is regularly tested for security vulnerabilities using various testing methods before and after release.
This control ensures that software is thoroughly checked for security weaknesses before and after it's launched. If missed, these weaknesses could become easy targets for hackers, leading to stolen data or financial losses.
Free. Save your status, tasks and notes.
Why it matters
Unaddressed software vulnerabilities can lead to potential breaches, data loss, and significant financial damages.
How to implement
System owners should schedule regular vulnerability scans: Allocate time before each software release to conduct vulnerability checks.
Use tools that automatically scan for known issues.
IT team should conduct Static Application Security Testing (SAST): This involves reviewing the software's code for vulnerabilities.
Train team members to use specific software tools that highlight potential security flaws in the code.
IT security personnel should employ Dynamic Application Security Testing (DAST): This type involves testing running applications for vulnerabilities.
Use tools that simulate attacks to identify and fix security gaps before software is deployed.
Procurement should source Software Composition Analysis (SCA) tools: These tools scan for vulnerabilities in third-party components.
Ensure that the team remains aware of vulnerabilities in open-source libraries by integrating SCA in the development lifecycle.
Managers must ensure periodic reviews post-release: Schedule ongoing security evaluations at regular intervals after software goes live.
Confirm that assessments keep up with new threats by updating tools and techniques as needed.
Keep it running
Maintain up-to-date knowledge of security tools and regularly update testing protocols to address new vulnerabilities.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
the most recent SAST testing report: Request records showing when and where code was reviewed for vulnerabilities.
Look at
indications that all critical code areas were assessed.
Good evidence
is a detailed report showing the vulnerabilities discovered and fixed.
- Check 2 of 5What an auditor asks for
Ask for
a log of DAST assessments: Request documentation demonstrating that dynamic tests were conducted on running applications.
Look at
evidence that testing covered all application functionalities.
Good evidence
shows test results with identified issues and the steps taken to mitigate them.
- Check 3 of 5What an auditor asks for
Ask for
Software Composition Analysis records: Request a list showing results from scanning third-party components.
Look at
whether all dependencies have been analysed for weaknesses.
Good evidence
includes a clear record of outdated or vulnerable components and actions taken to address them.
- Check 4 of 5What an auditor asks for
Ask for
meeting notes from post-release security evaluations: Request documentation of any discussions conducted to review security findings.
Look at
schedules and frequency of these meetings.
Good evidence
would demonstrate regular and consistent review cycles with documented outcomes.
- Check 5 of 5What an auditor asks for
Ask for
a vulnerability management policy: Request any documents detailing how new vulnerabilities are tracked and addressed over time.
Look at
details on responsible personnel and patching timelines.
Good evidence
would display a proactive approach to updating and securing software.
Mappings
Closest match in ISO/IEC 27001: A.8.25, Secure development lifecycle, which this control partially meets.
ISO/IEC 27001: 4 mappings
This control partially meets A.8.25.
ISM-0402 requires comprehensive vulnerability testing (including SAST, DAST and SCA) prior to release and periodically thereafter. Annex A 8.25 requires the organisation to establish and apply rules for secure development across the software and system lifecycle, under which security testing is one possible rule set. ISM-0402 is a specific secure-SDLC requirement focused on vulnerability testing, while Annex A 8.25 covers many additional secure development practices beyond testing.
This control partially meets A.8.29.
ISM-0402 requires comprehensive software vulnerability testing using SAST, DAST and SCA before initial release, subsequent releases, and periodically to uncover previously unidentified vulnerabilities. Annex A 8.29 requires that security testing processes are defined and implemented within the development and acceptance lifecycle, which can include vulnerability testing activities such as SAST/DAST/SCA. ISM-0402 is more prescriptive and specific about the testing types and timing, whereas Annex A 8.29 is broader and leaves the specific testing methods to the organisation.
This control depends on A.8.28.
Annex A 8.28 requires secure coding principles to be applied to prevent vulnerabilities during software development. ISM-0402 supports this by mandating comprehensive vulnerability testing (SAST/DAST/SCA) prior to releases and periodically, which helps detect when secure coding practices were missed or incorrectly implemented. ISM-0402 is testing-focused and does not itself require secure coding practices to be followed in day-to-day development.
This control depends on A.8.30.
ISM-0402 requires comprehensive vulnerability testing (SAST, DAST, SCA) before release and periodically to identify previously unknown vulnerabilities. Annex A 8.30 requires the organisation to direct, monitor and review outsourced development activities, which can be used to mandate and evidence that suppliers perform the SAST/DAST/SCA testing required by ISM-0402. Annex A 8.30 is governance over third parties, while ISM-0402 is the specific technical assurance outcome to be achieved regardless of who develops the software.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.