ScanOps

Visitor

Public Mode

Enterprise Knowledge Base

ScanOps Documentation

Enterprise operational guide for ScanOps modules, field-level controls, and secure usage patterns.

Authorized Use Notice

ScanOps is for authorized internal security operations only. Use of this platform outside approved scope is prohibited.

Getting Started

Access ScanOps via /login/ and review this documentation before first use.
Sign in with an approved role and verify your sidebar module access.
Create or confirm target inventory, then submit a controlled New Scan request.
Monitor runtime in Running and Scan Queue, then review Results and History.
Generate Reports for stakeholders and configure Schedule for recurring controls.

Module Documentation

Each module section includes What it is, Why it is used, How to use, Field-by-field guidance, real examples, best practices, and warnings.

dashboard

Dashboard

Enterprise module reference and operational usage guidance.

What Is It

Dashboard is the operational command view that summarizes scan activity, request volume, result trends, reports, notifications, and assets in one place.

Why It Is Used

Gives operators immediate visibility into current workload and outcomes.
Reduces time-to-triage by surfacing high-value metrics and recent activity first.
Supports daily review, handover notes, and management reporting.

How To Use

Review the KPI cards at the top to assess your current scope.
Check the Scan Requests (Last 7 Days) chart for trend changes.
Use Activity Summary to understand Draft, Pending, Validated, and Rejected request mix.
Open Recent Targets and Recent Scan Requests to continue active investigations quickly.

Field-By-Field Explanation

Field / Option	Explanation	Examples
Scope Label	Shows whether cards and lists are scoped as My data or All data based on your role.	-
KPI Cards	Targets, Scan Requests, Pending Requests, Validated Requests, Running Scans, Reports, Unread Notifications, and Assets.	-
Scan Requests (Last 7 Days)	Day-by-day bar chart of request volume used for throughput trend analysis.	-
Activity Summary	Compact counts for Draft, Pending, Validated, and Rejected request states.	-
Quick Actions	New Scan and Add Target shortcuts, with visibility based on your account access scope.	-

Real Examples

Morning operations check: verify Running Scans and Pending Requests before creating new workload.
Weekly review: compare daily request chart trend with report generation output.

Best Practices

Use Dashboard as a pre-flight check before launching new scans.
Investigate sudden spikes in Pending Requests or Failed executions immediately.
Confirm scope label before exporting metrics into stakeholder reports.

Warnings

Do not treat dashboard counts as final evidence without validating underlying records.

add_circle

New Scan

Enterprise module reference and operational usage guidance.

What Is It

New Scan is the controlled request builder used to submit validated scan jobs with policy-governed options.

Why It Is Used

Standardizes scan creation so teams follow the same safe workflow.
Captures audit-ready context and validates configuration before runtime execution.
Prevents invalid or unsafe request combinations from entering the execution queue.

How To Use

Open New Scan from Dashboard or sidebar.
Select Target and optional Scan Profile.
Set Scan Type, Timing Profile, and Port Scope.
Choose Controlled Options required for your objective.
Add Notes for audit/compliance context.
Review the live preview panel, then click Submit Scan Request.

Field-By-Field Explanation

Field / Option	Explanation	Examples
Target	Defines what host or network will be scanned. Supported target formats include single IP, domain, or CIDR ranges.	192.168.1.10 example.com 10.0.0.0/24
Scan Profile (optional)	Predefined template that can prefill scan strategy, timing, and options. Use profiles for repeatable scanning standards; use manual setup for custom needs.	-
Scan Type	Logical classification controlling primary scan behavior. Available values: Host Discovery, Quick TCP, Top 100, Top 1000, Service Detection, Safe Basic.	-
Timing Profile	Controls speed-versus-load tradeoff. Normal is conservative baseline, Balanced mixes speed and stability, Fast increases aggressiveness and network pressure.	Normal Balanced Fast
Port Scope	Defines ports to probe. Supports single, multi, range, and mixed patterns.	80 22,80,443 1-1024 80,443,8000-8100
Controlled Options	Feature toggles that tune scan depth and runtime behavior. Use only the options required for the current objective.	Host Discovery Service Detection Version Detection OS Detection Traceroute DNS Resolution
Host Discovery	Checks host reachability before deeper probing to reduce unnecessary traffic.	-
Service Detection	Identifies running services such as nginx, apache, ssh, mysql, and similar.	-
Version Detection	Attempts service version fingerprinting for patch/vulnerability triage.	-
OS Detection	Infers operating system characteristics to improve inventory context.	-
Traceroute	Collects network path hops to aid routing and segmentation troubleshooting.	-
DNS Resolution	Resolves hostnames where possible to improve readability and reporting context.	-
Notes	Operational and audit context field used for approvals, intent, and compliance tracking.	Weekly security scan for production API servers

Real Examples

Production API baseline: Target 10.10.20.0/24, Scan Type Top 1000, Timing Balanced, Notes with change-ticket ID.
Urgent verification: Target app.example.com, Quick TCP + Service Detection, limited Port Scope 22,80,443.

Best Practices

Start with Safe Basic or conservative profiles before enabling deeper options.
Keep Port Scope focused on required business services when scanning critical infrastructure.
Always populate Notes with owner, purpose, and approval reference.
Use live preview feedback before submission to catch configuration mistakes early.

Warnings

Fast timing and broad Port Scope can increase target/network load significantly.
Incorrect Target format or scope selection can scan unintended systems.
Enabling multiple deep-detection toggles may increase runtime and noise.

sync

Running

Enterprise module reference and operational usage guidance.

What Is It

Running is the live execution monitor for active and recently processed scan jobs.

Why It Is Used

Gives real-time visibility into execution progress and stage transitions.
Enables quick intervention for failed, stalled, or misconfigured runs.
Provides worker and queue context needed for runtime troubleshooting.

How To Use

Open Running and review summary cards for Running, Queued, Completed, and Failed states.
Filter the table using Status, Queue State, User, Target, and Search.
Open Monitor for live status panel and event log stream.
Use Cancel or Retry actions when role permissions allow.

Field-By-Field Explanation

Field / Option	Explanation	Examples
Search	Matches target values, execution IDs, and worker names.	-
Status	Execution state filter: Queued, Running, Completed, Failed, Cancelled.	-
Queue State	Queue lifecycle filter: Waiting, Assigned, Processing, Done, Error.	-
User	Requested-by filter for multi-user operational teams.	-
Target	Target-specific execution filter.	-
Progress	Shows progress percent and current stage for each execution.	-
Worker	Displays assigned worker_name, or Unassigned when pending.	-

Real Examples

During incident response, filter Status=Running and Target=<affected host> for immediate visibility.
For recovery ops, filter Status=Failed then use Retry where policy permits.

Best Practices

Use Monitor view for confirmed runtime diagnosis before cancelling jobs.
Correlate Worker and Queue State when troubleshooting throughput issues.
Review Completed vs Failed trend per shift to detect pipeline instability.

Warnings

Frequent cancel/retry loops can create queue churn and delay other jobs.

queue

Scan Queue

Enterprise module reference and operational usage guidance.

What Is It

Scan Queue displays jobs waiting for execution or currently being assigned/processed by workers.

Why It Is Used

Provides queue depth and position visibility before jobs start running.
Helps operators prioritize workloads and estimate execution start times.
Supports capacity planning by highlighting assignment and processing bottlenecks.

How To Use

Review queue summary cards for Total Queued, Assigned, Processing, and Failed Queue State.
Filter by Queue State, Target, Submitted By, and Search.
Use Position, Priority, and Est. Wait columns to estimate dispatch timing.
Open Monitor to jump into execution detail once assignment begins.

Field-By-Field Explanation

Field / Option	Explanation	Examples
Queue State	Primary filter for waiting/assigned/processing/error queue stages.	-
Target	Limits queue rows to a target or subnet-specific workload.	-
Submitted By	Identifies owner/user pipeline load in shared teams.	-
Priority	Displayed as P<value>; lower queue order and dispatch behavior are role-policy dependent.	-
Est. Wait	Approximate wait indicator for planning, not an SLA guarantee.	-
Assigned Worker	Shows selected worker or pending assignment state.	-

Real Examples

Before maintenance windows, confirm high-priority jobs are near top queue positions.
If queue backlog grows, validate worker availability in Queue & Worker Status.

Best Practices

Keep queue filters focused during incident periods to avoid operator overload.
Use Submitted By filter during team handovers to reassign ownership quickly.

Warnings

Estimated wait values are approximations and can shift with new higher-priority jobs.

analytics

Results

Enterprise module reference and operational usage guidance.

What Is It

Results is the structured findings workspace for completed scan executions.

Why It Is Used

Turns raw execution output into operator-friendly risk and service intelligence.
Supports remediation prioritization through host state and service evidence.
Provides exportable evidence for audits and incident workflows.

How To Use

Filter using Target, Execution Status, Profile, Service Detected, Risk Level, and date range.
Open a result to inspect host status, open ports, services, and raw/parsed outputs.
Use Compare to evaluate drift between two snapshots.
Use Export actions for downstream analysis and reporting.

Field-By-Field Explanation

Field / Option	Explanation	Examples
Search	Find by scan ID, hostname, or target snapshot text.	-
Target	Target-specific result filter.	-
Execution Status	Filters results by execution lifecycle state.	-
Profile	Filters by associated scan profile used during request.	-
Service Detected	Matches service strings such as http, ssh, mysql.	-
Risk Level	Port/service risk classification filter.	-
Date From / Date To	Time-bounds result review windows.	-
Actions	Open, Compare, Re-run, and Export based on capability.	-

Real Examples

Post-release validation: filter by Target + Date From and compare against previous baseline.
Threat hunt: filter Service Detected=ssh and Risk Level=high for fast triage.

Best Practices

Validate suspicious findings with raw output before escalation.
Use comparison mode for change-driven investigations rather than ad hoc guesswork.
Review host-down results alongside execution logs to separate network issues from host outages.

Warnings

Do not assume low-risk labels eliminate business impact; verify service context.

history

History

Enterprise module reference and operational usage guidance.

What Is It

History is the long-term execution ledger for completed, active, and archived runs.

Why It Is Used

Preserves operational traceability for audits and incident post-analysis.
Enables trend review and replay operations such as clone/re-run workflows.
Supports lifecycle management through archive, restore, and controlled delete actions.

How To Use

Choose the correct tab: All History, My History, or Archived.
Apply filters for Search, Status, Target, Profile, User (when available), and date range.
Use row actions for Monitor/Result, Re-run, Clone, Compare, or Archive based on state and role.
Use Archived tab for restore/delete lifecycle tasks where authorized.

Field-By-Field Explanation

Field / Option	Explanation	Examples
Page Mode Tabs	All History, My History, and Archived context selection.	-
Status	Execution state filter for lifecycle analysis.	-
Target	Target-specific historical analysis.	-
Profile	Profile-level historical behavior and policy traceability.	-
User	Requested-by filter for multi-operator reviews.	-
Archived	Indicates whether a record is in archived lifecycle state.	-
Actions	Re-run, Clone, Compare, Archive, Restore, Delete as permitted.	-

Real Examples

Quarterly audit: pull Archived records for retention and compliance checks.
Change impact study: use Compare across historical executions on the same target.

Best Practices

Prefer archive over delete for audit-safe retention when policy requires traceability.
Use clone for repeatability when recreating prior scan conditions.

Warnings

Delete actions are irreversible and should follow approval policy.

description

Reports

Enterprise module reference and operational usage guidance.

What Is It

Reports provides governed generation, review, and export of operational and executive reporting.

Why It Is Used

Converts scan and asset evidence into stakeholder-ready formats.
Improves communication between technical teams and decision makers.
Supports compliance, audit narratives, and remediation planning artifacts.

How To Use

Open Reports to review previously generated documents with filters.
Use Generate Report to choose source type and report type.
Select source records, include sections, add summary notes, and generate output.
Preview details, then Download or Print for distribution.

Field-By-Field Explanation

Field / Option	Explanation	Examples
Report Title	Custom title; system can auto-generate when left blank.	-
Source Type	Scan Result, Scan Execution, Comparison, or Asset.	-
Report Type	Executive Summary, Technical Report, Comparison Report, Per-Host Report.	-
Output Format	HTML, PDF, JSON, or TXT.	-
Source Result	Required when Source Type is Scan Result.	-
Source Execution	Required when Source Type is Scan Execution.	-
Comparison Baseline	Left-side result used as historical baseline.	-
Comparison Current	Right-side result used as current comparison target.	-
Asset	Required when Source Type is Asset.	-
Include Sections	Summary, Ports, Services, Findings, Timeline toggles.	-
Summary Notes	Narrative context for business and audit consumers.	-
List Filters	Search, Type, Format, Status, Generated By, From, To.	-

Real Examples

Executive weekly update: Executive Summary in PDF with Summary + Findings sections.
Technical diff review: Comparison Report between baseline and current result snapshots.

Best Practices

Use consistent naming conventions for report titles (system, scope, date).
Keep Summary Notes concise and action-oriented for faster stakeholder review.
Verify source objects belong to the intended environment before publishing output.

Warnings

Comparison reports require two distinct results; selecting the same result is invalid.

calendar_clock

Schedule

Enterprise module reference and operational usage guidance.

What Is It

Schedule manages recurring scan orchestration for continuous security monitoring.

Why It Is Used

Automates repeatable scan operations without manual request creation each cycle.
Supports predictable monitoring cadence for critical systems and environments.
Creates execution history for recurring controls and audit evidence.

How To Use

Open Schedule and review Active, Paused, and Due Soon summary cards.
Create a schedule and define frequency, timing window, and scan options.
Use Run Now for immediate execution, or toggle enable state for lifecycle control.
Review Schedule History for triggered run status and linked reports.

Field-By-Field Explanation

Field / Option	Explanation	Examples
Schedule Name	Human-readable identifier for recurring job intent.	-
Target	Target to be scanned on each scheduled run.	-
Profile	Optional profile to standardize recurring scan behavior.	-
Scan Type	Host Discovery, Quick TCP, Top 100, Top 1000, Service Detection, or Safe Basic.	-
Timing Profile	Normal, Balanced, or Fast runtime behavior control.	-
Frequency	One Time, Daily, Weekly, Monthly, or Custom.	-
Port Scope	Ports/ranges to probe per scheduled execution.	-
Custom Recurrence Rule	Required in Custom frequency mode.	-
Start At / End At	Execution window boundaries for schedule validity.	-
Host Discovery	Reachability check before deeper probes.	-
Service Detection	Service fingerprinting toggle.	-
Version Detection	Version fingerprinting toggle.	-
OS Detection	Operating system inference toggle.	-
Traceroute	Path analysis toggle.	-
DNS Resolution	Hostname resolution toggle.	-
Enabled	Controls whether the schedule is active for trigger processing.	-
Notify on Run	Emits notification events for schedule-triggered executions.	-
List Filters	Search, Frequency, State, Owner, Next Run From, Next Run To.	-

Real Examples

Daily perimeter check at off-peak hours with Balanced timing and targeted Port Scope.
Weekly service baseline collection with Notify on Run enabled for SOC visibility.

Best Practices

Name schedules with environment + objective + cadence.
Use conservative timing for large network ranges to reduce scan pressure.
Review Due Soon and Schedule History regularly to catch missed or failed triggers.

Warnings

Custom recurrence rules can create high-frequency runs if configured incorrectly.
Large scope plus deep detection toggles can increase queue load during peak windows.

notifications

Notifications

Enterprise module reference and operational usage guidance.

What Is It

Notifications is the operational alert inbox for scan, schedule, report, policy, asset, and system events.

Why It Is Used

Reduces missed events by centralizing action-required alerts.
Provides direct links to related execution, result, schedule, report, and asset records.
Supports workload triage using severity and read state.

How To Use

Review summary cards for Total, Unread, and Critical Unread.
Filter by Read State, Type, Severity, and date range.
Open detail view to inspect context and related objects.
Use Mark Read/Unread actions to keep the queue operationally clean.

Field-By-Field Explanation

Field / Option	Explanation	Examples
Search	Matches notification title, message, execution ID, or related asset name.	-
Read State	All, Unread, or Read filter.	-
Type	Scan Completed, Scan Failed, Schedule Triggered, Report Generated, Asset Changed, Policy Alert, System Alert.	-
Severity	Info, Success, Warning, or Error.	-
From / To	Date range filters for alert timeline review.	-
Detail Fields	Title, message, type badge, severity badge, read state, related links, and activity timeline.	-

Real Examples

Filter Severity=Error + Unread to prioritize high-impact failures first.
Open schedule-triggered alerts to validate recurring job outcomes.

Best Practices

Process unread critical alerts first during each shift.
Mark notifications after investigation to keep handoff clean.

Warnings

Ignoring unread policy or system alerts can hide control drift and runtime degradation.

inventory_2

Assets

Enterprise module reference and operational usage guidance.

What Is It

Assets is the discovered infrastructure inventory built from scan results and change telemetry.

Why It Is Used

Creates a living asset inventory tied directly to technical evidence.
Enables risk-driven prioritization through risk level, risk score, and service exposure.
Tracks longitudinal change through snapshots and asset change logs.

How To Use

Use list filters to isolate target networks, owners, risk level, and status.
Open an asset to review risk posture, ports, services, and linked scan history.
Switch tabs (Overview, Snapshots, Change History, Related Results, Notes) for deep investigation.
Use Sync from Results to refresh inventory from latest findings where permitted.

Field-By-Field Explanation

Field / Option	Explanation	Examples
Search	Find by asset name, IP, or hostname.	-
Target	Limit inventory to a network/target context.	-
Owner	Owner/team metadata filter via owner_name.	-
Risk Level	Info, Low, Medium, High, Critical classification filter.	-
Status	Active, Inactive, Monitoring, Archived lifecycle state.	-
Last Seen From / To	Temporal filter for asset recency tracking.	-
Detail Metrics	Risk Score, Risk Level, Status, Open Ports, Last Scanned.	-
Detail Tabs	Overview, Snapshots, Change History, Related Results, Notes.	-
Change Types	Ports Added, Ports Removed, Service Changed, OS Changed, Asset Created, Asset Updated.	-

Real Examples

Identify stale exposure: Status=Monitoring with old Last Seen dates for verification.
Investigate service drift: open Change History for recent Service Changed events.

Best Practices

Review high and critical risk assets first each cycle.
Validate ownership fields for accountability and routing.
Correlate Related Results before opening remediation tickets.

Warnings

Asset data reflects scan observations; unknown services still need manual validation.

monitor_heart

System Health

Enterprise module reference and operational usage guidance.

What Is It

System Health is the platform reliability console for core dependencies and worker runtime.

Why It Is Used

Detects service degradation before it impacts scan operations.
Supports rapid root-cause analysis for queue delays and failed execution spikes.
Provides auditable health snapshots for operational governance.

How To Use

Open System Health and review Overall Status first.
Inspect service cards and alerts for Database, Queue, Scheduler, Storage, and tooling checks.
Use Queue & Workers to inspect worker fleet state and job backlog.
Review timeline to confirm whether issues are persistent or transient.

Field-By-Field Explanation

Field / Option	Explanation	Examples
Overall Status	Roll-up health state derived from service check severity.	-
Service Cards	Django App, Database, Nmap Binary, Queue Service, Scheduler, Storage.	-
Alerts	Warning/Error snapshots auto-refreshed for recent anomalies.	-
Recent Health Timeline	Service, status, summary, and checked_at history rows.	-
Worker Summary	Total Workers, Online, Degraded, Offline, Active Jobs, Queue Backlog, Failed Jobs.	-
Worker Status	Per-worker heartbeat, active jobs, queued jobs, failed jobs, and derived runtime status.	-

Real Examples

If queue backlog rises while workers show degraded/offline, escalate runtime capacity review.
If scheduler is warning with overdue runs, verify schedule trigger pipeline and worker health.

Best Practices

Check System Health before diagnosing scan-level failures.
Correlate health anomalies with execution failure windows in Running/History.
Use timeline history in post-incident reports.

Warnings

Ignoring repeated warning states can lead to silent operational failure over time.

Security & Access Control

Role-based access control governs module capabilities and action buttons.
User-owned data isolation limits private records to their owners.
Scoped users cannot access other users' private targets, scans, results, reports, schedules, notifications, or assets.
Administrative roles can have broader operational visibility based on policy.
All scans must remain within approved authorization boundaries.

Recommended Workflow

Login and validate your operational scope.
Add/select authorized targets.
Create New Scan request with safe defaults.
Observe Running and Queue states until completion.
Analyze Results and compare with History.
Generate and distribute Reports.
Create recurring Schedule entries for ongoing monitoring.

Best Practices

Prefer conservative scan configurations before deep fingerprinting in production.
Capture meaningful Notes and report summaries for audit readiness.
Investigate failed or degraded runtime indicators before increasing scan load.
Use comparative analysis to identify true change instead of one-off anomalies.
Only scan assets explicitly authorized by policy.

Support / Help

For access issues, role changes, failed workflows, or platform anomalies, contact your ScanOps administrator or security operations lead. Include time window, module name, target scope, and execution/report IDs to accelerate triage. For product improvements use /feedback/suggestions/, and for defects or operational incidents use /feedback/issues/ with optional evidence attachments.