How do you ship a patched dependency to Lambda@Edge?

To ship a patched dependency to Lambda@Edge, rebuild the package with the updated library, publish it as a new numbered version, and point the CloudFront association at that version. AWS requires a numbered version rather than $LATEST or an alias, and Lambda@Edge supports only the Auto runtime management setting.

Two kinds of update, two owners

A Lambda@Edge function has code from two places. The runtime is AWS's, and the packages in your zip are yours. AWS's Node.js packaging guidance states the split plainly: under the shared responsibility model, you manage the dependencies in your deployment package, including updates and security patches.

For the runtime, AWS documents that Lambda@Edge does not support runtime management configurations other than Auto. Auto is the default, and AWS's version documentation notes that in Auto mode the runtime version used by a function version is updated automatically. So you do not need to decide between Auto, Function update and Manual here. You get Auto.

That is helpful, but it only covers the runtime. It does not touch anything inside your package.

The patch workflow, step by step

1. Update the dependency in the source repo. Change the version in the manifest and regenerate the lockfile.
2. Build the zip from the lockfile. Use a clean install so no stale packages sneak in.
3. Scan the built artifact. Confirm the vulnerable version is gone and nothing new appeared.
4. Deploy to $LATEST. AWS notes that code and most settings can only be changed on the unpublished version.
5. Publish a numbered version. Published versions lock their code, runtime, layers and most settings, per the AWS versions page. Lambda never reuses a version number.
6. Update the CloudFront cache behavior to use the new version's ARN, with the version suffix. AWS states the function must be in US East (N. Virginia).
7. Verify at the edge. Request a test path and confirm the behavior you expect.

Because published versions are immutable, the old version still exists after step 6. It is no longer associated, but it is worth confirming that no other distribution still points to it. See our note on old versions and aliases still running vulnerable code.

What about deprecated runtimes

AWS says you cannot create or update Lambda@Edge functions with deprecated versions of Node.js. You can only associate existing functions with those versions, and functions with those versions that are already associated keep running. That is a quiet trap. A function can look healthy while sitting on a runtime nobody can update. The cure is to schedule a runtime move before the deprecation date, not after.

Make the patch loop measurable

Track two numbers for every edge function: the date its newest dependency update was published, and the version currently associated with each distribution. When the second number lags behind the first, a patch is stuck somewhere.

Try it yourself

The dependency inventory demo shows how an SBOM answers the third row. Click a package and see where it is used.

Click through it at your own pace, or open it full screen.

Where Safeguard fits

Safeguard produces an SBOM and scans dependencies on each build, and its autonomous remediation can open a fix pull request when a patched version exists. That feature is off by default with every category on Manual, so a person approves each change. Try a free scan at gold.safeguard.sh/scan.

Quick check

Sources

• Restrictions on Lambda@Edge, AWS documentation
• Manage Lambda function versions, AWS documentation
• Deploy Node.js Lambda functions with .zip file archives, AWS documentation

Last reviewed: 19 October 2026.