Your coding tool adds packages as it goes, and each one brings its own dependencies. When a vulnerability is published for one of them, the fix is usually a version bump, and an app that never makes it stays exposed. A known vulnerable package with a published fix is the easiest way in.
Find them
- Turn on dependency alerts in your repository host’s security settings. They watch every package in your lockfile and alert you when an advisory is published.
- Run an audit now with the prompt below, so you are not waiting for the next alert.
- Record each result: the package, the installed version, the advisory id, its severity and the fixed version.
Ask your coding tool to audit
Run the package manager audit for this repository (for example npm audit, pnpm audit or yarn npm audit) and show me the raw output. Do not change any files and do not fix anything yet. Then list each vulnerable package as: package, installed version, advisory id, severity, fixed version. Only list advisory ids that appear in the audit output; never guess one.
Fix them by deadline
- Each advisory carries its own severity. Fix a critical within 7 days, a high within 30 and a medium within 90. A known malicious package is critical: remove it today.
- Upgrade to the fixed version named in the advisory, run your package manager install, and commit the lockfile with the change.
- If the vulnerable package is a dependency of a dependency, upgrade the package that pulls it in, or use your package manager’s override setting.
- If no fixed version is published yet, note it, check whether your app uses the affected feature, and look again in a week.
Prove it
Run the audit again after the change. The fix is done when the advisory no longer appears and the dependency alert closes. Keep the date: that is your evidence.
Ask your tool never to name an advisory id it did not see in the audit output. A made-up id wastes your time and hides the real ones.