News
OSV Lockfile Advisories vs a Public URL OPSEC Scan
January 3, 2025
OSV lockfile advisories vs a public URL OPSEC scan are two inventories. A URL roast sees what browsers already get: headers, cookies, mixed content, path leaks, and secret-shaped strings in public JavaScript. An OSV match on package-lock.json says a pinned npm version appears in a known advisory database. That is a triage queue, not a proof the bug is reachable on your origin. RoastMyOpsec's optional GitHub deepen reads package-lock.json on a repo you authorize (up to a bounded set of packages) and queries OSV. It does not run exploits, does not parse every lockfile format, and a URL-only scan cannot see node_modules at all.
The practical difference
The costume is HTTP. The dressing room is the lockfile that built the costume. A clean CSP with a lockfile full of unpatched lodash advisories is still homework. A patched lockfile with .env on the CDN is still an incident. You fix the surface that leaked.
OSV IDs are labels. Reachability, authz, and whether the vulnerable function ships to production are engineering work after the roast.
How to choose what to run
Shipped a marketing site this week: URL mode first. Same team builds from GitHub with npm: deepen that repo, not a random package. If the lockfile is Yarn or pnpm, the current deepen may be inconclusive — enable Dependabot or equivalent for that format and still roast the URL.
| Question | URL roast | OSV on lockfile | Takeaway |
|---|---|---|---|
| Missing HSTS / CSP | Yes | No | HTTP is the source of truth |
| Known CVE in a pinned npm version | No | Yes, if package-lock.json is readable | Triage; do not skip headers |
| Secret in public JS | Yes | Only if it is also a dependency name | Rotate; see JS-secrets guide |
| Exploitability in prod | Not claimed | Not claimed | Neither tool is a pentest |
What deepen actually does
It reads default-branch package-lock.json through the GitHub API, samples up to 100 package/version pairs, and asks OSV whether those versions have known vulns. History, yarn.lock, and whether webpack tree-shook the function are out of scope. Enable push protection and dependency alerts in GitHub regardless of the roast.
Common mistakes
The first mistake is ignoring OSV hits because the URL score was 9/10.
The second mistake is treating every advisory as a production incident without reachability.
The third mistake is deepening a demo repo that is not what deploys roastmyopsec's target URL.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Does a URL scan replace npm audit?
- No. The public site cannot see your lockfile. Use GitHub deepen or your own CI advisory tools on a repo you own.
- If OSV matches, is the site hacked?
- No. It means a known advisory exists for a locked version. Patch, then decide reachability. The roast does not exploit it.
- Why was the dependency check inconclusive?
- No package-lock.json, or a lockfile format deepen does not parse yet. Use Dependabot/Renovate for that ecosystem and still run the URL audit.