Disclosure of Software Vulnerabilities Responsibly
Share software flaws publicly in a careful and quick manner to ensure security.
Plain language
When software has a flaw that could let hackers in, it's crucial to share details about this problem in a careful and timely way. This helps others fix it quickly and prevents serious issues like data theft or system breakdowns.
Framework
ASD Information Security Manual (ISM)
Control effect
Responsive
Classifications
NC, OS, P, S, TS
ISM last updated
Nov 2023
Control Stack last updated
19 Mar 2026
E8 maturity levels
ML1, ML2, ML3
Official control statement
Online services that are no longer supported by vendors are removed.
Why it matters
Failing to remove vendor-unsupported online services leaves exploitable, unpatched vulnerabilities exposed to the internet, increasing breach likelihood.
Operational notes
Maintain an inventory of internet-facing services and their vendor support status; promptly retire/replace end-of-life services and remove public exposure when support ends.
Implementation tips
- IT team should establish a process for identifying and categorising vulnerabilities: When a software flaw is found, log the details, including its severity and potential impact. Use a simple checklist to ensure all vital information is collected.
- IT manager is tasked with forming a timeline for disclosure: After identifying a vulnerability, they should decide when and how to inform others. They might start by notifying the software vendor and allowing time for a fix before broader disclosure.
- System owners should work with IT to use Common Weakness Enumeration lists: Help categorise the vulnerability using these standard lists for clear communication. This makes it easier for everyone to understand how serious the flaw is.
- Communications team should prepare a clear message for stakeholders: Write in plain language about what the vulnerability is and what actions are being taken to address it. This keeps everyone in the loop and reduces panic.
- IT manager should ensure public disclosure when appropriate: Once a fix is available, or if needed, explain the flaw publicly to inform other organisations. Provide guidance on implementing the fix for those affected.
Audit / evidence tips
-
Askthe vulnerability management policy: Request a copy of the policy outlining processes for handling discovered software flaws
Goodincludes clear, written procedures with roles and responsibilities defined
-
Goodreport shows timely action and communication efforts
-
Askrecords of communication with software vendors
Cross-framework mappings
How ISM-1905 relates to controls across ISO/IEC 27001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (1) expand_less | ||
| Annex A 8.8 | ISM-1905 requires removal of vendor-unsupported online services to reduce risk from vulnerabilities that can no longer be remediated | |
E8
| Control | Notes | Details |
|---|---|---|
| link Related (1) expand_less | ||
| E8-PA-ML1.8 | E8-PA-ML1.8 requires organisations to remove online services that are no longer supported by vendors | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.