DEV Community: Brandon Sooknanan

The Vulnerability Scanner Is Not the Hard Part. The Handoff Is.

Brandon Sooknanan — Wed, 16 Sep 2026 20:57:25 +0000

The Vulnerability Scanner Is Not the Hard Part. The Handoff Is.

Most vulnerability scanners are good at finding problems.

The difficult part begins after the scan finishes.

A scanner can produce hundreds or thousands of findings, but a client usually does not need another enormous export. They need answers:

What matters most?
What should we fix first?
Which systems are affected?
What evidence supports the recommendation?
Can the result be explained to both leadership and a technician?

That gap between detection and action is the reporting handoff.

A raw export is not a remediation plan

Scanner exports are designed for completeness. Client reports need clarity.

A raw export may contain:

The same vulnerability repeated across many assets
Multiple ports and services affected by one issue
CVSS scores without business context
Scanner-specific terminology
Inconsistent or incomplete metadata
Technical evidence that is difficult for non-technical readers to interpret

Simply converting XML into a nicer-looking PDF does not solve the problem. The reporting layer has to preserve the evidence while making the result easier to act on.

A defensible reporting pipeline

A useful reporting system should separate ingestion, validation, prioritization, and presentation.

Conceptually:

raw = parse_export(upload)
validated = validate_and_consolidate(raw)
enriched = enrich_with_public_intelligence(validated)
prioritized = prioritize_deterministically(enriched)
report = render_report(prioritized, audience="client")

Each stage has a specific responsibility.

1. Treat scanner exports as untrusted input

Nessus and OpenVAS/Greenbone exports are XML documents. They should be parsed defensively.

That means enforcing limits on:

Request size
XML depth
Element count
Numeric fields
External entities
Unexpected document structures

A reporting tool should fail safely when an export is malformed instead of producing a report that looks authoritative but is based on corrupted data.

2. Preserve scanner provenance

A reporting system should not guess relationships that the scanner did not provide.

For example, if a scanner reports:

Plugin 12345 → CVE-2025-1234

the reporting layer should preserve that relationship. It should not assign a CVE merely because a vulnerability title or description contains a familiar product name.

This matters because inaccurate enrichment can create false confidence. A professional report must distinguish between:

Evidence directly supplied by the scanner
Validated normalized data
Public threat intelligence
Information that could not be verified

3. Consolidate findings without hiding scope

The same vulnerability may appear on dozens of hosts, ports, or services.

A useful report should consolidate the vulnerability into one meaningful finding while retaining the affected-instance details underneath it.

The goal is not to make the scan appear smaller. The goal is to make it readable without losing scope.

A consolidated finding might contain:

Finding:
  Source identifier
  Normalized CVE list
  Severity and CVSS information
  Affected host count
  Affected service and port details
  Scanner evidence
  Remediation guidance

This gives leadership a clear summary while preserving the technical evidence needed by the person doing the work.

4. Validate before enrichment

External intelligence should only be applied after the scanner data passes consistency checks.

For example, if the same scanner plugin is associated with conflicting CVE sets across the export, that should be disclosed as a data-quality issue rather than silently merged.

Invalid or ambiguous records should be separated from normal prioritization. The report should clearly state that those records could not be confidently assessed.

That is much better than presenting uncertain data with an artificially precise score.

5. Prioritize deterministically

“Critical” is not always enough to determine what should happen first.

A practical prioritization process can combine:

Known exploitation activity
CVE presence
CVSS score
Scanner severity
Affected asset count
Available remediation information

The important word is deterministic.

If the same validated scan is processed twice with the same configuration and intelligence catalog, the ordering should be reproducible. Security teams should be able to explain why one finding appears above another.

Public intelligence sources such as the CISA Known Exploited Vulnerabilities Catalog can provide additional context about vulnerabilities being exploited in the wild.

That intelligence should be shown as supporting evidence—not hidden inside an unexplained black-box score.

One export, multiple audiences

A single report often needs to serve several audiences.

Executives need:

Overall risk status
The most important issues
Business impact
Clear next steps

Technicians need:

Affected hosts
Ports and services
Scanner evidence
Plugin or check identifiers
Remediation details
Exact counts

Auditors and security leads need:

Data-quality disclosures
Source provenance
Reproducible prioritization
Intelligence limitations
A complete record of what was and was not assessed

The best reports use layers instead of forcing every reader through the same level of detail.

The scanner should remain the scanner

Small and midsize MSPs usually do not need another vulnerability scanner.

They already have tools such as Nessus or OpenVAS/Greenbone. Replacing those tools would mean rebuilding integrations, credential workflows, scan scheduling, asset management, and years of operational experience.

The more practical approach is to improve the layer after scanning.

Keep the scanner responsible for detection. Let the reporting system handle:

Normalization
Evidence preservation
Prioritization
Client communication
Remediation planning
Professional delivery

That separation keeps the workflow flexible. If another scanner is added later, it can be connected through an adapter without rewriting the reporting and prioritization core.

Why I built Varaxon Scan Hub

This reporting gap is why I built Varaxon Scan Hub.

Varaxon Scan Hub lets security teams upload Nessus or OpenVAS/Greenbone exports and turn them into client-ready reports with:

Executive summaries
Deterministic vulnerability prioritization
Affected-asset aggregation
Scanner evidence
Remediation guidance
Data-quality disclosures
Technician-ready technical details
White-label PDF output

The standard upload workflow does not require scanner API credentials or replacing the tools an MSP already uses. The export is processed through the reporting pipeline and returned as a professional deliverable.

The goal is simple:

Spend less time formatting scanner output and more time helping clients reduce risk.

If your team already has a scanner but still spends hours turning exports into professional reports, Varaxon Scan Hub is built for that handoff.

Start with the scanner you already trust. Improve what happens next.

Before You Trust a Vulnerability Report, Check This Page First

Brandon Sooknanan — Tue, 15 Sep 2026 16:14:37 +0000

A vulnerability report can look polished and still leave out the context you need to make a good decision.

Before I look at the highest-severity finding, I want to know whether the scan itself was recent, complete, and backed by enough evidence to support the conclusions.

That is why the “Scope, scan quality & data quality” section matters so much.

Example report section showing scan age, credential coverage, feed age, and missing evidence.

Start with the scope

This example shows a scan that was performed 183 days before the report was generated. That does not make the report useless, but it does mean the results are a historical snapshot rather than a statement about the environment today.

The report also shows:

30 hosts scanned
Only 3.3% credential coverage
25 hosts where patch assessment failed
29 hosts missing a hostname
A plugin feed that was 601 days old when the scan ran

Those details completely change how I would explain the findings to a client.

Missing data is part of the result

The report retained:

1,338 occurrences without a CVE
1,262 occurrences without CVSS data
961 occurrences without an actionable solution
1,289 occurrences marked informational

That does not automatically mean every finding is wrong. It means the report has to be honest about what can and cannot be prioritized.

A missing CVE is not proof that a finding is harmless. A missing CVSS score is not the same thing as a zero score. And a failed patch assessment should never quietly look like a clean result.

Band distribution is not the whole story

The band table is useful for organizing validated findings, but it should not be read in isolation.

Seeing zero findings in the top exploitation-related bands does not prove that the environment is clean—especially when the scan is old, credential coverage is low, and large portions of the evidence are incomplete.

The most useful reports make those limitations visible instead of burying them in a footer.

What I would do next

For a client-facing assessment, I would recommend:

Run a fresh scan.
Update the scanner/plugin feed first.
Improve credentialed coverage where possible.
Investigate hosts that failed patch assessment.
Resolve missing CVE, CVSS, hostname, and remediation data.
Treat the current report as a starting point, not a clean bill of health.

The main takeaway is simple: vulnerability reporting is not only about counting findings. It is also about showing how much confidence the reader should place in those findings.

A trustworthy report should tell you what was scanned, what evidence was available, what was missing, and what still needs manual review.

Disclosure: I’m building Varaxon Scan Hub at Varaxon Technologies. It converts Nessus and Greenbone/OpenVAS XML exports into evidence-led PDF vulnerability reports for MSPs and security teams.

If you want to try the workflow, the first three scans are currently free with a no-commitment preflight assessment: https://scan.varaxontech.com

“No Findings” Does Not Always Mean “Secure”

Brandon Sooknanan — Mon, 14 Sep 2026 23:50:52 +0000

One of the easiest ways to miscommunicate a vulnerability assessment is to treat “no findings” as “the environment is secure.”

Those two statements are not the same.

A scanner can return no findings because:

The target was not included in the scan
The host was offline or unreachable
Credentials failed
A service was excluded
The scan ended early
The export was incomplete
The scanner did not have enough information to evaluate the system

That does not automatically mean the environment has no vulnerabilities.

What should the report say instead?

A useful report should separate three things:

Findings

Issues that were actually identified and supported by scanner evidence.

Coverage

What systems, services, and environments were actually assessed.

Limitations

Anything that prevented the assessment from being complete or reliable.

For example, if a scan covered 80 of 100 expected systems, the report should make that visible. The client needs to know that the results apply to the 80 assessed systems—not automatically to the entire environment.

Why this matters to MSPs

Clients often read a report as a statement about their overall security posture.

If coverage limitations are hidden, a client may believe that systems were assessed when they were not. That creates confusion during remediation and makes future comparisons harder.

Clear reporting protects both sides:

The client understands what was tested
The MSP can explain what remains unknown
Remediation can focus on verified evidence
Follow-up scans can be compared more accurately

The goal is not to make a report sound worse. The goal is to make it accurate.

I’m building Varaxon Scan Hub around this idea: preserve the original scan evidence, show affected systems clearly, and call out data-quality or coverage limitations instead of hiding them.

This post uses synthetic examples only. No client data is included.

— Brandon Sooknanan

Founder, Varaxon Technologies

What to Check Before Turning a Vulnerability Scan Into a Client Report

Brandon Sooknanan — Mon, 14 Sep 2026 23:44:19 +0000

A vulnerability report is only as useful as the data behind it.

A polished PDF can still mislead a client if the scan scope was incomplete, findings were disconnected from affected systems, or missing data was treated as a clean result.

Quick rule: Never let a clean-looking report hide uncertainty in the underlying scan.

1. Confirm the scan scope

Before reviewing findings, confirm that the scan covered the systems it was supposed to cover.

Check:

Expected hosts and IP ranges
Network segments
Services and ports
Offline or unreachable systems
Any exclusions or skipped assets

A report should never imply that an environment is clean simply because certain systems were never scanned.

2. Connect findings to affected systems

The same vulnerability may appear across multiple hosts, ports, or services.

Clients should be able to answer:

Which systems are affected?
Which services are exposed?
How many instances exist?
Is the issue isolated or widespread?

Without that context, a report becomes a list of vulnerability titles instead of something a client can act on.

3. Preserve the supporting evidence

Each finding should remain traceable to the original scanner output.

Useful details include:

Plugin or test identifier
CVE references
Severity and CVSS information
Affected host and service
Scanner description
Recommended remediation

The report does not need to display every raw field, but it should preserve enough context to support the conclusion.

4. Be honest about data-quality issues

Real scan exports are not always perfect.

You may encounter:

Missing CVEs
Conflicting metadata
Incomplete plugin information
Findings that cannot be reliably prioritized

Those cases should be called out instead of silently normalized.

If the underlying data is incomplete, the report should explain the limitation and identify what needs manual review.

That is more useful—and more defensible—than presenting uncertain results as facts.

5. Make the next step obvious

A useful report should help the client decide what to do next.

The final document should clearly show:

What needs attention first
Why it matters
Which systems are affected
What evidence supports the finding
What information is missing
What should happen next

The goal is not just to produce a longer report. It is to make the technical evidence easier to review and act on.

I’m building Varaxon Scan Hub around this workflow. It converts Nessus and Greenbone/OpenVAS XML exports into structured, evidence-linked reports while keeping the original finding context visible and calling out coverage or data-quality limitations.

Want to try it? The first three scans are free, with no card and no commitment.

Try Varaxon Scan Hub

— Brandon Sooknanan

Founder, Varaxon Technologies