The security team receives a long export from the latest scan. Thousands of rows, each with a vulnerability ID, an IP address and a severity score. Someone splits it by team and sends it out. Operations then tries to work out which servers these actually are, which service they belong to, and when they may be touched. A month later the next export arrives, and nobody can say with confidence what from the previous one has been fixed.
Behind this picture are tired people on both sides. Security feels operations is not listening. Operations feels it receives lists with no context and no priorities. And management asks a simple question nobody can answer quickly: are we in a better position than last month?
Why a scanner export is not enough
A scanner does what it is built for: it finds vulnerable software versions. What it does not know is what role a server plays, which service runs on it and who is accountable for that service. Without that, a finding cannot sensibly be turned into work.
We often see the same weaknesses:
- findings are ranked by score alone, even though in real operations it matters more whether a vulnerability is being actively exploited,
- fix deadlines are not derived from severity, so a critical finding can wait as long as a minor one,
- the path from finding to change runs through email and manually created tickets,
- remediation status is stitched together from several spreadsheets and is always one step behind.
How to approach it
A vulnerability finding only becomes meaningful when it is connected to the CMDB. Once we know which server it sits on, we also know which service it puts at risk, who owns that service and what its maintenance window is. Only then can we decide on order and timing.
Priority should follow two questions: how severe is the vulnerability, and is anyone actively exploiting it? The deadline follows from the answer. The path to a fix should run through the normal change process, so that even an urgent fix respects the impact on services, just with shorter lead times.
How Eywo Stratum handles it
Eywo Stratum imports findings from your scanner and matches them to CMDB items. Vulnerabilities are then visible per server and per service, so each service owner sees what concerns them.
Prioritisation builds on that:
- actively exploited vulnerabilities (KEV) are clearly flagged so they do not get lost among the rest,
- severity-based deadlines set when a finding must be fixed,
- an expedited mode for critical issues, agreed in advance in the patch agreement with the service owner, provides a shorter path without bypassing accountability.
The route from finding to fix is a wave-based patching plan. Servers are grouped by service and window, and the plan generates the changes in a single step. Each change goes through impact calculation, maintenance window checks, freezes and collision detection. Redundant nodes can be patched one at a time so the service stays available.
The vulnerability and remediation dashboard shows how many findings are open, which are approaching their deadline and how remediation is progressing by service. Security and operations look at the same data, which ends the debate about whose spreadsheet is current.
A shared picture instead of passing lists around
Vulnerability management is not only a security discipline. It is operational work that needs context: servers, services, owners and changes. When that information is connected, security does not have to chase and operations does not have to guess. Both sides can see what needs fixing first, who approves it and when it will happen. And management's question about whether things are better than last month has an answer on a single screen.
Finding import, vulnerability prioritisation, patch planning and the remediation dashboard are included in the Business edition.
Eywo Stratum Business
For operations that want to connect monitoring, security and vendors.