In my previous post, I wrote about Azure Container Apps as a runtime layer for composable headless architectures.
One question that came up afterwards was very practical: How do you keep the container images running in Azure Container Apps secure and up to date?
That is an important question. Once you run frontends, APIs, workers, jobs and integrations as containers, the security of those workloads depends heavily on the images you deploy. But there is an important nuance. The goal is not to automatically update production every time a new image is available. The goal is to automate the image lifecycle while keeping production promotion controlled.
Security automation should help you move faster. It should not silently replace production with an unvalidated runtime.
Containers are not patched in place
A container image can become vulnerable even when your own application code has not changed. A CVE can be found in the operating system layer. A base image can receive a security update. A framework or package dependency can become vulnerable.That means container image security is not a one-time deployment task. It is a continuous process.
The principle is simple: You do not patch a running container. You rebuild the image, validate it, and promote a new version.
Microsoft Defender for Cloud can help detect vulnerable images and make security findings visible. The actual remediation still belongs in your delivery process. More background: view and remediate vulnerabilities for registry images.
Do not use latest in production
One of the easiest ways to create production risk is to deploy with a mutable tag such as latest.It looks convenient, but it reduces traceability. If production runs:my-app:latest. Which build is that? Which commit created it? Which scan result belongs to it? Which version is actually running?
It can also create inconsistent runtime behaviour. New replicas may pull the new meaning of latest, while existing replicas still run the previous image behind the same tag. For production, use a unique image tag or deploy by digest:
myregistry.azurecr.io/my-app:build-1042
or:
myregistry.azurecr.io/my-app@sha256:...
The architectural point: production should point to an exact image version, not to whatever a mutable tag happens to mean at startup time.
Microsoft has more details here: image tag best practices.
The architectural point: production should point to an exact image version, not to whatever a mutable tag happens to mean at startup time.
Microsoft has more details here: image tag best practices.
Automate rebuilds, not production replacement
When a CVE is detected, automation should do the repetitive work.
A patched image can still break the application. The base image may behave differently. The runtime may have changed. A package update may introduce a breaking change.
So the split should be clear:Automatic: detect → rebuild → scan → sign → deploy to staging → test Controlled: approve → deploy exact image to production → monitor → rollback if needed
For rebuild automation, Azure Container Registry Tasks can help, especially when base images are updated: ACR Tasks and base image updates.
For production control, use the approval mechanisms of your delivery platform:
The important architectural point is that the build process should not automatically have the right to update production.
- It should rebuild the image.
- It should scan the image.
- It should sign the image.
- It should deploy the image to staging.
- It should run tests.
A patched image can still break the application. The base image may behave differently. The runtime may have changed. A package update may introduce a breaking change.
So the split should be clear:Automatic: detect → rebuild → scan → sign → deploy to staging → test Controlled: approve → deploy exact image to production → monitor → rollback if needed
For rebuild automation, Azure Container Registry Tasks can help, especially when base images are updated: ACR Tasks and base image updates.
For production control, use the approval mechanisms of your delivery platform:
The important architectural point is that the build process should not automatically have the right to update production.
Use revisions where they fit
Azure Container Apps has a useful deployment concept: revisions.When you deploy a new image, Azure Container Apps can create a new revision. For HTTP workloads, that revision can be tested, routed to and rolled back from. That makes it useful for controlled rollout patterns such as blue-green deployments or gradual traffic shifting.
More background:
Architecturally, this means you do not have to think in terms of “replace the app”. You can think in terms of “introduce a new revision”. That is especially useful under security pressure. You can move quickly, but still keep production controlled.
Be careful with workers and jobs
One caveat is important. Not every Container App should be rolled out in the same way. Traffic splitting works well for HTTP workloads because incoming traffic can be routed between revisions.For workers, queue consumers and integrations, that is different. If two worker revisions are active at the same time, both may consume messages. That can be fine, but only if the worker is designed for it.
More background: application lifecycle management in Azure Container Apps.
The architectural rule is simple:
A frontend, an API, a worker and a scheduled job may all run on Azure Container Apps, but they do not all need the same release strategy.
Sign and promote exact images
In more mature environments, I would also include image signing. This helps prove which image was approved and promoted. Be aware that Docker Content Trust is being phased out in Azure Container Registry. Microsoft is moving towards the Notary Project and Notation. More background: transition from Docker Content Trust to Notary Project.The architectural point is simple: Production should run an exact, traceable, validated image.
- Not a moving tag.
- Not whatever was latest at the time.
- Not an image that skipped the release process.
My conclusion
Keeping Azure Container Apps secure is not about magically updating running containers.It is about rebuilding, validating and promoting exact image versions through a controlled process.
Automate the parts that should be automated: detect → rebuild → scan → sign → deploy to staging → test
Control the parts that affect production: approve → deploy exact image to production → monitor → rollback if needed
That is the balance I would aim for. Move fast on CVEs. But do not turn security automation into blind production automation.
Control the parts that affect production: approve → deploy exact image to production → monitor → rollback if needed
That is the balance I would aim for. Move fast on CVEs. But do not turn security automation into blind production automation.