Finding a vulnerability is easy; closing one is a process.

A scan produces a list; vulnerability management is the process that carries that list to closure. Sanal Çekirdek builds it on asset context, ownership and measured time to close.

A vulnerability's score does not tell you how dangerous it is to you. The same score means something different on an internet-facing server than on an isolated test machine.

Let's measure your time to close Back to Cyber Resilience

Asset context

Scanning runs under the organization's explicit written authorization and within a defined scope. Prioritization starts with the context of the asset rather than the score of the finding: is it internet-facing, which data does it reach, how critical is it to the business. Scan output without context is a pile that cannot be closed.

The asset owner is known before scanning begins
Internet exposure travels as its own flag
Data class influences priority directly
An asset with no context enters the inventory first

Ranking by real risk

A medium-severity issue with public exploit code is more urgent than a high-severity one with none. Ranking places exploitability and exposure alongside the score.

Available exploit code changes the ranking
Compensating controls can lower urgency
The ranking method is written and repeatable
Exceptions are granted with an expiry, never permanently

Patch and remediation flow

Closing work usually sits with system and application teams rather than the security team. The flow accepts that: a finding reaches the right team, inside their own tooling, with an achievable target time.

Findings land in each team's own work tracker
Target times follow the criticality class
Patch windows are agreed with the maintenance calendar
Closure is confirmed by re-verification

Measurement and trend

Three numbers reveal the health of the process: mean time to close, the share of findings past target, and the count of reopened findings. If those are not improving, scanning more often only lengthens the list.

Time to close is reported per criticality class
Findings past their target are reported separately
A reopened finding points to a non-durable fix
Direction over several periods outweighs one month's figure

How we work

Clarify the asset inventory and ownership
Set scanning scope and frequency
Put the ranking method in writing
Route findings into the teams' own tooling
Track the three indicators and correct the process

How success is measured

Every finding has an asset owner
Findings close faster each period
Fewer findings run past their target date
Reopened findings are declining

Frequently asked questions

How frequently should we scan?

As often as your closing rate can absorb. Weekly scanning combined with monthly closure produces only a growing list; the flow has to be accelerated first.

Must every vulnerability be closed?

No, but every one needs a decision: fix, compensate or accept. A finding left undecided is a risk nobody is aware of.

Should cloud resources be in scope?

Yes, but through a different method. In cloud, most findings close through a configuration change rather than a patch, and the process should tell the two apart.

If you are holding a findings list that never closes, the problem may be the flow rather than the scan — let's review the process together.

Let's measure your time to close