Scanning a static or CDN-hosted site means checking its dependencies, build tools, functions, scripts and hosting settings for known weaknesses. These ten answers cover what to scan, how often, and how to avoid drowning in alerts. Each links to a deeper post.
1. What should I scan first?
The lockfile. It lists exact package versions, including transitive ones, and matches how advisories are published. See scan the built output or the source repo.
2. Do build tools count?
Yes. They run with access to your CI environment. A flaw in a build tool can matter even if no visitor ever downloads it. See which dependencies ship and which are build-only.
3. How often should I scan?
On every pull request that changes dependencies, and on a schedule such as daily or weekly. New advisories appear against code you already deployed.
4. Are serverless functions in scope?
Yes, and they are often missed. They have their own manifests and often hold API keys. See scan serverless functions inside a static site repo.
5. What about scripts from other domains?
List them, assign an owner for each, and use iframes with sandbox where possible. See third-party embeds on a static site.
6. Does a high severity score mean I must fix it today?
No. Severity describes the flaw in general. Your priority depends on whether the vulnerable code runs in your site and whether it is exposed to untrusted input. A score alone does not answer that.
7. How do I cut false alarms?
Use reachability analysis to see which findings sit in code your project actually calls, and record a reason whenever you defer one. Review deferrals on a date.
8. Is a CDN a security tool?
A CDN reduces some availability risk and can add headers and rules. It does not patch your packages, and a shared cache can serve stale vulnerable files until purged. See purge the CDN cache after a security fix.
9. Do I need an SBOM for a static site?
An SBOM is a machine-readable list of what your build used. It is useful for rescanning later without rebuilding, and some customers ask for one. It takes minutes to generate once your scan is set up.
10. Where do I start if I have nothing?
- Inventory repositories, functions and external hostnames.
- Scan lockfiles and fix critical issues with known fixes.
- Add a pull request check.
- Add a scheduled rescan.
- Review headers and DNS records once a quarter.
Try it yourself
The reachability demo makes question 7 concrete. Compare the list before and after reachability filtering and note which findings drop in priority.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard offers dependency scanning, SBOM generation, reachability analysis and pull request policy gates. Start with the free scan at gold.safeguard.sh/scan.
Quick check
Do I need a paid tool for a small site?
Not necessarily. Many teams start with free scans and add tooling as the number of repositories grows.
What is the quickest improvement for a typical site?
Commit the lockfile, install from it in CI, and add a scan to pull requests.
Last reviewed: 19 October 2026.
