Container Vulnerability Management: Is Every Site Patched?

Yes, a company with hundreds of sites can fix a security weakness everywhere, and prove it. The fix itself is rarely the hard part. The hard part is knowing where the affected application runs, rolling out safely, and showing site by site that the new version is running and healthy.

Container vulnerability management is the work of finding, fixing and confirming security weaknesses in the containerized applications you run. Across hundreds of stores, factories or machines, confirming is the part leadership keeps asking about. Three terms we use:

• A container is an application packaged with everything it needs to run, so it behaves the same on any host.
• A CVE (Common Vulnerabilities and Exposures) is a public ID for a known security weakness.
• A patch is the corrected code, usually shipped as a new version of the container image.

This article is for leaders and teams who answer for applications across many sites. Worth noting is that container scanning and CVE management are outside the scope of the Avassa Edge Platform, yet they’re key to a solid security posture at the edge. Once in place, Avassa will take care of the rest when it comes to operations and orchestration at the edge.

Why One CVE Alert Becomes an Edge Security Problem at Hundreds of Sites

It is Monday morning. Your security team flags a new CVE in a component that some of your containers use. Within the hour, someone in leadership asks four questions:

1. Which applications are affected?
2. Which sites run them?
3. How fast can we fix them without breaking anything?
4. How do we know it is done, everywhere?

The first three are about action. The fourth is about proof, and it is the one that tends to stay open longest.

Many sites make every one of those questions harder. Nobody on site can check a machine. Hardware differs from store to store and from one production line to the next. Connections are weak or come and go. Some machines sit at customer locations you do not control. This is what makes edge security different from securing a data center: the same weakness has to be handled at hundreds of places you cannot walk into.

A vulnerability management program is the ongoing process an organization uses to find, rank, fix and verify security weaknesses across its systems. It usually covers scanning, risk ranking, remediation and reporting. The response we describe here sits inside that program: the moment a known weakness meets your running fleet, and the work of closing it out.

The five steps ahead:

• Find the affected applications and sites
• Decide what to fix first
• Roll out the fix in stages
• Confirm the fix reached every site
• Handle the sites that are offline

Container Vulnerability Management in Five Steps: From CVE Alert to Patch

Each step below answers part of the leader’s four questions. Steps 1 and 2 tell you what is affected and what comes first. Step 3 covers how fast you can move safely. Steps 4 and 5 deliver the answer to “is it done?”, including for the sites that cannot answer yet.

Step 1: Find the Affected Applications and Sites

You cannot fix what you cannot find. When the alert lands, you need a record of what runs where, and you need it before the alert, not after. Rebuilding that picture from spreadsheets and messages during an incident is slow and usually wrong.

For every site, the record should hold the application, the version running (and the container image behind it), the site, and the host (the machine it runs on).

Finding the weakness is the job of separate security tools. They scan container images and match the components inside against published CVE data. The Avassa Edge Platform does not scan containers or find vulnerabilities per se. What Avassa adds is the other half of the answer. In the Avassa Edge Platform, sites, hosts, applications and versions are tracked as objects you can query through the UI, API or CLI. The platform keeps both the declared state (what should run) and the actual state (what is running), as we describe in NCSC’s 5 OT architecture principles, put into practice with Avassa. So when your security tool says “image version 3.2 is affected”, you can answer “where do we run version 3.2?” from a maintained record.

Two examples, to make it concrete. These are illustrations, not customer stories:

• A retail chain. A checkout service runs in every store. The security tool flags version 3.2. What you need is the list of stores actually running 3.2, not the list of stores that should run it according to last quarter’s rollout plan.
• A manufacturer. A protocol adaptor runs next to production lines in three plants. Two lines still run an older version because of a machine vendor requirement. Your record has to show that exception, or those two lines will be missed.

Step 2: CVE Prioritization: Decide What to Fix First

CVE prioritization means choosing which fix goes first when you cannot fix everything at once. With a busy CVE week and hundreds of sites, that is the normal case.

Your security tool gives each weakness a severity score. Your team adds the business context the score cannot see: which sites matter most, what is exposed, and who has to sign off. The decision stays with your team.

Walk through these questions for each finding:

Question to ask	Why it matters
Can the weakness be reached at the site?	If the vulnerable component is not exposed or not in use, the real risk may be lower than the score suggests.
How important is the site to the business?	A flagship store or a bottleneck production line carries more risk than a pilot site or a lab.
Is the application connected to the outside?	Applications that accept traffic from, or send traffic to, outside networks are easier for an attacker to reach.
Is a fixed version available?	Without a fix, you plan temporary protection, such as closing network access, while you wait for the vendor.
Who owns the application at the site?	Someone has to approve, test and sign off the fix, especially for third-party software.

Two things make these questions easier to answer in the Avassa Edge Platform. Sites can carry labels for business context, such as criticality or region, so “which important sites run this?” becomes a filter rather than a meeting. And each application’s specification declares what it exposes and what it may contact. By default, a container cannot open outbound connections unless the specification allows it, so the “connected to the outside?” question has a written answer.

Step 3: Container Vulnerability Remediation: Roll Out the Fix in Stages

Container vulnerability remediation is the act of replacing the vulnerable application with a fixed one. In practice, the fix is usually a new version of the container image with the patched component inside. You build it, test it, and tell the platform that this new version is what should run.

Then you roll it out in stages. A staged rollout sends the fix to a few sites first, checks that they are healthy, and only then moves on to more sites. Rollback means returning a site to the previous version if the new one causes problems.

Start with sites that matter least to the business. If something goes wrong, it goes wrong where the impact is smallest. Classifying sites by criticality and updating low-criticality sites first is one of the practical ways to apply the NCSC guidance on risk-based decisions, as we cover in the NCSC article.

In the Avassa Edge Platform, the rollout works like this, as described in What are OTA updates in Application Management Edge?:

• Canary, rolling and rollback. The platform supports canary releases, rolling updates and rollback as standard rollout strategies.
• Canary sites by label. You choose the first group of sites with a label, for example canary = true. Promotion to the rest of the fleet can be automatic after the canary sites stay healthy, or gated behind a manual go or no-go. Read more in Labels, groups and blast radius.
• Rolling batches. The remaining sites update a set number at a time, with a wait between batches to confirm health.
• Automatic stop. If a canary site or a batch fails its health check, the rollout stops there instead of continuing across the fleet.
• Applications update independently. Each application has its own versioning, health checks and update cycle, so patching one does not disturb the others running at the same site.
• Built for weak links. The platform downloads only the changes it needs, restarts transfers when a connection drops, and shares images between hosts at a site to save bandwidth.

Watch how the Avassa Edge Platform deploys and updates applications across many stores and factories.

Take the Product Tour

Step 4: Confirm the Fix Reached Every Site

This is the step leadership cares about most, and the one that is easiest to get wrong.

“We sent the fix” describes intent. It does not tell you what is running in store 0203 right now. A fix can be sent and still fail to start, start and then crash, or be waiting in a later batch. Proof means comparing, for every site, what should run with what is actually running, and whether it is healthy.

What to check for each site:

• The new version is running. Not scheduled, not downloaded, running.
• The application is healthy. It started cleanly and passes its health checks.
• Which sites are still waiting, and why. In a later batch, stopped by a failed check, or offline.

Who needs this proof:

• Leadership, who must answer for risk across the business.
• Auditors, who want evidence that a known weakness was closed, and when.
• Customers, especially when your machines run at their sites and they ask whether they are exposed.

In the Avassa Edge Platform, proof comes from the sites themselves. The Edge Enforcer, the agent on every host, monitors application startup and health at the site and reports the result back to the Control Tower. That status is visible fleet-wide and per site, along with logs, metrics and alerts. Every change, whether from a pipeline or an operator, produces an audit record. And because everything is available through the REST API, you can pull the per-site evidence straight into the reports your security team already produces.

Step 5: OT Patch Management for Sites That Are Offline

OT (operational technology) is the machines and control systems on a factory floor, and the computers that run alongside them. OT patch management has an extra constraint: some sites are disconnected on purpose, and some simply lose their link.

Let us be plain about it: a site without a connection gets the fix only after it reconnects. No platform can push an update over a link that is not there.

What leaders can do about the sites still waiting:

• List them. Every offline site should be on a named list, not missing from the report.
• Plan a next step for each. A maintenance window, a local visit, or temporary protection such as reduced network exposure.
• Set a limit. Decide how long a site may stay on the old version before it is escalated.

The Avassa Edge Platform is built for this situation. Communication is started from the site outward, so no inbound ports need to be opened in segmented OT networks, and the platform tolerates intermittent connectivity. Sites keep running their applications while offline. When a site reconnects after a long disconnection, the platform keeps driving it toward the declared state without anyone having to retry by hand, and it restarts interrupted transfers on its own. Offline sites stay visible as offline, so your list of waiting sites stays accurate.

Try a rollout and a rollback on a small group of sites, with an application you run.

Start Free Trial

Who Does What in Your Vulnerability Management Program

A clear split of responsibilities avoids the classic gap where everyone assumes someone else confirmed the fix. Here is how the work divides between your security tool, the Avassa Edge Platform and your own team:

Task	Security tool	Avassa	Your team
Find the weakness	Scans images and matches components against CVE data	Shows where each affected application version should run and where it is running	Confirms which findings apply to your applications
Decide what to fix first	Provides severity scores	Supplies site labels, such as criticality, and each application’s declared exposure	Makes the call and sets deadlines
Update the applications	Re-scans the fixed image before release	Rolls out the new version with canary sites, rolling batches, health checks and rollback	Builds and tests the fixed image, and approves the rollout
Confirm each site	Confirms the weakness is gone from the new image	Reports version and health per site, and shows which sites are waiting or offline	Follows up on every site that is not yet patched
Report to leadership	Provides vulnerability reports	Provides per-site status and an audit trail through the UI and API	Combines both into one report for leadership, auditors and customers

See how this applies to retail and industrial environments.

Conclusion

A CVE alert at hundreds of sites is answered in five steps: find the affected applications and sites, decide what to fix first, roll out in stages, confirm the result at every site, and keep a named list of offline sites until they catch up. Speed matters, and so does proof. “We sent the fix” is not an answer leadership, auditors or customers can use. “Every site runs the fixed version, except these two offline sites, which are planned” is.

This week, pick one application and ask for the list of sites running it, with the version on each. How long a trustworthy answer takes shows how ready you are for the next CVE.

Talk to the Avassa team about how application updates would work across your stores, factories or machines.

Book a Meeting

About the authors

This article was written by the Avassa team. Avassa builds the Avassa Edge Platform, used to deploy, update, monitor and secure containerized applications and AI models across hundreds or thousands of distributed sites, from stores and factories to machines and vehicles, without requiring Kubernetes at every edge site.