Responsible Disclosure of Software Vulnerabilities
Software weaknesses must be reported openly and quickly, using standard classification systems.
Plain language
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.
Framework
ASD Information Security Manual (ISM)
Control effect
Responsive
Classifications
NC, OS, P, S, TS
ISM last updated
May 2025
Control Stack last updated
19 May 2026
E8 maturity levels
N/A
Guideline
Guidelines for software developmentOfficial control statement
Vulnerabilities identified in software are publicly disclosed in a responsible and timely manner, including with Common Weakness Enumeration and Common Platform Enumeration information.
Why it matters
Failure to responsibly disclose vulnerabilities can lead to exploitation by attackers, causing data breaches and operational disruptions.
Operational notes
Disclose identified vulnerabilities responsibly and promptly, including CWE/CPE details, and coordinate release timelines with vendors and affected parties.
Implementation tips
- 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.
Audit / evidence tips
- AskThe vulnerability disclosure policy document: Review if it outlines roles, contact points for reporting, and classification systems GoodDocument will clearly outline procedures, timelines, and how vulnerabilities are classified
- GoodList will have complete, detailed entries for each reported vulnerability including key dates and actions taken
- AskTo see the contact method for reporting vulnerabilities on the organisation's website GoodWould show easy access with clear instructions on reporting
- GoodTraining program will be documented with materials that cover procedure and demonstrate regular sessions
- AskRecent 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
Cross-framework mappings
How ISM-1908 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| handshake Supports (2) expand_less | ||
| Annex A 5.14 | ISM-1908 requires organisations to disclose vulnerabilities responsibly and in a timely manner, including publishing or sharing details w... | |
| Annex A 5.24 | ISM-1908 requires responsible, timely public disclosure of software vulnerabilities and inclusion of vulnerability classification informa... | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.