ASD ISM 1908 Responsible disclosure of software vulnerabilities
What it says
Vulnerabilities identified in software are publicly disclosed in a responsible and timely manner, including with Common Weakness Enumeration and Common Platform Enumeration information.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishSoftware weaknesses must be reported openly and quickly, using standard classification systems.
This control is about making sure software flaws are reported responsibly and quickly so they can be fixed before causing harm. If vulnerabilities are not disclosed properly, hackers could exploit them to steal information or disrupt operations.
Free. Save your status, tasks and notes.
Why it matters
Failure to responsibly disclose vulnerabilities can lead to exploitation by attackers, causing data breaches and operational disruptions.
How to implement
Software developers should establish a clear process for reporting vulnerabilities, including designated contacts for receiving reports.
This can be done by creating a contact form or dedicated email address specifically for this purpose, clearly visible on your website.
The IT team should integrate Common Weakness Enumeration (CWE) and Common Platform Enumeration (CPE) classifications when documenting vulnerabilities.
Use resources and tools available online to consistently define and classify each identified vulnerability against these standards.
Managers should ensure all employees are educated on the importance of timely vulnerability disclosure.
Conduct regular training sessions that simulate reporting processes, highlighting roles, responsibilities, and the importance of swift action.
IT leads should work with management to develop a public statement or policy on responsible vulnerability disclosure.
This can include issuing press releases or posts on company platforms when significant vulnerabilities are disclosed and addressed.
Organisation leaders should set a timeframe for disclosing vulnerabilities publicly after they are discovered and resolved.
This might involve waiting a set number of days or weeks, balancing transparency with the need to develop a fix before making details public.
Keep it running
Disclose identified vulnerabilities responsibly and promptly, including CWE/CPE details, and coordinate release timelines with vendors and affected parties.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The vulnerability disclosure policy document: Review if it outlines roles, contact points for reporting, and classification systems.
Good evidence
Document will clearly outline procedures, timelines, and how vulnerabilities are classified.
- Check 2 of 5What an auditor asks for
Good evidence
List will have complete, detailed entries for each reported vulnerability including key dates and actions taken.
- Check 3 of 5What an auditor asks for
Ask for
To see the contact method for reporting vulnerabilities on the organisation's website.
Look at
Its visibility and accessibility to the public.
Good evidence
Would show easy access with clear instructions on reporting.
- Check 4 of 5What an auditor asks for
Good evidence
Training program will be documented with materials that cover procedure and demonstrate regular sessions.
- Check 5 of 5What an auditor asks for
Ask for
Recent public statements on addressed vulnerabilities: Review for clarity and compliance with the public disclosure policy. Effective statements will provide detail without compromising security or breaking any agreements.
Mappings
Closest match in ISO/IEC 27001: A.8.8, Management of technical vulnerabilities, which partially overlaps with this control.
ISO/IEC 27001: 1 mapping
This control partially overlaps A.8.8.
ISM-1908 requires vulnerabilities identified in an organisation's software to be publicly disclosed in a responsible and timely manner, including Common Weakness Enumeration and Common Platform Enumeration information. Both controls sit within technical vulnerability management: ISM-1908 makes structured vulnerability information available to those using the software, while Annex A 8.8 requires the organisation to obtain such information, evaluate its exposure and take appropriate measures. Annex A 8.8 focuses on vulnerabilities in systems the organisation uses, whereas ISM-1908 covers the disclosure obligations of an organisation that produces software, so each covers aspects the other does not.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.