In short: Vulnerability management in mid-sized businesses and SMEs is a lean, recurring cycle: know your systems, follow alerts selectively, assess by risk, decide, implement and document. What matters is not expensive tools but clear responsibilities and a prioritisation that takes reachability, data and the threat situation into account. PHP2Shell is a good practice example because every step of the cycle appears in it.
Hundreds of alerts, few people
New security vulnerabilities are published every week, in operating systems, programming languages, applications and plugins. A large corporation has a team for this. A mid-sized company often has one head of IT, one or two admins and several external service providers. Nobody can read every alert, and nobody needs to.
What is needed is a filter: which alerts concern our systems, which of those are urgent, and who takes care of them? Without this filter, one of two things happens. Either everything is ignored until something goes wrong, or every alert causes alarm and the truly critical one is lost in the noise.
The vulnerability management cycle
A workable process for SMEs can be described in six steps:
- Record what is running. Without an inventory there is nothing to compare against. Which websites, servers, PHP versions and applications do you operate, and where? How to achieve this is shown in Know what is running: an inventory of all websites and servers.
- Follow alerts. Subscribe to a few reliable sources: warnings from the BSI (German Federal Office for Information Security), notices from the vendors of your software, the security pages of your Linux distribution and, for PHP, the home page of php.net.
- Assess. Does the alert affect us? If so, how urgent is it? More on this below.
- Decide. Fix, secure temporarily, isolate the system or knowingly accept the risk. Who may decide what?
- Implement. Install the update, apply an interim measure, commission a service provider.
- Verify and follow up. Is the vulnerability really closed? When will an interim solution be replaced?
After that the cycle starts again. New systems are added, old ones are retired and new alerts appear.
For step 2, a simple rule helps: read a few sources regularly rather than many occasionally. For a typical mid-sized web environment, the warnings from CERT-Bund (the German government CERT) at the BSI, the security notices of the Linux distribution in use, the pages of the CMS and shop vendors and the home page of php.net are usually enough. Decide who reads these sources, and set up a shared mailbox or channel for them that does not depend on a single person.
A look from the outside is also worthwhile. A regular vulnerability scan of your publicly reachable systems shows whether outdated software or unnecessarily open services are visible. It replaces neither the inventory nor updates, but it uncovers systems that appear on no list.
Assessing: what comes first
The CVSS score, a standardised rating of severity, is a good starting point. For the order of work within your own company, however, it is not enough. Three further questions decide:
| Question | Increases urgency | Decreases urgency |
|---|---|---|
| Is the system reachable from the internet? | public website, shop, portal | internal only, behind a VPN |
| Is a login needed to exploit the vulnerability? | no, unauthenticated | yes, administrators only |
| What data does the system process? | customer data, payments, credentials | public content without accounts |
| Are there reports of attacks? | attack attempts reported | no known attempts |
| Is there an interim measure? | no | yes, with proven effect |
PHP2Shell shows how these factors interact. Both vulnerabilities have a CVSS v4.0 score of 9.2, allow code execution without a login and affect publicly reachable web servers. According to media reports, Cloudflare and Patchstack observed attack attempts, and the BSI classified the situation as warning level 3. The interim measures from php.net explicitly do not offer complete protection. All the questions point in the same direction: act immediately. What the BSI specifically recommended is covered in What the BSI recommends on PHP2Shell.
Deciding and documenting
Not every vulnerability can be closed immediately. A legacy system runs on PHP 8.1, for which there are no official updates any more (see PHP 8.1 and older: what applies now), and a specialist application does not yet tolerate the update. A decision is then needed, and it does not belong in the technical team alone.
A good decision note contains the affected system, the vulnerability, the assessment, the option chosen, interim measures, the responsible person and a date for review. If a risk is knowingly accepted, management decides, not the admin alone. The OWASP cheat sheet on handling vulnerable dependencies likewise recommends anchoring risk acceptance explicitly at management level.
Keep a single list of open vulnerabilities with status, owner and deadline. A table is enough. What matters is that it is reviewed regularly, for example in the monthly meeting with management.
What NIS2 and service providers have to do with it
For companies that fall under NIS2, handling vulnerabilities is part of the risk management obligations. The details are described in NIS2 and web server security. But even without a legal obligation, a documented process is an advantage, for instance towards customers, insurers and your own management.
Many steps can be outsourced, such as following alerts or installing updates. The decision on risks and the overall picture should, however, stay in-house. A company that hands the entire cycle over to a service provider no longer knows in an emergency which systems it has at all. How to organise implementation as a routine is described in Patch management as a process instead of firefighting.
How does PHP SOS help?
- Together with you, we create the inventory of your websites and servers as the basis for every comparison.
- We follow the relevant alerts for your systems and provide an assessment in plain words with a recommendation.
- We prepare decision notes for cases where an update is not possible immediately.
- Through security monitoring, we continuously check whether systems become conspicuous while a vulnerability is still open.
Conclusion: Vulnerability management in a mid-sized business does not have to be big, but it has to be binding. Anyone who knows their systems, reads a few good sources and records decisions will react quickly and correctly to the next critical alert.
Frequently asked questions
What is vulnerability management?
A recurring process by which a company learns about security vulnerabilities in its systems, assesses them, fixes them or knowingly accepts them, and records the outcome. It is not about a tool, but about responsibilities and decisions.
Is the CVSS score enough for prioritisation?
It is a good starting point, but not enough. What also matters is whether the affected system is reachable from the internet, what data it processes and whether attacks have already been observed. A vulnerability with a high score on an internal test system can wait; one on the shop cannot.
Does a small company need a dedicated tool for this?
Not at the start. A maintained list of systems, subscribed security alerts and a table of open items are enough. Vulnerability scanners pay off when the number of systems grows or when regular audits need to be evidenced.
May a vulnerability be knowingly left unfixed?
Yes, provided the risk has been assessed, the decision is made by the responsible management and recorded in writing, ideally with interim measures and a date for review.