Question 1

Is it a direct or transitive dependency?

Accepted Answer

Direct dependency (you control the version):
  package.json:  "express": "^4.17.0"
  Fix: Bump version in your manifest. Usually straightforward.

Transitive dependency (someone else controls the version):
  your-app → some-framework → vulnerable-lib@1.2.3
  Fix: More complex. See ecosystem-specific strategies below.

Direct dependencies are straightforward — bump the version in your manifest file. Transitive dependencies are trickier because you don't directly control the version. You'll need to use ecosystem-specific override mechanisms or wait for the parent package to update.

Question 2

Does the fixed version have breaking changes?

Accepted Answer

Check the changelog or release notes of the target version. A patch release (4.17.1 → 4.17.2) is almost always safe. A minor release (4.17 → 4.18) is usually safe but deserves a test run. A major release (4 → 5) will likely require code changes.

Question 3

Is the vulnerability reachable in your code?

Accepted Answer

Not all vulnerable code paths are exercised by your application. If you can confirm the vulnerability isn't reachable (the affected function is never called), you can lower the priority — but still patch it eventually. Don't use reachability as an excuse to never patch.

Question 4

How do I handle a vulnerability when no patched version exists?

Accepted Answer

Apply a workaround (WAF rule, configuration change, or code-level mitigation), document it, and set a calendar reminder to check weekly for a patch release. If the vulnerability is on CISA KEV with no patch available, escalate to your security team — you may need to disable the feature or switch libraries entirely.

Question 5

Should I automate remediation?

Accepted Answer

Automate cautiously. Automated version bumps for patch releases (semver patch) are generally safe and worth automating. Minor version bumps should generate PRs for human review. Major version bumps should never be automated — they require manual assessment of breaking changes.

Question 6

What if upgrading breaks our application?

Accepted Answer

If your test suite catches the breakage, you have two options: fix your code to work with the new version (preferred) or use an override to pin the secure version while you plan the migration. Don't revert the security patch and leave the vulnerability open — find a path forward.

Question 7

How do I track remediation progress across multiple projects?

Accepted Answer

Use your scanner's dashboard to track findings across projects over time. Key metrics: mean time to remediate (MTTR) for KEV entries, percentage of findings resolved within SLA, and trend of open findings over time. If MTTR for KEV entries is above 48 hours, your remediation process needs work.

Question 8

What's the difference between remediation and mitigation?

Accepted Answer

Remediation removes the vulnerability (typically by upgrading to a patched version). Mitigation reduces the risk without removing the root cause (WAF rules, configuration changes, network controls). Remediation is always preferred. Mitigation is a temporary measure when remediation isn't immediately possible.