Exposure scanning vs vulnerability scanning vs penetration testing

Three different questions

'Is my site secure?' isn't one question — it's at least three. Is any of my software known to be vulnerable? Have I left anything open that shouldn't be? And could someone actually break in right now? Each has its own kind of check, and confusing them leaves gaps.

The three checks below answer those three questions. The first two are safe to run continuously and automatically; the third — actually attacking the site — is powerful but risky, occasional, and usually done by a human. Most real break-ins are enabled by the first two going unwatched.

Vulnerability scanning — is my software known-vulnerable?

A vulnerability scan takes an inventory of the software you run — WordPress core, plugins, themes — and checks each version against databases of known vulnerabilities (CVEs). If a plugin you have has a published flaw that isn't patched in your version, it's flagged. Relvato's vulnerability journey does this against the Wordfence Intelligence feed and WPScan, and prioritises by severity and whether a flaw is being actively exploited (CISA KEV).

It's essential — most WordPress hacks come through a plugin with a known, unpatched CVE. Its limit: it only knows about DISCLOSED vulnerabilities in software it can identify. It says nothing about your configuration, or about a clean plugin doing something dangerous, or about files you've accidentally left reachable.

Exposure / hardening scanning — what have I left open?

An exposure scan takes the attacker's-eye view from OUTSIDE: it requests URLs and reads responses to find things that shouldn't be reachable. Not vulnerable code — misconfiguration and exposure. A stray .env or database backup at the web root, an exposed .git folder (your whole source and history), directory listing switched on, XML-RPC enabled for brute-forcing, usernames leaking through the REST API, missing security headers.

This is where a huge share of real break-ins actually start — not with a clever exploit, but with a door someone forgot to close. It's also invisible to a vulnerability scan, because none of it is a CVE. Relvato's exposure scan runs this continuously, read-only (it never exploits anything), on the site you've verified you own, and flags a newly-exposed secret the day it appears.

Because it's non-intrusive — plain GET requests, no payloads, no brute force — it's safe to run automatically and often, which is exactly what catches a backup someone left behind after a migration.

Penetration testing — could someone actually break in?

A penetration test goes further: a tester (usually a human, sometimes with heavy tooling) actively tries to exploit what they find — injecting payloads, chaining weaknesses, attempting to gain access — to prove real, exploitable impact. It's the most thorough, and the only one that confirms a finding by demonstrating it.

The trade-offs are why it's not continuous: it's intrusive by nature (it can break things, create junk data, trip defences, or take a site down), it needs explicit authorisation for the specific systems and hosting, and it's typically a scheduled engagement, not an always-on monitor. A good security programme runs a pentest periodically AND watches exposure and vulnerabilities continuously between them.

Why Relvato does the first two continuously — and not the third

Relvato is a continuous monitor of sites its customers have verified they own, so it does the two checks that are safe to automate — vulnerability scanning and exposure scanning — and re-runs them on every relevant change. It deliberately does NOT do the active, exploit-driven part: on a live production store, injecting payloads or brute-forcing could corrupt data, lock out real customers, or take the store down, and it would exceed what domain verification authorises (you control the page, not necessarily the server or the host).

So the honest framing is: Relvato covers the 'is it vulnerable?' and 'what's left open?' questions continuously, and complements — rather than replaces — an occasional human penetration test for the 'could someone actually break in?' question.

How Relvato's exposure scan works

It runs a small, curated set of read-only requests against your verified site, from an identified user-agent (not a stealth attacker), at a low rate. It confirms each finding by content — an exposed .env has to actually look like an env file, so a soft-404 page never false-positives — and separates critical exposure (a reachable secret or backup, which fails the check and alerts you) from hardening gaps (missing headers, enabled XML-RPC, enumeration, which warn). Anything expected on your site you can mark as reviewed.

It works on any site — the generic checks (exposed files, directory listing, headers) apply everywhere, and the WordPress-specific probes simply don't match on a non-WordPress site. No plugin needed.