WPScan checks the installed plugin, theme, and core versions against its vulnerability database and writes the latest result set into wp_options entries like wpscan_vuln_data and wpscan_scan_history. Per-scan detail lives in transients that expire on the schedule the plugin sets. The default admin screen renders this as a flat list with severity icons but does not expose the underlying rows as a real table.

SleekView reads the same options and transients, normalises the entries, and presents one row per finding. Columns expose the affected slug, the installed version, the patched version, the CVSS score, the CVE identifier, and the first time the finding appeared. Ignored items from the WPScan ignore list show as their own column rather than being silently hidden, so policy decisions stay visible.

From there workflows become consistent. Mark a finding as triaged, assign it to a teammate, or add a note explaining why a particular version cannot be patched yet. The next scan refreshes the underlying data; saved views keep showing the same slice with the same columns so weekly vulnerability reviews stop being a rebuild every time.

Vulnerability data only changes outcomes when someone acts on it. WPScan is excellent at fetching the right advisories and matching them to the installed versions, but the moment a finding lands the workflow tends to collapse into a copy and paste loop with a ticket queue. The data already lives in wp_options and transients; the missing piece is a grid with the columns that matter, persistent triage state, and a saved view that resumes the same review next week.

Compliance and risk teams need a stable shape for what they audit, not a JSON blob that mutates on every refresh. Plugin owners need to know which findings are theirs without a meeting. Treating WPScan output as a tracked list turns vulnerability management from a notification stream into a managed pipeline, and the plugin keeps doing what it does best: knowing about the advisories before anyone else does.