Vulnerability management and disclosure
Map vulnerability findings to the installed version, configuration and exposure. Use that context to plan remediation, approvals and the change window.
Sources and scopeSource record 25 August 2026
Technical source record: 25 August 2026. Check the linked documentation for current product requirements.
Research and static guidance only; product and deployment specific behaviour requires controlled environment validation and authoritative product evidence.
On this page
Overview#
A vulnerability record becomes actionable only when mapped to exact assets, versions, configuration, exposure, privileges, physical consequence, available fixes, and recovery constraints. A product family name or CVSS score alone is insufficient.
Intake sources#
- official vendor product security advisories and release notes;
- CISA Known Exploited Vulnerabilities and ICS advisories;
- national CERT/CSIRT publications;
- standards body errata or deprecation notices;
- vulnerability databases used as discovery indexes, followed by the cited primary advisory;
- authorised internal testing evidence with the exact environment, method, and limitations.
Triage record#
| Field | Required decision |
|---|---|
| Identity | Product, model, hardware, firmware/software, component and build feature |
| Applicability | Confirmed, not affected, potentially affected, or insufficient evidence |
| Exposure | Reachable interfaces, authentication, network zone, user interaction and prerequisites |
| Impact | Confidentiality, integrity, availability, tenant boundary, evidence and physical/safety effect |
| Exploitation | Vendor/CISA status and local indicators; do not infer from score alone |
| Remediation | Fixed version, configuration change, disablement, isolation or replacement |
| Operational cost | Downtime, compatibility, data migration, recertification and rollback |
| Deadline/owner | Risk based target and accountable role |
| Evidence | Sources, inventory query, configuration record, and environment validation |
Response hierarchy#
Prefer a vendor supported fixed version after compatibility and recovery planning. If unavailable, reduce reachability, disable the vulnerable feature, strengthen upstream identity/authorisation, add protocol aware mediation, increase monitoring, or replace the product. Document what a compensating control doesn't prevent.
Don't actively probe production physical security equipment with exploit code merely to confirm applicability. Use version/configuration evidence, vendor guidance, a non production owned device, or an offline component when necessary and authorised.
Coordinated disclosure#
For newly discovered issues, preserve minimal evidence, protect customer and facility information, avoid public exploitation details before remediation coordination, contact the supplier's published PSIRT channel, agree on secure communication and timelines, and involve the appropriate coordinator if the supplier is unavailable. Life safety or actively exploited conditions may require accelerated coordination.
ISO/IEC 29147:2018 and ISO/IEC 30111:2019 remain the published baselines at this review date. ISO lists a third edition ISO/IEC 29147 Approved Work Item and ISO/IEC WD 30111.2 as replacements under development. Those projects can change and must not be cited as published requirements.
Sources#
- CISA KEV, CISA Known Exploited Vulnerabilities Catalog, authoritative US federal exploitation action catalogue, accessed 25 August 2026.
- CISA ICS, CISA Industrial Control Systems Advisories, accessed 25 August 2026.
- ISO 29147, ISO/IEC 29147:2018 Vulnerability disclosure, catalogue entry, paywalled standard, accessed 25 August 2026.
- ISO 30111, ISO/IEC 30111:2019 Vulnerability handling processes, catalogue entry, paywalled standard, accessed 25 August 2026.
- ISO 29147 NEXT, ISO/IEC AWI 29147 edition 3, under development, accessed 25 August 2026.
- ISO 30111 NEXT, ISO/IEC WD 30111.2 edition 3, under development, accessed 25 August 2026.