The Patch That Nobody Owned

The situation

A logistics company runs a shipment-tracking platform in one AWS account, and a security advisory arrives on a Monday morning. A widely used library has a remote code execution vulnerability, rated critical, with an exploit already circulating.

The library appears in five places across the estate:

• On 22 EC2 instances running the tracking API, installed as an operating system package.
• Inside the Amazon RDS for PostgreSQL instance, as a dependency of the engine build itself.
• Bundled into the runtime under six AWS Lambda functions that process shipment events.
• Inside the container image for four AWS Fargate tasks running a reporting job.
• In a third-party network appliance bought through AWS Marketplace and running as an EC2 instance in the inspection subnet.

There is also an Amazon S3 bucket holding fifteen years of signed delivery manifests, and the compliance officer has asked whether it is affected too.

The security manager needs a written answer by Friday saying which of those six things the company has to act on, which AWS handles, and what evidence exists either way.

What actually matters

The question underneath all six is the same one: at which layer does the vulnerable library sit, and who operates that layer. AWS is responsible for security of the cloud, which is the infrastructure, the hardware, the facilities and the software that AWS itself runs. The customer is responsible for security in the cloud, which is everything the customer puts there and everything they configure. The line does not sit in a fixed place. It moves according to how much of the stack the service takes over, and each of these five services takes over a different amount.

The useful way to see it is as a stack with a cut through it. Below the cut, AWS operates the layer and patches it. Above the cut, the company operates the layer and patches it. On EC2 the cut sits just under the guest operating system, so every package inside that operating system is the company’s. On a managed database the cut sits above the engine, so the engine build is AWS’s. Under a Lambda function the cut sits directly under the function code, so the runtime and everything below it is AWS’s.

The part people get wrong is assuming that “AWS patches it” means “nothing is required of us”. Managed services publish maintenance windows and version deprecations, and applying an available patch is often a customer action even when producing that patch is not. A managed database that has a patched engine version available and is still running the old one is exposed, and the exposure belongs to whoever chose not to apply the upgrade. The same holds for a Lambda runtime past its deprecation date, after which AWS may stop issuing security patches for it.

There is also a category that looks managed and is not. Software bought through AWS Marketplace runs in the customer’s account under the customer’s control; the vendor supplies updates, but installing them is the customer’s job, and the delivery model does not change that.

Finally, three things stay with the customer no matter which service is involved: the data, who can reach it, and how it is classified. The S3 question is answered by that rule rather than by anything about the library.

What we’ll filter on

1. Where the vulnerable code sits in the stack: hardware, hypervisor, guest OS, runtime, engine, or application.
2. Whether producing the fix is AWS’s work or the company’s.
3. Whether applying the fix is AWS’s work or the company’s, which is not always the same answer.
4. Whether any configuration the company controls changes the exposure.
5. What evidence the security manager can put in the Friday report.

The landscape

EC2 hands over the hardware, the facilities and the hypervisor. Everything from the guest operating system upwards is the company’s: the OS packages, the patching schedule, the host firewall, the application, and the data on the volumes. A vulnerable OS package on an EC2 instance is unambiguously the company’s to fix.

Amazon RDS takes the operating system and the database engine as well. AWS patches the engine and the underlying OS and publishes those patches through maintenance windows and engine version upgrades. The company still owns the database users and their grants, the network path to the instance, the encryption choice made at creation, and the contents. A vulnerability in the engine build is AWS’s to fix. Applying the resulting version is a scheduling decision the company makes, within a limit: RDS marks an update available, which it never installs on its own, or required, which carries an apply date after which RDS installs it during a maintenance window.

AWS Lambda takes everything under the function: the operating system, the language runtime, the scaling, and the underlying compute. The company owns the function code, the libraries it packages with that code, its IAM role, and its environment variables. That split cuts straight through the case here, because the same library can be either an AWS-managed runtime component or something the deployment package brought with it, and the two have different owners.

AWS Fargate removes the instance and the operating system from the company’s list, which is what distinguishes it from running containers on EC2. It does not remove the container image. Everything inside that image is built and chosen by the company, so a vulnerable library baked into the image is the company’s, exactly as it would be on EC2.

Amazon S3 takes the storage infrastructure, the durability, and the service software. The company owns the bucket policy, Block Public Access, the encryption choice, object-level permissions, and the objects themselves. Nothing about an operating system package applies to it.

AWS Marketplace software runs in the company’s account. The vendor supplies the product and its updates, and the company installs them, monitors the appliance, and operates it. Buying software through a marketplace changes procurement, not responsibility.

Evaluation

Side by side

Where it appears	Layer the library sits in	Who produces the fix	Who applies it	Company action by Friday
22 EC2 instances, OS package	Guest operating system	The OS vendor	Company	✓
RDS for PostgreSQL, engine dependency	Database engine	AWS	Company schedules it, or RDS after the apply date	✓
Six Lambda functions, in the deployment package	Function code and its libraries	Company	Company	✓
Six Lambda functions, in the managed runtime	Runtime, below the function	AWS	AWS	✗
Four Fargate tasks, in the container image	Container image	Company	Company	✓
Marketplace appliance on EC2	Third-party application	The vendor	Company	✓
S3 manifests bucket	Not applicable	n/a	n/a	✗

The Lambda row splits into two because the same library name can arrive by two different routes, and the route settles the owner. On Lambda, anything in the deployment package is the company’s and anything in the managed runtime is AWS’s.

The RDS row is the one that looks like a no and is a yes. AWS produced the patched engine build, and the company still chooses when this instance restarts into it, up to the apply date on a required update.

What stays with the customer regardless

Concern	Owner	True on EC2	True on RDS	True on Lambda	True on S3
The data itself	Customer	✓	✓	✓	✓
Who can access it (IAM, policies, grants)	Customer	✓	✓	✓	✓
Classification and retention	Customer	✓	✓	✓	✓
Encryption choice and key management	Customer	✓	✓	✓	✓
Network exposure and public access settings	Customer	✓	✓	✓	✓
Physical security of the facility	AWS	✓	✓	✓	✓

Every row but the last is the customer’s on every service in the estate. The more managed the service, the shorter the customer’s list becomes, and it never becomes empty.

The solution

Deal with the EC2 instances first, since they are the largest exposure and entirely the company’s. AWS Systems Manager Patch Manager applies the vendor patch across all 22 instances on a defined schedule, with a patch baseline saying which severities get installed automatically. Amazon Inspector scans the instances continuously and reports which of them still carry the vulnerable package, which turns “we patched them” into a list with instance IDs against it. That list is the evidence the Friday report needs.

For RDS, open the pending maintenance actions for the instance, in the console under Maintenance & backups or through describe-pending-maintenance-actions. That view separates the two cases above: an available update is never installed for you, and a required one carries an apply date. Either let the next maintenance window take it or apply it immediately with Patch now if the severity warrants not waiting. The written answer for this row is that AWS produced the fix and the company scheduled it, which is a different sentence from “AWS handled it”.

The Lambda functions need the deployment packages inspected rather than assumed. If the library was packaged with the function code or supplied through a Lambda layer the company built, the company rebuilds and redeploys. If it is part of the AWS-managed runtime, Lambda publishes the patched runtime and applies it automatically, which is the default unless somebody has switched that function’s runtime management setting to manual. Two conditions still attach. The function has to be on a runtime that has not passed its deprecation date, and a function deployed as a container image is the company’s to rebuild from the updated base image rather than Lambda’s to patch in place.

The Fargate tasks are a rebuild. Fargate removed the instance and the operating system from the company’s responsibilities and left the image exactly where it was. Rebuild the image against a patched base, push it to Amazon ECR, and redeploy the service. With Amazon Inspector enhanced scanning turned on for the registry, images are scanned on push and rescanned as new CVEs are published, so the registry reports whether the new image is clean.

The Marketplace appliance goes to the vendor for a patched version, and the company installs it. Buying through Marketplace means the billing runs through the AWS account; the appliance is still an EC2 instance in the company’s VPC that the company operates.

The S3 bucket is unaffected by this advisory, and the answer to the compliance officer is worth writing carefully rather than as a single word. The library is not present in S3, so there is nothing to patch. What is present is fifteen years of signed manifests whose protection is entirely the company’s: Block Public Access, the bucket policy, the encryption setting, and who holds the permissions. Those controls should be checked, because the question behind “is the bucket affected” is usually “is the data safe”, and that question never moves to AWS.

Two things belong in the report regardless of the six rows. AWS Artifact supplies the SOC, PCI and ISO reports covering AWS’s side of the line, which is what an auditor asks for when they want assurance about the parts the company cannot inspect, and it carries security documents from Marketplace sellers too. AWS Security Hub CSPM, which held the plain Security Hub name until AWS moved that name to its newer unified service, aggregates the Inspector findings, the AWS Config rule results and the rest into one view. The next advisory then starts from an assembled picture rather than a fresh inventory.

What’s worth remembering

1. AWS is responsible for security of the cloud (hardware, facilities, the virtualisation layer, and the software AWS runs); the customer is responsible for security in the cloud (what they put there and how they configure it).
2. The line moves with the service: on EC2 the customer patches the guest OS; on RDS and Lambda, AWS patches the engine, the OS and the runtime; on Fargate, AWS takes the instance and the OS and the customer keeps the container image.
3. Producing a patch and applying it are separate responsibilities. A managed service can supply the fixed version while the customer still decides when to take it.
4. Anything the customer packages with a Lambda function, including a layer they built, is theirs; the managed runtime beneath it is AWS’s, and only until that runtime reaches its deprecation date.
5. Software bought through AWS Marketplace runs in the customer’s account and is the customer’s to operate and update, whatever the billing arrangement.
6. The data, who can access it, and how it is classified stay with the customer on every service without exception, so the customer’s list gets shorter with more managed services and never becomes empty.