Dependency scanning fits serverless best, because each function bundles its own packages. Static analysis works per function. Dynamic scanning only reaches functions behind an HTTP endpoint. Add input testing for every event source, since a function can be triggered by more than web requests.
What makes serverless different to test
A serverless app is many small functions wired to triggers: HTTP routes, queue messages, file uploads, scheduled jobs. Three traits change the testing picture.
- Each function ships its own dependencies. The same vulnerable package can be bundled into dozens of deployments, so inventory matters.
- Inputs arrive from many sources. A queue message or a storage event is still untrusted input, even though no browser is involved.
- There is no host to scan. The platform runs the runtime, so your risk sits in your code, your packages and your permissions.
How each method behaves
| Method | Fit | Notes |
|---|---|---|
| Dependency scanning | Strong | Scan each function's lockfile or bundle, and re-scan deployed artifacts |
| Static analysis | Good | Works on function source. Cross-function data flow through queues is hard for any tool to follow |
| Dynamic scanning | Partial | Reaches HTTP triggered functions only. Event driven paths are invisible to a crawler |
| Interactive testing | Limited | Depends on agent support for the function runtime and short lived execution |
| Fuzzing | Good for parsers | Pull the handler logic into a testable function and fuzz it locally |
The fuzzing and testing advice rests on one design habit: keep handler code thin, and put the logic in plain functions you can call from a test.
A practical order
- Inventory every function and its dependencies. If you cannot list them, you cannot patch them.
- Scan bundles, not just source. The deployed artifact can differ from the repository.
- Review permissions. An over-broad execution role turns a small bug into a large one. This is configuration review, not code scanning.
- Unit test hostile inputs for each event type: empty, oversized, malformed, wrong type.
- Run a dynamic scan against the HTTP routes in a non-production stage.
- Fuzz any function that parses files or custom formats.
Gaps people forget
- Function timeouts and retries can repeat a harmful action. Test idempotency.
- Environment variables and secrets stores need access control, which no code scanner checks.
- Third-party layers and shared libraries are easy to skip in inventories.
Where Safeguard fits
Safeguard handles the inventory and dependency part: SBOM and dependency scanning across repositories and container images, reachability analysis to prioritise, and gates on pull requests. It does not test cloud permissions or event handlers. Try the free scan at https://gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Container-packaged functions can be inspected the same way, so watch how layers and packages are listed.
Quick check
Can a dynamic scanner test my queue-triggered function?
Not directly. It sends web requests. Test queue handlers with unit tests and crafted messages.
What is the first thing to do for a serverless app?
List every function and the packages it ships. Patching starts from that list.
Last reviewed: 19 October 2026.
