Scanner Information

What is SecPortal's Scanner?

SecPortal provides active security testing features to its users, including vulnerability scanning, SSL/TLS checks, HTTP header analysis, and attack surface discovery. These scans are non-intrusive and designed to identify security issues without causing disruption to target systems.

Scans are only performed against domains that have been verified by a SecPortal user through our domain ownership verification process. Users must prove they own or are authorised to test a domain before any scanning can take place.

How to Identify Our Scanner

All SecPortal scanner traffic can be identified by:

What Our Scanner Checks

SecPortal's scanner performs non-intrusive checks including:

• SSL/TLS certificate validity and configuration
• HTTP security headers (HSTS, CSP, X-Frame-Options, etc.)
• Open port detection on common service ports
• DNS configuration analysis
• Subdomain enumeration (paid plans only)
• Known vulnerability detection based on service banners

Our scanner does not perform:

• Exploitation of vulnerabilities
• Brute-force password attacks
• Denial-of-service testing
• Data exfiltration or extraction
• Any form of destructive testing

The SSL/TLS check module produces certificate expiry findings (expired, less than seven, thirty, sixty, and ninety days), chain trust signals, protocol posture, and cipher posture on every scan cycle. For the operational lifecycle that runs the renewal queue, the chain-health trend, and the cryptographic-control evidence pack on a single engagement record, see the TLS certificate expiry and lifecycle tracking workflow.

Interpreting Scanner Output

Vulnerability scanners produce false positives by design: pattern-based detection cannot see whether a flagged condition is reachable or exploitable in the deployed asset. Our guide to vulnerability scanner false positives covers how to triage scanner output, how to suppress confirmed false positives durably, and how to drive the false positive rate down across scan cycles.

False positives waste triage time; false negatives ship undetected risk into the next scan cycle. Our guide to scanner false negatives and undetected vulnerabilities covers the five mechanisms that produce false negatives (coverage gap, detection gap, authentication failure, output truncation, context blindness), the four external signals (manual pentest, bug bounty, post-incident root cause, external advisory) that surface them, the six execution-status conditions that should convert a clean-looking scan into a result that needs review, why authenticated scan failure is the worst false negative pattern, and how to operate a scan programme that treats scanner output as input to a verified findings record.

Triage produces a decision; recording the decision so it survives audit is a separate discipline. Our guide to scanner finding suppression and deferral controls covers the three structured override types (false positive, accepted risk, severity override), how to scope an override to the finding-target tuple so recurring scans inherit the decision, how to gate the override authority by RBAC role, how often each override type should be reviewed, and how ISO 27001 Annex A 8.8, SOC 2 CC4.1, PCI DSS 6.3.1, and NIST 800-53 RA-5 read the suppression history as operating evidence.

Recording the override decision is one layer; running the override after it lands is a separate operating discipline. Our guide to scanner finding exception lifecycle and expiry covers the six lifecycle states an exception passes through (active within window, review-due, in-review, renewed, expired and reopened, revoked), the time-based and event-based expiry triggers that reset the review clock, the closed-loop renewal record with refreshed rationale and named approver, the six failure modes that produce silent persistence, how the lifecycle interacts with continuous monitoring schedules and retesting workflows, and how ISO 27001 Annex A 8.8, SOC 2 CC4.1 and CC7.1, PCI DSS 6.3.1 and 12.5.1, NIST 800-53 RA-5 and SI-2 and PM-9, and NIST CSF 2.0 ID.RA and GV.RM read the lifecycle evidence at the policy, operating, and programme layers.

Coverage is the other side of the same conversation. Our guide to vulnerability scanner coverage and limits walks through what external, authenticated, SAST, and SCA scans actually find, where each class stops working, and how to sequence scanner output with manual testing so the report represents what was verified.

Both questions inherit from the upstream decision about scope. Our guide to vulnerability scan scoping and target selection covers how to choose targets, document inclusions and exclusions, and produce a scope record that survives audit.

Scoping decides which targets belong inside the assurance question; validation proves each one can lawfully and safely be tested before any scan traffic dispatches. Our guide to scan target validation and authorisation covers the three control points (verified ownership, legal attestation, platform blocklist), how authenticated scans add credential authorisation on top, when validation has to be re-run, and how internal security and AppSec teams operate the chain so the audit trail from scan execution to authorising human is single-record traceable.

Once scope, coverage, and false positive triage are in place, the next discipline is making sure the same finding does not appear five ways across tools and scan cycles. Our guide to scanner output deduplication covers how to merge findings across Nessus, Burp Suite, SAST, and SCA tools without losing evidence, severity, or the audit trail behind each detection.

Deduplication answers what to merge; the next question is what severity the merged record carries when every scanner emits a different scale. Our guide to scanner output severity normalisation covers how to translate Nessus, Burp Suite, SARIF, SAST, and SCA severities into one defensible workspace scale, how to design the translation table, how to resolve disagreement between scanners on the same issue, how CVSS 3.1 and CVSS 4.0 reconcile during migration, and how compliance frameworks read severity as operating evidence.

Even a perfectly scoped scan produces unreliable output if it is silently denied at the WAF or CDN. Our guide to scanner blocking and WAF allowlisting covers where blocks land in a typical stack, how to write a narrow allowlist rule that survives audit, and how to detect partial blocks before the report ships.

The format that scanners emit decides how much evidence survives the trip into your findings record. Our guide to scanner output formats compares SARIF, Nessus XML, Burp XML, JSON, and CSV exports, covers what each one preserves, and explains how to plan format choice across a multi-tool engagement so the import keeps the evidence the consolidated finding actually needs.

Authenticated scans fail in different ways than unauthenticated ones, and most disappointing authenticated scans never actually authenticated. Our guide to authenticated scanner failure modes covers the six failure classes (wrong role, login script drift, session expiry, CSRF token rotation, MFA enforcement, SSO redirect failure), how to read the diagnostic signals in scanner logs, and how to record the authentication state so the report can defend the depth.

Cadence is the discipline that ties every scheduled scan to the next one. Our guide to vulnerability scan scheduling and baseline cadence covers how often to schedule external, authenticated, and code scans per asset class, when to override the schedule with an on-change scan, and how to read the diff between two scan baselines so the cadence drives remediation rather than producing a stack of static reports.

Reading the trend across many cycles is a different discipline than reading a two-scan diff. Our guide to scan baseline and trend comparison covers how to define a baseline that holds, how to separate real change from coverage drift, the five trend metrics that carry signal at the leadership view, and how compliance frameworks read the trend across the audit observation window.

Once cadence is set, the next operational decision is rate. Our guide to scanner rate limiting and throttling covers how to choose a starting scan rate per target class, ramp into the operating rate, handle HTTP 429 and Retry-After feedback, manage WAF and CDN burst rules, and pair findings with scan-coverage records so rate-limited truncation does not get misread as remediation.

The credential behind every authenticated scan is itself a perishable artefact. Our guide to scanner credential rotation and lifecycle covers rotation cadence by credential type, the six event classes that trigger off-cycle rotation, how to rotate without breaking scheduled scans, the difference between rotation and revocation, service account discipline, mid-scan invalidation handling, and how compliance frameworks read the credential lifecycle as evidence of operating credential management.

Once scans are running on cadence and credentials are rotating cleanly, the next governance question is how long the resulting evidence is retained and how it is disposed. Our guide to scan evidence retention and governance covers retention per artefact class (scan execution, finding, activity log, raw module output), how compliance frameworks read retention evidence (PCI DSS 10.5.1, ISO 27001 Annex A 5.33 and 8.10, SOC 2 CC7.1, NIST AU-11 and SI-12), how privacy regulations layer on top, when to dispose, when to hold, and how to operate retention as a controlled activity rather than as an annual policy refresh.

Many enterprise programmes already run scanners under existing licences (a Nessus instance owned by operations, a Burp Pro licence held by an AppSec engineer, a SAST or SCA tool already integrated into the source repository). Our guide to importing third-party scanner results covers the import workflow that turns Nessus, Burp Suite, and CSV exports into structured findings on the engagement record, including severity normalisation across scanner scales, CSV column mapping, the post-import triage that promotes drafts into canonical findings, and the audit trail the import preserves so the chain from scanner output to closed finding is reproducible.

All of the disciplines above (scoping, coverage, validation, output formats, authentication, cadence, retention, import) feed into a single operating record that an auditor or security leader reads end to end. Our guide to the scanner evidence chain from scan execution to closed finding covers the seven evidence layers (scan execution, module or rule, asset binding, source-emitted and platform-canonical values, triage transitions, remediation evidence, retest and closure binding), the six failure modes that break the chain in real programmes, and how compliance frameworks (PCI DSS 6.3.3, 11.3, 11.4, 10.5.1; ISO 27001 Annex A 8.8 and 8.15; SOC 2 CC4.1, CC7.1, CC7.2; NIST 800-53 RA-5, SI-2, AU-2, AU-12; NIST 800-218 RV.1 and RV.2; CIS Controls v8.1 7 and 8; OWASP SAMM Verification) read the chain as the technical vulnerability management control narrative.

The evidence chain assumes every module returned a clean completion status; in production, scans frequently complete partially because individual modules time out, error, or get skipped. Our guide to scanner module failures and partial scan recovery covers the four module states (completed, error, timeout, skipped), where module failures come from in production, how retry and stale-job recovery work without masking underlying conditions, how to record a partial scan so the next reader can tell coverage from completion, and how PCI DSS 11.3, ISO 27001 Annex A 8.8, SOC 2 CC7.1, and NIST 800-53 RA-5 read per-module status as operating evidence rather than as a scanner-internal detail.

Every layer in the chain ultimately refers to an asset, and the chain holds only when the binding between finding and asset survives renames, transfers, and decommissions. Our guide to scanner finding to asset binding covers how external, authenticated, code, SBOM, container, and cloud scanners bind findings to different canonical keys, the five failure modes that break the binding in real programmes, how affected_asset should be modelled so the source-emitted reference is preserved while the canonical reference resolves through a foreign key into the asset register, how ownership inherits through the binding rather than being denormalised onto each finding, how orphaned findings should be surfaced as a controlled queue, and how ISO 27001 Annex A 5.9 and 8.8, SOC 2 CC4.1 and CC7.1, PCI DSS 6.3.3 and 11.3 and 12.5.1, NIST SP 800-53 CM-8 and RA-5, NIST CSF 2.0 ID.AM, CIS Controls v8.1 control 1 and 2, HIPAA 164.310(d)(2)(iii), and DORA Article 8 read the binding chain as inventory and vulnerability management control evidence.

A finding bound to an asset still needs a lifecycle reading: when it first landed, when the workspace last had evidence it still applies, and how to retire it without reading silent disappearance as remediation. Our guide to scanner finding aging and staleness covers the difference between age (cumulative count from first detection) and staleness (time since last scan evidence), the six durable fields an aging record carries (first_seen, last_seen, detection_count, last_evaluated_against_target, open_duration_days, source_class), the six structural causes of staleness (scope change, authentication drift, coverage shift, rate-limited truncation, asset reference movement, scheduled scan miss), how to band the aged-finding queue so SLA and staleness triage stay separate workstreams, how to retire stale findings with explicit verification evidence rather than by silent close, and how ISO 27001 Annex A 8.8, SOC 2 CC4.1 and CC7.1, PCI DSS 6.3.1 and 11.3, NIST 800-53 RA-5 and SI-2, NIST CSF 2.0 ID.RA and DE.CM, and CIS Controls v8.1 control 7 read the aging record as technical vulnerability management control evidence.

Asset binding decides which canonical key each scanner type emits, but multi-scanner programmes face one layer earlier the question of how divergent identifiers for the same logical asset reconcile to one record. Our guide to scanner output normalised asset resolution covers the seven recurring identifier collisions (hostname versus FQDN, hostname versus IP, URL path variants, container tag versus digest, repository slug variants, cloud resource forms, package coordinate variants), the six elements of a defensible resolution policy (canonical identifier format, normalisation rule set, alias resolution rules, conflict resolution, unresolved-asset queue, change-event handler), how to preserve source-emitted and platform-canonical references on the same record, how DNS rotations, repository transfers, container image rebuilds, and cloud migrations re-bind through deliberate change events rather than silent rewrites, the five anti-patterns that fragment the asset record, and how ISO 27001 Annex A 5.9 and 8.8, SOC 2 CC4.1 and CC7.1, PCI DSS 6.3.3 and 11.3 and 12.5.1, NIST 800-53 CM-8 and RA-5, NIST CSF 2.0 ID.AM, CIS Controls v8.1 controls 1 and 2, and DORA Article 8 read the resolution chain as inventory and vulnerability management evidence.

Severity normalisation answers what number the canonical record carries; asset binding and resolution answer which target the canonical record points at. The classification axes that the backlog, the cross-engagement search, and the leadership rollup actually read sit in the structured category field, the impact dimension, the asset class, the exposure context, and the remediation owner. Our guide to scanner finding tag and label taxonomy covers the five axes a defensible taxonomy classifies along, why scanner-emitted tags do not constitute a workspace taxonomy, how to crosswalk the workspace categories to OWASP Top 10, OWASP LLM Top 10, CWE, and ASVS without pinning the internal scheme to an external version, how to keep compliance control mapping as a separate axis from the technical category, how enforcement runs at finding creation, triage, and cross-engagement review, the six failure modes that recur without a taxonomy, and how ISO 27001 Annex A 8.8, SOC 2 CC7.1 and CC4.1, PCI DSS 6.3 and 6.3.1, NIST 800-53 RA-5, NIST CSF 2.0 ID.RA, and CIS Controls v8.1 control 7 read the classification as operating evidence.

Every discipline above asks a question about the scans that ran. The next discipline asks about the scans that did not. Our guide to scanner coverage gap analysis covers the five gap classes (asset-level, scanner-class, cadence, authentication-depth, shadow-asset), how to build a coverage map that joins the asset inventory against the scan record, the six external signals (certificate transparency, DNS enumeration, cloud account discovery, repository directory, container catalogue, vendor attestation) that surface shadow assets the inventory missed, the cadence-gap mathematics that match scan frequency to asset change rate, the six anti-patterns programmes inherit without an explicit coverage discipline, the four review cadences that keep the map honest, and how ISO 27001 Annex A 5.9 and 8.8, SOC 2 CC7.1, PCI DSS 11.3, NIST 800-53 CM-8 and RA-5, NIST CSF 2.0 ID.AM and DE.CM, and CIS Controls v8.1 controls 1, 2, and 7 read coverage as a paired inventory-and-detection control.

Our Safeguards

We take the following measures to prevent misuse:

• Domain verification required: Users must prove domain ownership via DNS TXT record, file upload, or HTML meta tag before any scanning. See our domain verification feature for the full workflow.
• Legal attestation required: Users must sign a legally binding attestation confirming their authorisation to test, recorded immutably with IP and timestamp.
• Rate limiting: Scan frequency is limited by plan tier and per-domain rate limits.
• Blocklist: Government, military, critical infrastructure, and cloud provider management domains are blocked.
• Audit trail: All scan activity is logged with full attribution.

Report Unauthorised Scanning

If you believe your systems are being scanned by SecPortal without your authorisation, please contact us immediately:

We investigate all reports within 24 hours and will immediately suspend scanning against the reported domain pending review. For more details, see our Acceptable Use Policy.