An edge function dependency review should check seven things: the inventory of packages, size against the platform limit, runtime compatibility, secrets handling, how patches ship, the runtime support date, and a named owner. Do it at creation and again on a schedule, because edge code is easy to forget.
1. Inventory
Write down every package, direct and transitive, from the build lockfile. A hand-written list goes stale. Generate it from the build and store it with the release.
2. Size against the limit
Compare the built artifact with the documented limit: 10 KB for CloudFront Functions code and libraries, 50 MB for Lambda@Edge, 1 to 4 MB gzipped on Vercel's Edge runtime depending on plan, and 64 MiB uncompressed for Cloudflare Workers. Read how size limits shape dependency choices. A function near its limit is a function that gets pressure to hide code.
3. Runtime fit
Each platform restricts what code can do. Vercel disables eval and new Function and allows only ES module packages without native Node.js APIs. CloudFront Functions do not support dynamic code evaluation. Test every dependency on the real runtime. See why edge runtimes block eval.
4. Secrets and configuration
Lambda@Edge does not support custom environment variables, per AWS, so teams are tempted to bake values into the bundle. Search the built output for tokens and keys. Keep secrets out of the artifact and fetch them at run time with a narrow permission.
5. How a patch ships
| Platform | Patch path |
|---|---|
| Lambda@Edge | Rebuild, publish a numbered version, update the CloudFront association |
| Workers | Rebuild with Wrangler and redeploy |
| Vercel | Rebuild and redeploy the project |
Write the path in the runbook so nobody has to rediscover it during an incident. For Lambda@Edge details, see shipping a patched dependency.
6. Runtime support date
Record the runtime and its end of support date. AWS says deprecated Node.js versions cannot be used to create or update Lambda@Edge functions. Vercel says it recommends migrating from edge to Node.js, so check the platform direction too.
7. Owner
Every function needs a person or team and a way to reach them. An unowned edge function that sits in front of production traffic is the one that stays vulnerable longest.
The checklist in one table
| Item | Question | Evidence |
|---|---|---|
| Inventory | Do we have the full package list? | SBOM from the build |
| Size | Under the limit with room to spare? | Build output |
| Runtime fit | Tested on the real runtime? | Preview deployment result |
| Secrets | Is the bundle free of keys? | Manual search and a policy |
| Patch path | Is it written down and tested? | Runbook |
| Support date | Is the runtime supported for 12 months? | Platform docs |
| Owner | Is someone accountable? | Inventory record |
How often
Review at creation, on every major dependency change, and at least twice a year. Tie the review to the runtime end date so it is not optional.
Try it yourself
Use the gate pull request demo to see how items in this list can become automated checks that block a change.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard's policies and gates can enforce parts of this checklist in pull requests, and its SBOM and dependency scanning supply the inventory. Free scan: gold.safeguard.sh/scan.
Quick check
How often should I review an edge function?
At creation, on major dependency changes, and at least twice a year, tied to the runtime end date.
What is the most commonly missed item?
The owner. Unowned edge functions tend to stay unpatched the longest.
Sources
- Differences between CloudFront Functions and Lambda@Edge, AWS documentation
- Restrictions on Lambda@Edge, AWS documentation
- Edge Runtime, Vercel documentation
- Limits, Cloudflare Workers documentation
Last reviewed: 19 October 2026.
