Vulnerability scanning FAQ for MSPs

Varaxon Scan Hub turns vulnerability scanner exports into prioritized, client-ready remediation reports. Upload an export from Nessus, Greenbone / OpenVAS, Qualys, Rapid7, Nuclei or a CSV, XML or JSON export from another vulnerability scanner, or connect Microsoft Defender Vulnerability Management or ConnectSecure directly, and Scan Hub ranks the findings, writes the report in plain language and keeps every statement tied to the scanner evidence it came from.

MSPs, MSSPs and security consultants who scan client environments and need to hand over a report a business owner can act on, plus individuals and small businesses who already have a scan export and want to understand it. You keep your scanner; Scan Hub handles the reporting.

No. Scan Hub processes an export you already generated; it does not replace your scanner and does not need scanner credentials or an agent on client devices. Run the scan in your normal tooling, then upload the export to get the report.

Tenable Nessus (.nessus XML), Greenbone / OpenVAS XML, Qualys scan and VMDR exports (CSV and XML), Rapid7 Nexpose / InsightVM XML, Nuclei JSON, and other network, host or web vulnerability scanners' CSV, XML or JSON exports that list findings by host, IP or URL. Run the free pre-flight check first to see whether Scan Hub can read a file; if a report can't be written from it, the credit is refunded. Microsoft Defender Vulnerability Management and ConnectSecure have no export file to upload; connect them directly instead. Defender needs Microsoft Defender for Business (included in Microsoft 365 Business Premium), Defender for Endpoint Plan 2, Defender Vulnerability Management or Defender for Servers. See the Nessus report guide and the Greenbone / OpenVAS guide for how each export family is handled.

Use the most complete machine-readable export your scanner offers, not its PDF. For Nessus that is the .nessus file; for Greenbone / OpenVAS it is the XML report. PDF and HTML reports are presentation formats and often drop fields such as CVE lists or plugin output. The guide to turning a scan export into a client report lists the right format per scanner.

Each upload is read on its own terms, because scanners disagree on severity scales, identifiers and what counts as one finding. Scan Hub normalizes them into the same priority bands, so reports for one client read consistently even when the scans came from different tools.

Start with scope (which hosts, which date, credentialed or not), then the findings that are known to be exploited, then everything else by severity. Treat informational items as context rather than work. The guide to reading a Nessus report walks through each section.

No. It means the export did not provide a usable structured CVE reference for that finding. Many real issues, such as weak TLS settings or default credentials, have no CVE at all. Scan Hub marks CVE-based assessment as Unknown for those findings so nobody presents incomplete evidence as a clean result.

The classic Greenbone / OpenVAS PDF format summarizes results and is known to leave out CVE details that the XML, CSV and TXT exports include. Results can also disappear because of the Quality of Detection (QoD) filter applied when the report was generated. Export the XML instead; the OpenVAS missing CVEs guide explains both causes.

Scanner exports can omit, vary or leave parts of the supporting metadata incomplete. Scan Hub preserves the fields that are present and calls out gaps rather than inventing a score, remediation step or certainty that the export cannot support.

Credentialed coverage can give the scanner deeper visibility into installed software, patches and configuration. A credentialed percentage is still a scope and evidence measure, not proof that every asset was assessed. The report surfaces coverage, credential failures and missing host context so you can explain the boundary to a client. More in credentialed vs non-credentialed scans.

A credentialed (authenticated) scan logs in to each host and reads installed software and configuration directly. A non-credentialed scan only sees what the host exposes over the network, the way an outside attacker would. Credentialed scans usually find far more missing patches and produce fewer false positives; a failed login quietly turns a credentialed scan into a non-credentialed one.

Check the scanner's evidence first: the detected version, the plugin output and whether the scan was credentialed. Version-based checks on backported packages (common on Linux distributions) are a frequent cause. Record the reason when you accept or dismiss a finding, so the next report does not resurface it without explanation.

They are severity labels, usually mapped from CVSS base scores: Critical 9.0 to 10.0, High 7.0 to 8.9, Medium 4.0 to 6.9 and Low 0.1 to 3.9. Severity describes how bad a flaw could be in general, not how likely it is to be used against this client. That is why Scan Hub ranks known exploitation ahead of raw severity.

Scan Hub sorts findings into six fixed priority bands: known exploited with ransomware use (CISA KEV), known exploited (KEV), CVSS 9.0 or above without a KEV match, other findings with a CVE and meaningful severity, findings without a CVE but with meaningful severity, and finally low or informational items. The bands, counts and KEV status are calculated by deterministic code, so the same export always produces the same ranking.

CVSS rates how severe a vulnerability could be. EPSS, published by FIRST, estimates the probability that it will be exploited in the next 30 days. The CISA Known Exploited Vulnerabilities (KEV) catalog lists vulnerabilities with confirmed exploitation in the wild. Use KEV first, EPSS to break ties and CVSS for impact. The full comparison is in CVSS vs EPSS vs KEV.

The Known Exploited Vulnerabilities catalog is a list maintained by the US Cybersecurity and Infrastructure Security Agency of vulnerabilities with reliable evidence of active exploitation. Each entry carries a remediation due date for US federal agencies and a flag for known ransomware campaign use. It is the strongest single signal for what to patch first.

EPSS is a probability that changes daily, which makes it a good tiebreaker but a poor basis for a fixed ranking a client signs off on. Scan Hub shows EPSS beside each finding and never lets a missing or low EPSS score move a finding down a band.

No. KEV only lists exploitation that CISA has confirmed, so absence means no confirmed evidence yet, not that nobody is exploiting it. Scan Hub never describes a KEV miss as "not exploited".

There is no universal deadline; the client's policy or framework sets it. Common targets are days for known exploited vulnerabilities on internet-facing systems, 14 to 30 days for Critical, about 30 days for High and 60 to 90 days for Medium. The remediation SLA guide has a starting matrix you can adapt.

An executive summary in plain language, the scope and date of the scan, the method (scanner, credentialed or not), the prioritized findings with evidence, a remediation plan with owners, and a clear statement of what the scan could not see. A report checklist and template covers each section.

Yes. You can identify the MSP as the provider, identify the client separately and add an optional provider logo. Scan Hub sizes the supplied logo to fit the report cover so the exported PDF reads as a clear, client-ready deliverable.

Lead with the handful of actions that matter, in business terms: what could happen, which systems, and what fixing it involves. Keep raw finding counts out of the opening, because a long list of Highs alarms people without telling them what to do. Scan Hub writes the executive summary this way and keeps the technical detail in the appendix.

Yes. Scan Hub drafts a ticket for each remediation action and creates it in HaloPSA or ConnectWise PSA after you review and approve it. Nothing reaches your PSA without that approval.

Yes. Reports are kept per client in your account, so you can see which findings are new, which were fixed since the last scan and how long the open ones have been outstanding. That history is what makes a quarterly business review credible.

No. It is a reporting layer for vulnerability assessment data. It does not perform a penetration test, replace remediation work or establish that an environment is secure. Read vulnerability scan vs penetration test for when a client needs which.

There is no single schedule that fits every client. Set cadence from the environment's exposure, asset criticality, change rate, contractual commitments and the time needed to act on findings. A recurring authenticated process is usually more useful than a one-time scan; monthly is a common baseline, and frameworks such as PCI DSS require at least quarterly. Document the scope and date every time so the report's age is clear.

PCI DSS v4 requires internal and external vulnerability scans at least once every three months and after any significant change. External scans must be performed by an Approved Scanning Vendor (ASV), and internal scans must be authenticated. See how often to run vulnerability scans for details.

The current HIPAA Security Rule requires a risk analysis and reasonable safeguards but does not name a scan frequency. Regular scanning is the usual way to support the risk analysis, and proposed updates to the Security Rule would add explicit vulnerability scanning requirements.

Many do. Underwriting questionnaires commonly ask whether you scan regularly, how fast critical vulnerabilities are patched and whether internet-facing systems are covered. A dated report history with remediation tracking is the easiest way to answer those questions with evidence.

Scan Hub uses AI models from Anthropic to read unusual export layouts, gather vendor fix guidance and write the report in plain language. The facts a client relies on (priority bands, finding counts, KEV status and fixed versions) are calculated by deterministic code, and every report is checked against those facts before release.

It is not allowed to. Every claim in the AI-written text must reference a fact taken from the export or from trusted vulnerability data, and a report that adds a finding, changes a count or moves a finding between bands fails validation and is not released.

Reports and findings are stored in your account so you can track each client over time, isolated per account and deletable on request. Do not upload a real client export without the client's authorization, and review the Privacy Policy and Data Processing Addendum for retention and subprocessor details.

No. Scan data is sent to Anthropic through its commercial API, under terms that do not allow customer content to be used for model training.

Start with the free, anonymous pre-flight assessment; no account, card or email address is required. You get a 14-day free trial of Core, with up to 10 reports; after that, choose a plan or a pay-as-you-go report. Visit sample reports first if you want to review the output before uploading your own export.

Monthly plans start at $49 for 10 reports, with yearly billing at ten times the monthly price, and a single report costs $9 on pay-as-you-go. See pricing for every plan.

Yes. Owners and admins invite teammates by email, and everyone works in the same clients and reports with their own sign-in and two-factor authentication. Core includes up to 3 people, Growth up to 10 and Scale unlimited, with no extra charge per person. Starter and pay-as-you-go are for one person.