Release Notes — Deeper Scans, Clearer Reports, and AI-Powered Guidance (April 2026)

This week we shipped three upgrades to Biz Secure Online. Two are engineering improvements — a deeper vulnerability scan and a clearer report. The third is, for us, the most important release we've ever put out: we've closed the loop between detection, explanation, and resolution by adding AI Prompts for Issue Resolution to every scan report, and we think it genuinely changes what a vulnerability scanner can do for a small business owner. All three changes went live on production on the night of 11 April 2026 AEST. Every scan run after that date automatically benefits from all three. There's nothing you need to do.

The notes below are in two parts. The first is for website owners and business users, in plain English. The second is for security practitioners and engineers who want to know what changed under the hood.

Part 1 — For website owners

What changed

1. We now check services on every open port, not just your web port.

Every scan starts by looking at your website the way a visitor's browser does — by connecting to its normal web address. Until this week, that was also the only place our vulnerability checks ran. If your server happened to be running other services on other ports — a database, a remote-access tool, an admin panel on a non-standard port — those were listed as open ports in your report, but we weren't running targeted vulnerability checks against them.

As of this release, whenever our port scanner finds anything open beyond the standard web ports, our vulnerability scanner automatically takes a second pass and checks those services too. On most small-business websites that only expose ports 80 and 443, nothing changes — the scan behaves exactly as it did before. On sites that expose anything else, you'll see a more thorough check and, where relevant, extra findings in your report.

2. The Security Issues section of your report is now much clearer.

We heard that "no issues found" wasn't telling customers enough about what that actually meant, and that findings with severity scores weren't always clear about how worried to be. So we've added three new pieces to every report:

A Scope & Methodology panel at the top of the Security Issues section. It explains exactly what this scan did and didn't cover — what we looked at on your public perimeter, what we couldn't reach (anything behind a login, other subdomains, your internal APIs), and a few honest caveats about how vulnerability databases work.
An About CVSS Scores explainer that appears whenever any finding includes a CVSS score. It tells you what the 0–10 number means, what the critical / high / medium / low bands are, and where the score comes from so you can judge severity yourself instead of just trusting a colour.
A clearer clean-result message for scans that find nothing. Instead of a single line, you now get a short explanation of what a clean result means (and just as importantly, what it doesn't mean — a clean external scan is one signal, not a certification). Individual findings now also show the CVE identifier and reference links directly on the card, so you can jump straight to vendor advisories without having to search.

3. We've closed the loop between detection, explanation, and resolution.

This is the big one, and it deserves a few paragraphs — because we think it genuinely changes what a vulnerability scan is for an SME owner.

Every vulnerability-testing product on the market does the first step well: detection. They run scans, they find issues, they produce a report. The problem has always been the next two steps. Explanation — what does this finding actually mean for my business? Resolution — what do I actually do about it, right now, on my specific site? For most of the industry those two steps are left as an exercise for the reader. If you're a large enterprise with a security team on staff, that's fine — your engineers translate the report into action. But if you're a small or medium business owner, a sole trader, a one-person marketing agency or a two-person MSP, the scan report often ends up doing the opposite of what it should: it makes you feel more worried and less equipped. You know there's a problem. You don't know what it means. You certainly don't know how to fix it. And the tool that found it has quietly walked away.

We've been aware of that gap in our own product since day one. Our reports are clearer than most, but they are still, unavoidably, technical documents. Until this release we couldn't honestly claim we were helping customers resolve the things we were pointing out. That changes today.

At the bottom of every scan report — both in your dashboard and on any public share link — there's a new section called AI Prompts for Issue Resolution. It contains ready-to-use prompts you can paste straight into ChatGPT, Claude, or any other AI assistant. Click one button to copy, paste into the assistant of your choice, and you're immediately in a conversation with something that knows exactly what we found, on which host, at what severity, with which CVE, and with all the context it needs to walk you through fixing it — in plain English, at your pace, for as many follow-up questions as you want to ask. No prompt-writing skill required. No cybersecurity vocabulary required. You don't even need to understand the finding before you paste it.

There are two kinds of prompt. Category prompts bundle every finding of a given type — missing security headers, SSL/TLS issues, vulnerabilities, open-port services, WordPress plugin problems and so on — into one prompt so you can tackle a whole category in a single conversation and get a prioritised remediation plan back. Per-issue prompts are generated for every critical and high severity finding individually, so you can go deep on the one thing that matters most first. Each prompt is completely self-contained: the finding details, the affected host, the CVE or CVSS score where we have one, and a short lead-in that tells the assistant who you are and what you need — all of that is already baked in. On scans that find nothing to fix, the section quietly hides itself; you'll never see an empty block.

Why does this matter, beyond the convenience? Because it closes a loop that nobody else in this market has closed for SMEs. Detection → Explanation → Resolution. Enterprise-grade scanners offer detection and leave explanation and resolution to the customer's in-house security team. SME-focused tools, including our own until this week, offered detection and a nicely formatted report and then walked away. As far as we're aware, no other vulnerability-testing vendor is combining SME-focused scanning with AI-generated, pre-loaded remediation prompts that the customer can use immediately, with an AI assistant they already have open in another tab. For a category of customer who can't justify a security engineer on staff, that's a meaningful difference: the scan is no longer the end of the conversation, it's the start of one. That, for us, is what "peace of mind" is supposed to mean — not just knowing, but being able to act.

The feature is live on every scan run from 11 April 2026 onward. If you'd like to see it in action, run a scan from your dashboard and scroll to the bottom of the report.

What this means for your score

These changes are about coverage and clarity, not penalties. The scoring formula itself is unchanged. What may change is whether deeper services get checked at all — so on a handful of sites with exposed non-web services, you could see new findings appear. If that happens, the finding will include a clear recommendation and a link to the relevant guide.

What to do

Nothing. Your next scheduled scan will automatically use the new engine and new report. If you want to see the new report format right away, run a manual scan from your dashboard.

Part 2 — For security practitioners

Stream 1 — Scan coverage: nmap → nuclei port chaining

Before this release, the scanengine's nuclei phase was invoked against the URL target only — effectively nuclei -u https://example.com — which meant nuclei only ever saw the web host and port. nmap was already running in an earlier phase to enumerate the full set of open ports, but that port list was only being used for the report's open-ports section, not fed back into vulnerability scanning. On any target with exposed non-web services — SSH on 22, a database port, a message broker, a misconfigured admin panel on 8888 — those services were visible to nmap but never checked by nuclei.

We've closed that gap. nuclei.service.js now runs in two phases:

Phase A is the original web-perimeter pass, unchanged — same templates, same target, same arguments. Nothing regresses for standard 80/443-only sites.
Phase B runs a second nuclei invocation against a target list built from nmap's open-ports output, minus the URL's own host:port. It uses the network,default-logins tag set, a shorter per-request timeout, and writes the target list to a tempfile consumed via -l. Phase B is skipped entirely when nmap's output contains no ports beyond the URL's own. Runtime impact on typical sites (80/443 only) is zero; on port-heavy targets the phase adds roughly one to three minutes, well under the existing per-tool ceiling.

Findings from both phases are deduplicated on ${template_id}::${matched_at} before being handed to the aggregator, so repeat detections across phases are merged. Phase B findings are recognisable by a bare host:port value in matched_at, whereas Phase A findings have a URL-style matched_at.

Stream 2 — AI Prompts for Issue Resolution

This release introduces a new ai-prompts.service.js in the scanengine and a corresponding section at the bottom of both ScanReportPage.jsx (authenticated dashboard) and PublicReportPage.jsx (shared public links). The goal is to let users hand their specific scan findings to an LLM and get guided, context-aware remediation without having to write any prompt text themselves.

The service runs after the aggregator has produced its normalised findings list for a scan. It emits two kinds of prompt:

Category prompts. One per non-empty category (headers, ssl, vulnerabilities, ports, performance, seo, wordpress, tech). Each prompt bundles every finding in that category into a single context block and asks the assistant for a prioritised remediation plan.
Per-issue prompts. One per finding at critical or high severity, narrower in scope, asking the assistant to walk through just that one issue end to end.

Every prompt is fully self-contained. The target host, finding title, evidence, CVE and CVSS where present, and a short operator-voice lead-in are all interpolated into the prompt body at generation time, so the user can paste the output directly into ChatGPT, Claude, or any other assistant with zero editing. Each prompt is rendered in the frontend as a card with a one-click copy button.

Rendering is conditional on two things: the scan must have at least one finding to generate prompts against, and the scanengine must have had an OpenAI-compatible API key available at scan time. When either condition fails the section is omitted cleanly — no empty state, no half-rendered block, no console noise. This is deliberate: Free-tier and clean-result scans never see a broken-looking placeholder.

Stream 2 is additive. No schema changes, no changes to any existing aggregator output, no changes to scoring, and nothing required of existing public report consumers.

Stream 2.5 — AI Prompts categorisation refinement

With Stream 1 feeding network-layer findings into the same aggregator pipeline, the categorisation logic in ai-prompts.service.js::categorise() needed to be tightened. Before this release, the function checked for a CVE or CVSS score early and routed anything with either into the vulnerabilities bucket. That would have misrouted Phase B findings — for example, an exposed Redis instance with a CVE — into vulnerabilities when the right home for it is ports.

We reordered the checks so network signals now win over the CVE fallback. The function looks for a network tag, a known network-service tag (redis, mongodb, mysql, postgres, rdp, ssh, and friends), or a bare host:port matched-at with no URL scheme. Any of those routes the finding to ports. Only if none match does the function fall through to the CVE / CVSS check and route to vulnerabilities. Behavioural regression tests cover the "exposed Redis with CVE → ports" case explicitly.

Stream 3 — Security Issues section of the scan report

Three new presentation blocks, all in frontend/src/components/SecuritySection.jsx:

Methodology panel, always rendered, open by default, with four sub-blocks — Scope of this scan, What we tested, What we didn't test, and Caveats. All four link out to the relevant guides (score methodology, SSL/TLS, security headers, open ports) on bizsecure.online rather than re-explaining those topics inline.
CVSS explainer, rendered once per report immediately above the findings list whenever any finding has a numeric CVSS value. Covers the 0–10 scale, the severity bands, and that we display the vendor-published base score.
Expanded finding cards: CVSS score rendered as a badge in the card header, CVE identifier as a clickable link to the corresponding NVD entry, and up to three of the nuclei-supplied reference URLs as inline links.
Clean-result callout: replaces the previous single-line "No security issues found" block with a three-paragraph explanation covering what the result means, what it doesn't mean, and what to do next.

No backend schema changes were needed — the aggregator was already capturing cvss, cve, references, and matchedAt on every mapped vulnerability. Stream 3 is a pure presentation change on top of existing data.

Observability notes

The nuclei service's happy path is silent by design. The only log lines Phase B emits are on the two error branches — Network phase setup failed and Failed to clean up tempdir — so log silence during a scan is the expected outcome. If you want to confirm Phase B fired on a given scan, the surest test is to look for findings in the result JSON with a bare host:port value in matched_at. A small observability follow-up that adds [nuclei] network phase: scanning N targets / complete, M findings log lines is on the fast-follow list.

Deployment summary

Staging: scanengine, API, and frontend deployed earlier in the week. Validated against scanme.nmap.org and a clean control target. Phase B fired, new findings landed in the ports category, and the new report components rendered correctly including CVSS badges, CVE links, and the clean-result callout.
Production: scanengine (bso-scanengine), API (bizsecure-api), and frontend (Vercel Production → portal.bizsecure.online) deployed the night of 11 April 2026 AEST. Three new fly secrets set on the production scanengine app: NUCLEI_NETWORK_TAGS=network,default-logins, NUCLEI_NETWORK_REQ_TIMEOUT=5, NUCLEI_NETWORK_TIMEOUT=300.

What's next

Two items are already on the fast-follow list: KEV (CISA Known Exploited Vulnerabilities) enrichment on CVSS-scored findings so that "actively exploited" can be surfaced alongside the base score, and the Phase B observability log lines mentioned above. Both are small, both will ship in separate commits once the current release has baked on production.