Remove WPScan API vulnerability detection (detector/wordpress.go)

Summary

Remove the WPScan API vulnerability detection logic from detector/wordpress.go, including detectWordPressCves, wpscan, detect, match, convertToVinfos, and related configuration (config.WpScanConf).

Motivation

• No known OSS users: The WPScan API requires a token and no OSS users are configuring it through Vuls
• Maintenance burden: The WPScan HTTP client, version matching logic, CVE conversion, and rate limit handling (338 lines) add code that is not used in practice
• Clear separation of concerns: Vuls should focus on scanning (collecting what WordPress packages are installed) — vulnerability detection via external paid APIs is better handled externally

Scope

Remove

• detector/wordpress.go — WPScan API client, version matching, CVE conversion, rate limit handling
• detector/wordpress_test.go — Associated tests
• config.WpScanConf (WPScan token / DetectInactive flag)
• WordPress detection call in detector.Detect()
• errof.ErrFailedToAccessWpScan, errof.ErrWpScanAPILimitExceeded

Keep

• Scanner (scanner/base.go) — wp-cli integration (detectWordPress, detectWpCore, detectWpPlugins, detectWpThemes) remains as-is. Collecting installed WordPress packages is a core scanning function
• Models — models.WpPackage, models.WordPressPackages, models.WpPackageFixStats remain for ScanResult JSON compatibility
• SBOM output — CycloneDX, SPDX, and PURL conversion for WordPress packages (reporter/sbom/)
• Reporter/TUI — WordPress package display in text output and TUI
• Scan module config — config.WordPressConf (wp-cli path, docroot, osuser) and config/scanmodule.go WordPress flag

After this change

OSS Vuls will continue to collect WordPress package inventory (core version, plugins, themes with status) via wp-cli and output them in scan results and SBOM formats. It will no longer perform vulnerability lookups against the WPScan API.

Related

• #2484 (Remove GitHub Advisory detection)