Your service runs on a managed runtime whose host and execution environment the provider patches — which software do you still patch?

## What the tier actually covers A managed runtime is a hand-over of two layers. The provider takes the host operating system, which you cannot log into, and the execution environment your process runs inside, including its security fixes. In exchange it takes away host access. What it does **not** take is the thing you deployed, because that is the only part the provider did not install. ## The three layers still above the line - **Your own application code.** Obvious, and rarely the one that is missed. - **The third-party libraries your build resolved and bundled.** These entered the artifact at build time. To the platform they are indistinguishable from your code, because they are your code as far as the deployment boundary is concerned. - **Anything else baked into the artifact.** If you handed over an image rather than source, whatever system packages, tools and utilities you layered into it came from you. A provider patching its own base layers does not reach into the layers you added on top. ## Why the gap is invisible This is the shape of the failure that makes the question worth asking. Nothing signals it: 1. The provider's status and patch notes are current, because the layers it owns genuinely are patched. 2. The platform reports the deployment healthy, because health checks test whether the service responds, not what is inside it. 3. The artifact was built once and has been running unchanged ever since, so the moment it went stale has no event attached to it. 4. The team's mental model says "managed", and "managed" gets read as "somebody is watching all of it". A long-lived deployment on a managed runtime can therefore be simultaneously fully patched below the line and months behind above it, with no signal anywhere in the platform. ## What you do about it The only patching motion available above the line is **rebuild and redeploy**. There is no host to log into, no package manager to run against a live instance, and on many managed runtimes the filesystem the process sees is not durable anyway. That has a design consequence worth saying out loud: your deployment pipeline is the patch mechanism for everything above the line. If a rebuild is slow, manual or rare, then your patch latency for your own dependencies is slow, manual and rare, whatever the provider's cycle looks like. Two practical corollaries: - **Deployment frequency and patch latency are the same number.** A service redeployed weekly picks up a dependency fix in at most a week. A service that has not been rebuilt in a year is a year behind, on a platform advertised as managed. - **Rebuilding without re-resolving changes nothing.** If the build reproduces the exact same pinned set every time, a redeploy ships the same vulnerable component again. Something has to move the pins for the rebuild to carry a fix. ## Where this sits in the responsibility model It is the clearest illustration of the general rule: **the provider patches what it installed, and you patch what you shipped.** The tier changes which layers fall on which side of that sentence; it never changes the sentence. On a rented machine the guest system's packages are yours because you were handed the guest. On a managed runtime the guest is gone from your side of the line, but the artifact you supplied took its place. It also explains why "we use a managed runtime" is not an answer to "how do you handle vulnerable components". The two statements are about different sides of the line, and treating one as covering the other is the specific mistake this question exists to catch. ## How to answer it Name the two layers the provider took, name the three that remain, and then say the thing that makes it a real answer rather than a recitation: the failure is silent, and the only remedy is a rebuild, which makes your release cadence the real patch cadence for everything you shipped.