I mostly don’t care about known vulns in dependencies. I appreciate code quality and want to maintain a recency of at least 1-2 semver minor versions for packages. But so many of those vulns are distractions that don’t require prioritization over normal maintenance – things like XSS in unused code paths, reDoS, malicious config files, and exploit scenarios that require the planets to align in a great conjunction.

I’d rather know about one version to upgrade to than a list of security issues with questionable impact whose remediation spans a range of versions. (I also wish scanners would roll up findings into a single “apply this patch” recommendation.)

What I wish existed was a scaleable, well-supported scanner that enumerated all runtime dependencies and let me define alerting rules based on:

  • the distance from the most recent semver minor version
  • the distance from the most recent semver major version
  • the days since that most recent major/minor version
  • the days until a known EOL such as tracked in endoflife.date

Then for the dimension of known vulns I’d prioritize the CISA KEV along with malicious packages, i.e. packages delivered from a trusted source, but whose contents have been compromised. For the latter, think of packages from package repo, such as XZ Utils or an NPM package that included a malicious commit.

Yes, not every package follows a clean semver, but I’d love to bury the patch-all-the-vulns mentality that comes from being able to identify every single CVE in existence and instead raise a regular maintenance routine that accommodates the meaningful vulns.

We can even keep the SCA vendor category – just call it Semver Creation Analysis or maybe Semver Curation Approach instead. ;)