Scan rule · RSC-SEC-080
Dependencies with a known vulnerability
Matches the repository's package versions against the public OSV database and names the affected packages with advisory IDs.
Why this matters
A published vulnerability does not need a targeted attacker, only time. Advisories are public, come with sample code and are probed automatically at scale. The question is not whether someone finds the hole, but when a scanner passes your address.
Generated projects accumulate this especially fast. Versions sit in the repository exactly as the model knew them when scaffolding — and for an MVP, more time usually passes between scaffolding and launch than between an advisory and mass exploitation. Running `npm audit` is one of the things that simply never happens in a vibe-coded project.
Check it yourself: run `npm audit` or `bun audit` in the project directory. What matters is the difference between the installed version (in the lock file) and the version range in `package.json` — only the lock file says what actually runs. If the evidence says no lock file was present, the finding refers to the range, not to your actual state.
Scan tier
How to fix it
Raise affected packages to the patched version and set up a recurring update run.