An online shop consists of dozens of software building blocks: the shop system, the PHP runtime, the web server, the database, extensions, libraries and the operating system. In each of these, vulnerabilities are discovered continuously and published as CVEs (Common Vulnerabilities and Exposures). In 2025 alone, 48,185 new CVEs were added - around 131 per day (Zafran, 2026). Anyone who does not process this flood in a structured way patches either too late or not at all. At the same time, exploiting vulnerabilities has become the most common initial access in security incidents, with a 34 percent rise in the latest Verizon report (Verizon DBIR, 2026). This guide shows how to organize security patch and CVE management in four clear steps - detect, prioritize, test, deploy - and why a structured maintenance contract turns reactive chasing into a predictable process.
What CVE Management Means - and Why It Is a Process
A CVE is a unique identifier for a specific, publicly known vulnerability in a piece of software. The list is maintained centrally and enriched by databases such as the National Vulnerability Database (NVD) with severity and details. CVE management describes the ongoing process by which an operator finds out which of these vulnerabilities affect their own systems, how dangerous they are in the specific context, and in which order they are closed. It is explicitly not a one-off project, but a permanent task.
The sheer volume makes its importance clear: in 2024, around 40,009 CVEs were published, an increase of about 38 percent over the 28,818 CVEs of the previous year (Zafran, 2026). In 2025 the number rose further to 48,185 (Zafran, 2026). No shop operator can review this volume manually. The decisive factor is therefore to filter out the few truly relevant flaws from the mass and treat them specifically - instead of patching either everything or nothing.
CVE, CVSS and KEV Explained Briefly
Why Unpatched Vulnerabilities Are the Biggest Entry Point
Exploiting known vulnerabilities has become the dominant initial access for attackers. The current Verizon Data Breach Investigations Report records a 34 percent rise in this attack type and therefore sees it as the leading initial vector (Verizon DBIR, 2026). This is plausible, because a published CVE effectively hands attackers a blueprint: once the flaw and often a sample exploit are public, automated tools scan the internet for vulnerable systems.
Speed is especially critical. Analyses show that around 30 percent of vulnerabilities later actively exploited were already attacked on or before the day of their publication (VulnCheck, 2025). Anyone who patches only weeks later is therefore chasing an attack that may already be running. At the same time, old flaws are dangerous too: around 40 percent of CVEs exploited in 2024 were at least four years old (GreyNoise, 2025). A patch process has to cover both ends of the spectrum - brand new and long known.
For an online shop this weighs especially heavily, because not only availability but also payment data and personal customer data are at stake. A compromised shop means, in the worst case, leaking order data, manipulated payment pages or a complete business interruption during live operation. Recovery after an incident is, in experience, considerably more elaborate and expensive than applying a patch in time. What an orderly approach looks like in an emergency is described in our emergency plan for a hacked website - but the best emergency remains the one that consistent patching prevents from happening at all.
The Uncomfortable Metric
Step 1: Detect Vulnerabilities Reliably
You can only patch what you know about. The first step is therefore a complete inventory of all software components of a shop including version levels - from the shop core through PHP, web server and database to every single extension and library. This inventory forms the basis against which newly published CVEs are continuously cross-checked. Without a current inventory, every CVE notice remains an abstract message with no relation to your own system.
In practice, the cross-check uses several sources: the official CVE feeds and the NVD, the security advisories of the software vendors in use, and - as a particularly valuable filter - the CISA KEV list, which grew by 245 new, demonstrably exploited entries in 2025 (CISA, 2026). A CVE that is on the KEV list and affects a component used in the shop is a clear, urgent signal.
Component Inventory
All software building blocks documented with version: shop core, PHP, web server, database, extensions and libraries - the basis for every cross-check.
Dependencies and SBOM
A software bill of materials also makes indirect dependencies visible, where flaws often hide.
CVE Feeds and Advisories
Official CVE sources, the NVD and vendor advisories are continuously matched against the inventory rather than searched manually.
KEV Cross-Check
The CISA list of actively exploited flaws provides a particularly hard priority filter for acute cases.
Notification
When a relevant CVE hits a component in use, it triggers a defined response - no drowning in the inbox.
Continuous Update
The inventory is kept current with every change to the shop so the cross-check stays reliable over time.
Step 2: Prioritize by Real Risk
Not every CVE is equally urgent. With around 131 new CVEs per day (Zafran, 2026), trying to patch everything immediately would overload any maintenance team. Prioritization separates the few urgent items from the many uncritical ones. The first indicator is the CVSS value, which maps the technical severity on a scale up to 10. A flaw with CVSS 9.8 like the PHP-CGI vulnerability CVE-2024-4577 (NVD) obviously deserves more attention than a value in the lower range.
But the CVSS value alone is not enough. What matters is whether a flaw is actually being exploited and whether the affected component is exposed at all in your own shop. Two additions help here: the exploitation risk (for example via EPSS scores or the KEV list) and the specific context. A critical flaw in a module not reachable from outside is less urgent than a medium flaw directly in the checkout. This combination of severity, exploitation likelihood and exposure yields a reliable order.
| Criterion | What it measures | Example signal | Consequence |
|---|---|---|---|
| CVSS severity | Technical danger up to 10 | 9.8 (critical) | High base priority |
| KEV status (CISA) | Active exploitation proven | On the KEV list | Schedule immediately |
| Exploitation risk (EPSS) | Likelihood of an attack | High percentage | Bring forward |
| Exposure in the shop | Reachability of the component | Directly in checkout | Raise urgency |
| Patch availability | Is there already a fix | Vendor patch available | Schedule a test |
CVSS Is Not the Same as Urgency
Step 3: Test Patches on Staging Before They Go Live
A patch fixes a security problem - but in the worst case it can create a new one, for example if it collides with an extension or changes a function. That is exactly why a test run on a staging environment, as exact a clone of production as possible, belongs between prioritization and go-live. There the patch is applied first and the shop is checked under realistic conditions, without a single real customer being affected.
The test focuses on the business-critical flows: checkout, payment paths, search, cart, customer account and all interfaces. Only when these work correctly after the patch is it approved for production. If an error occurs, it is fixed on staging - not in the live shop. This gate approach prevents a patch from closing a flaw while disrupting the revenue flow. How this step fits into an overall update routine is described in detail in our Shopware update strategy.
# Apply security patch on staging and verify
composer update vendor/package --with-dependencies # targeted patch
bin/console cache:clear # clear cache after patch
bin/console dal:validate # check data model
# Functional tests: checkout, payment, search, cart, API
# Regression test against the critical paths
# Only after a green run -> approval for production- Provide a staging environment as a current clone of production
- Apply the patch on staging first, not directly in production
- Specifically test the business-critical paths after the patch
- Run a regression test against checkout, payment, search and interfaces
- Fix errors on staging and test again
- Only after a green approval, schedule the maintenance window for go-live
Step 4: Deploy in a Controlled Way with Rollback Protection
Once the patch is approved on staging, the controlled go-live in production follows. Even a carefully tested patch can reveal edge cases in live operation that did not appear in testing. That is why two things belong here: a deliberately chosen maintenance window outside high-revenue times and a tested rollback plan. Before deployment, a fresh database snapshot and a filesystem backup are created so the state can be quickly restored in an emergency.
After go-live, heightened attention applies. Monitoring observes error rates, response times and conversion in real time. Clearly defined thresholds decide on a rollback so that no time is lost on discussion in an emergency. Every applied patch is finally documented: which CVE it closes, when it was tested and deployed, and which component was affected. This auditability is not just tidiness, but also a basis for audits and compliance.
A patch without a tested rollback is a bet on a smooth course. With a snapshot, a rehearsed recovery path and real-time monitoring, deploying a security fix becomes a routine operation.
Treat Emergency Patches Separately
It also matters to distinguish between a pure security patch and a functional update. A security patch specifically closes a known flaw and should leave the rest of the functionality as untouched as possible - it is therefore usually faster to deploy and carries less risk than a large version update. Good CVE management uses this difference deliberately: acute flaws are closed via narrow, targeted patches, while larger functional updates are planned separately in the regular maintenance rhythm. This way two risks do not mix in a single maintenance window, and in case of an error it is clear which change was the cause. This clean separation considerably eases both testing and a possible rollback.
Why the Maintenance Contract Is the Right Framework
The four steps only work as a recurring process with clear ownership and fixed response times. That is exactly what a maintenance contract provides. Instead of hectically clarifying during an incident who does what by when, the procedures are defined in advance: who monitors the feeds, who prioritizes, in which window testing and deployment happen, and which response time applies to critical cases. The German Federal Office for Information Security explicitly recommends in its IT-Grundschutz that patches be evaluated, prioritized and applied promptly after release, and that decisions be documented in a traceable way (BSI IT-Grundschutz OPS.1.1.3).
The difference between reactive and structured action is measurable. Where patches are only fully deployed after a median of 43 days (Verizon DBIR, 2026) and attackers exploit critical flaws sometimes as early as day zero (VulnCheck, 2025), speed determines the risk. A fixed process with defined response times shortens the window in which a shop is vulnerable - and turns patching from a recurring disruption into a predictable routine. CVE management is not an isolated topic here, but closely interlinked with PHP EOL management, server hardening and regular updates.
A common objection is that an in-house patch process ties up too many resources. In practice the opposite is true: the greatest effort does not come from the orderly deployment of small, tested patches, but from the hectic clean-up of an incident or from a big jump when nothing has been updated for years. An ongoing process spreads the effort into small, predictable steps and thereby makes it calculable. This shift from the unplannable firefighting exercise to a calm routine is the actual value of a maintenance contract.
Continuous Observation
The relevant CVE feeds and advisories are continuously matched against your component inventory - not only once an incident has surfaced.
Fixed Response Times
For critical and actively exploited flaws, pre-agreed deadlines apply, instead of leaving treatment to chance.
Test and Approval Gate
Every patch goes through staging and approval before it reaches production - which protects against patch-induced disruptions.
Auditable Documentation
Which flaw was closed when with which patch is logged seamlessly - a basis for audits and compliance.
Sources and Studies