1. Start with an updated inventory
List servers, operating systems, packages and software in containers. A vulnerability matters to you when an affected component and version are present under the conditions described by its vendor.
Obermon automatically collects installed software inventories from Linux servers and containers. This is not a penetration test or a comprehensive review of application source code.
2. Decide which updates come first
A high score alone does not describe real risk: consider known exploitation, exposure, system importance and whether a fix exists. CISA’s KEV catalogue documents exploited vulnerabilities, but absence from it does not establish safety.
Obermon checks software daily. Vulnerability alerts trigger for exploited issues or critical issues with a fix available. The update list helps organise work: fewer notifications do not mean there are no other risks.
3. Fix and verify, rather than just dismissing an alert
Read vendor or distribution advisories. Prepare backups and rollback, test updates where possible and agree a maintenance window. Where no patch exists, assess vendor-recommended mitigations.
After the change, verify the version, availability and next check’s result. Obermon indicates what to update; it does not automatically patch monitored software. Record the person, time and reason when acknowledging, mitigating or resolving a vulnerability.
4. Include unsupported systems and certificates
An unsupported operating system may no longer receive routine fixes. Plan migration and check any extended-support arrangements. Review SSL certificate renewal and validity too: expiry can disrupt a service, but is not necessarily a CVE.
Obermon flags unsupported operating systems and expiring certificates. This is technical visibility to complement access controls, backups and other security measures, not real-time protection or attack blocking.
Sources and further reading
This information does not replace a technical or legal assessment of your circumstances.