Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add WPScan or Wordfence as analyzer or mirror #4598

Open
2 tasks done
valentijnscholten opened this issue Jan 28, 2025 · 1 comment
Open
2 tasks done

Add WPScan or Wordfence as analyzer or mirror #4598

valentijnscholten opened this issue Jan 28, 2025 · 1 comment
Labels
enhancement New feature or request

Comments

@valentijnscholten
Copy link
Contributor

Current Behavior

Currently Wordpress vulnerabilities are not covered completely by Dependency Tracks sources. If they have a CVE, the probably are detected.
But many plugins have vulnerabilities without a CVE (or GHSA, OSV, SNYK, .... ID).

Proposed Behavior

Popular sources for Wordpress vullnerabilities are

The problem with WPScan is that they do not allow any mirroring and do not allow even storing vulnerabilities. Unless you have a commercial enterprise license.

Wordfence seems to have almost the same (20k) vulnerabilities, but is completely free to use including mirroring.

There are some questions to be answered:

  • Vulnerabilities (WPScan + Wordfence) have a uuid as ID. This doesn't really look/fit very well in the DT UI;
  • Similar to my question in Composer Repository Vulnerability Mirroring #4515 (comment) is whether we should replicate all vulnerabilities as those which have a CVE are just copies of the vulnerability from NVD.

Checklist

@valentijnscholten valentijnscholten added the enhancement New feature or request label Jan 28, 2025
@nscuro
Copy link
Member

nscuro commented Feb 4, 2025

[...] whether we should replicate all vulnerabilities as those which have a CVE are just copies of the vulnerability from NVD.

I'd say same as #4515 (comment) for now.

Vulnerabilities (WPScan + Wordfence) have a uuid as ID. This doesn't really look/fit very well in the DT UI;

Honestly I wouldn't be too concerned about that. If a source picks UUIDs as IDs, then that's the reality we have to deal with.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants