How our website security checks work
Think of a scan as a planned inspection of a building’s public entrance and selected accessible rooms. The route and time are limited. An unvisited room cannot earn a clean bill of health.
Know what was checked before counting what was found.
Evidence has a boundary
CVE Scanner assesses one authorised host without logging in. It combines public DNS and TLS evidence with selected response-policy, exposure, software and read-only HTTP input checks. It does not inspect every page, account or dependency.
Both Standard and Deeper are available in public beta. Complete cloud and accuracy validation remain outstanding. Deeper increases the available scope and budgets; it does not promise more findings, exhaustive testing or that every supported check completes.
Configuration evidence
A header, policy or supported public response can support a hardening finding. Read the affected resource and evidence before choosing a fix.
Candidates
Version-based CVE matches and positive HTTP application signals require further investigation. They are not confirmed exploits.
Incomplete checks
Not assessed, inconclusive and failed outcomes are different from passes. A request failure cannot prove a resource is safe.
Get a useful answer in four moves
The report is a starting point for action. Pair each conclusion with the evidence and the scope that produced it.
Understand → test → change → recheckAuthorise the host and the activity
Only assess systems you own or have permission to test. Complete the requested DNS ownership proof and acknowledge selected active checks. Ownership is rechecked for relevant work; permission for one host does not extend to another.
Ready when The host and intended activity are explicitly in scope.
Understand the inspection route
The scanner selects eligible same-host pages and read-only input vectors within shared budgets. Target responses, missing-page controls and available evidence can reduce completed coverage. There is no login, form submission or browser execution.
Ready when You understand the selection ceilings and exclusions below.
Read outcomes before the total
Review completed, incomplete and failed check/resource outcomes. Separate unique open issue groups from advice, software observations and collection diagnostics. Several checks can contribute to one issue, so those totals answer different questions.
Ready when You can tell an observation from a candidate and an unknown.
Verify, remediate and recheck
Prioritise using the evidence and your application’s context. Confirm CVE prerequisites and installed builds, including vendor backports. After a fix, use a same-level rescan and verify the matching resource: earlier findings stay open until a newer conclusive recheck resolves them.
Ready when A specific fix has newer evidence, not just a smaller headline count.
More room to inspect. Still a limit.
Both packages use the same check families. These ceilings do not guarantee that every page or check completes.
| Scope | Standard | Deeper |
|---|---|---|
| Additional same-host pages | Up to 12 | Up to 40 |
| Discovery depth | 2 | 3 |
| Read-only input vectors | Up to 2 | Up to 8 |
| HTTP requests | Up to 100 | Up to 250 |
| Worker time | 120 seconds | 300 seconds |
What CVE Scanner can see
Public beta · validation ongoingWithin the lens
Supported DNS/email and TLS settings, selected public response policies and exposures, reviewed software/CVE rules and bounded read-only HTTP application candidates. The full catalogue explains each family.
Beyond the lens
No authenticated application testing, broad network or internal-device scan, full source/dependency audit, exhaustive crawling or complete API testing. Browser-assisted candidate validation is unavailable.
Review the coverage for your actual attempt. Historical reports retain their recorded profile; today’s catalogue does not retroactively upgrade them. Use the simulated sample to learn the layout, not as proof of live accuracy.
A couple of useful questions
Are the budgets a completion promise?
No. They are maximum allowances shared by selected work, not independent quotas that all run to completion. Network responses, usable evidence and other limits also matter. Queueing, database startup and DNS verification can add time outside the worker budget.
Does a read-only input check confirm exploitation?
No. Supported checks use bounded HTTP comparisons and inert markers. They do not perform delays, extraction, writes, callbacks or command execution. Reflection can be informational; other positive signals remain candidates until verified.
Read a little deeper
Primary guidance for the next conversation with your developer or administrator. References open in a new tab.
- OWASP: Web Security Testing Guide
Why automated checks belong within a broader testing programme.
- OWASP: Testing framework
How different assessment techniques fit the development lifecycle.