25 October 2026

800 vulnerabilities, one administrator. What to do this week

A food manufacturer with two plants and a dozen or so Linux servers: the warehouse system, the production database, mail, a few internal applications. One administrator who, besides the servers, handles backups, printers and calls from the shift manager whose barcode scanner has stopped working. After the first full scan they get a list: 800 vulnerabilities, sorted from the highest score down.

They look at it and close the window. Not out of laziness. A list of 800 items does not tell you what to do on Monday morning, and there is already a queue of other things to do on Monday morning.

In the fourth part of the KSC series I show how an administrator can turn such a list into a short weekly plan, and which obstacles need a decision from the board. If you are responsible for KSC rather than for servers, this article tells you what plan to ask for.

What the law says

In Article 21(2)(e), the NIS2 Directive, implemented in Poland by the amended National Cybersecurity System Act (KSC), lists security in the maintenance of systems, including vulnerability handling, among the risk-management measures. Article 21(1) says the measures must be proportionate, taking into account the state of the art, the cost of implementation, the size of the entity, and the likelihood and severity of incidents.

The Directive does not set one deadline for removing all vulnerabilities or prescribe a tool. The Polish KSC Act does, however, require regular updates and prompt action once a vulnerability is noticed, so "some day" is not an answer. Proportionality is about risk, not the size of the IT team: a one-person team does not justify weaker protection, but a well-ordered sequence lets one person do the most important things first and be able to explain why.

Why a list is not a plan

A vulnerability list sorted by severity score has three flaws that together make it impossible to work from.

It counts repetitions. The same vulnerability in the same library on ten servers is ten items. One package update can close a dozen vulnerabilities at once. The list shows symptoms, while the work happens on causes.

It mixes what can be done with what cannot. A large share of items has no fix yet from the vendor or the distribution. On my own nine servers it was ninety percent of the list. You cannot update those, but that does not mean nothing needs doing about them.

It sorts by the wrong key. A severity score says how much a vulnerability could hurt. It says nothing about whether anyone is using it. On the same fleet of mine, none of the seven vulnerabilities known to be exploited in attacks had critical severity. Sorting by severity, I would not have seen any of them at the top.

How to turn it into a weekly plan

The steps below work with any scanner and a spreadsheet. A tool only speeds them up.

1. Separate what has no fix. You cannot schedule it as an update, but do not drop it from view. Check whether any of these items are urgent, for example exploited in attacks on an internet-facing server. Those need a workaround, restricted access or a risk decision. Keep assessing the rest and watch for when a fix appears.

2. Turn vulnerabilities into packages. The question is not "which vulnerability to fix" but "which package to update, and on which servers". On my fleet, 17 thousand items with an available fix corresponded to 310 packages. Once grouped, you will see how many separate updates really need planning.

3. Order by what is actually dangerous. First, packages with vulnerabilities from the KEV catalogue, meaning those known to be exploited in attacks. Then whatever sits on internet-facing servers or servers critical to running the business. Then severity and the likelihood of exploitation. I wrote about this in more detail in the article on KEV and CVSS.

4. Pick three to five tasks for this week. Not all of them. As many as can realistically be done alongside your other duties, with a person and a deadline for each. Three tasks done beat thirty started.

5. Group by what needs a restart. Some updates require restarting a service or the server, which at a production plant means a maintenance window. Bundle them so you do not stop the warehouse system every week.

6. What will not make the deadline needs a decision. If the company has set remediation deadlines and some package cannot be updated in time because the application vendor does not support the newer version, that is not a task for the administrator. It is a risk decision that someone has to make and record. That is the topic of the next part.

7. Once a week, check whether the backlog is shrinking or growing. New vulnerabilities arrive every week, however well you work. If overdue items keep piling up for several weeks in a row, show the board the trend and its causes. Perhaps there are not enough maintenance windows, perhaps one application cannot be updated, or perhaps one person is simply not enough. This is the board decision I mentioned at the start: whether the measures match the risk is for the board to judge, not the administrator.

Where Secvalis helps, and where it does not

The priority list in Secvalis groups open vulnerabilities into tasks by package and shows the order of work. KEV status and severity affect that order, and the criticality and exposure of a machine change the remediation order without changing the severity of the vulnerability itself. The vulnerability card shows, when available, the CVSS severity score, the EPSS exploitation likelihood forecast and whether the vulnerability is in the KEV catalogue.

Finding context distinguishes, among other things, packages for a kernel that is not currently running and cases that require a restart, which helps when planning maintenance windows. The company sets its own remediation deadlines, and for vulnerabilities in the KEV catalogue an additional limit applies that can shorten the deadline. The account owner or administrator can assign a person to a finding, and the remediation plan shows assigned open items with their deadline. A daily digest and alerts about critical or high vulnerabilities can be delivered by email, webhook, Telegram or a chosen chat tool.

Secvalis does not install updates, does not test them and does not plan maintenance windows. It does not know which application at your plant will stop working after a library update; the administrator knows that. It covers Linux servers and the images of containers running on them, not Windows workstations, network devices or production line controllers.

You can see the package task list on a fictitious company's data in the public demo, with no registration.

In the next part: what to do when a fix exists but cannot be installed right away, and how to make a decision you can defend in front of an auditor.

Sources

One email a week with newly published vulnerabilities worth knowing about. No account needed.

This digest covers new vulnerabilities in general, not your servers. If you want to know which of them actually run in your infrastructure, that is what Secvalis does: it scans your machines and reports only what concerns them.