Find every manifest in the repository, including the one inside the functions folder, scan each as a separate project, and fail pull requests that add serious known vulnerabilities. A scan of the root alone often misses the functions, which usually carry their own dependencies.
Why functions get missed
A static site repo looks simple. A site generator config sits at the root and content sits in folders. Then someone adds a function for a form, a search endpoint or a webhook. It gets its own package manifest, its own lockfile, sometimes its own runtime version. The scanner is pointed at the root, and the function never appears in a report.
Step by step
- Find all manifests. Search the whole tree, excluding the installed packages folder, for manifest and lockfile names used by your languages. List each directory that has one.
- Decide what is a project. A functions folder with its own manifest is its own project. Give it its own name in your scanner so findings do not blend with the site build.
- Scan from lockfiles. Lockfiles list exact resolved versions, including transitive packages. A manifest alone lists ranges, so results can differ from what actually deploys.
- Label runtime. Mark each project as build, shipped to browser, or server runtime. Functions are server runtime, and they often hold credentials that a build bundle never sees.
- Review permissions next to dependencies. What can the function reach? An email API key, a storage bucket, a database? A vulnerable package matters more in a function that holds broad access.
- Gate on pull requests. Run the scan on every change that touches a manifest or lockfile, and block merges that introduce critical findings you cannot justify.
- Rescan on a schedule. Functions can sit untouched for months while new advisories appear against their packages.
What a useful report shows
| Field | Why you want it |
|---|---|
| Project and path | So the owner can find the code |
| Direct or transitive | Tells you what you chose and what came along |
| Fixed version | Turns a finding into an upgrade task |
| Reachability | Shows whether your function actually calls the vulnerable code |
| Runtime label | Separates browser risk from server risk |
Keep the function small
The safest dependency is one you do not add. Before importing a package for one small task, check whether the platform runtime already offers it. Fewer packages means a shorter advisory list and quicker upgrades.
Try it yourself
In the dependency inventory demo, expand a package to see how a transitive entry connects back to something you installed. Imagine the same view for a functions folder.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard scans dependencies across a repository, supports policy gates on pull requests, and can open fix pull requests when you turn that on. It is off by default and every category starts on manual approval. Try the free scan at gold.safeguard.sh/scan.
Quick check
Can I use one lockfile for the site and the functions?
You can in a monorepo with workspaces, but scan each workspace as its own project so findings keep the right owner and runtime label.
Should functions be scanned more often than the site?
Often yes, because they run on a server with credentials. A weekly rescan is a sensible floor.
Last reviewed: 19 October 2026.
