Architecture

OASM is built as a three-tier system that separates the way you interact with the platform from the heavy scanning work it does for you:

1. Web console — the operations interface you use every day: asset inventory, dashboards, targets, issues, reports, workflows, and management pages.
2. Platform service — the brain of the system. It holds the business logic, coordinates scanning, stores results, and sends notifications.
3. Scanning workers and database — workers execute the security tools against your attack surface, and the database stores everything the platform collects.

​

The three tiers

​

1. Web console

The Console is the single pane of glass for the platform: asset inventory, dashboards, targets, groups, issues, reports, workflows, notifications, and management pages such as workers and API keys. The Console runs in your browser, communicates with the platform service over secure connections, and holds no business logic of its own — it simply presents what the platform knows and lets you act on it. It reflects job state from the registry and streams in activity in real time.

​

2. Platform service

The platform service is the brain of OASM. It owns the business logic, persistence, and orchestration:

• Authentication and workspaces — who can access what.
• Targets and assets — what you monitor and what has been discovered.
• Jobs registry — every scan, discovery, and workflow run is tracked here.
• Workflows and tools — the automation and the scanning tools workers execute.
• Integrations and notifications — forwarding events to Slack, Telegram, webhooks, and ticketing services.
• Reports, audit, and search — how you review and find what the platform has collected.

The platform service also runs background processing: it enqueues jobs, merges scan results into your inventory, sends notifications, and updates dashboard statistics.

​

3. Scanning workers and database

Workers are the execution layer — small programs that connect securely to the platform with a workspace API key and pull jobs as capacity frees up. They run the installed scanning tools for each job category and report progress and results back. Because they are stateless, they scale horizontally without coordination — see Worker. The database is the platform’s memory: it stores your inventory of assets, services, and vulnerabilities, plus system state. Supporting services include a fast in-memory layer used for queues and caching, geo-location enrichment for your assets, and object storage for screenshots and scan artifacts.

​

How a scan becomes part of your inventory

The job lifecycle is the core pipeline of OASM. Every scan, discovery, and workflow run is a job recorded in the jobs registry:

1. Trigger. A job is created by a manual discovery, a workflow run, or a scheduled run against a target.
2. Waiting. The job is queued and waits for a connected worker. Jobs at this stage consume no compute.
3. Running. A worker picks up the job and executes its tool steps in order, depending on the job category.
4. Results merge. The worker streams results back to the platform, which merges them into your workspace inventory.
5. Downstream. Merged results drive vulnerability findings, notifications, dashboard statistics, and asset state (such as TLS status).
6. Finished. The job ends as completed, failed, or cancelled and remains inspectable in the Job Registry.

​

The data pipeline

The data adapter inside the platform service turns raw tool output into structured inventory. Each job category has a merge path:

• Subdomain discovery — newly found hosts and domains are added to your assets.
• HTTP probing — live web services are attached to your assets.
• Port scanning — open ports are attached to your assets.
• Vulnerability scanning — findings are linked to your assets.
• Screenshots — screenshots are attached to your web services.

Merged results flow to assets and services, where they are enriched with technologies, locations, and TLS state. New detections fire notifications such as “new asset detected” and “new vulnerability found” — see Notifications.

​

Automation and events

The platform coordinates work asynchronously:

• Job distribution — jobs are queued and consumed by workers as capacity frees up.
• Workflow chaining — workflows can react to lifecycle events, so a discovery workflow can automatically kick off a scan workflow when it finishes. See Workflows.
• Notifications — events stream to the Console and forward through integrations such as Slack, Telegram, and webhooks.

​

Security

• Workspace isolation — every workspace is a hard data boundary; assets, jobs, workflows, and settings are scoped to it.
• Permission groups — each member can only see and change what their role allows. See Permissions.
• API key authentication — programmatic clients and workers authenticate with the workspace API key. See API keys.
• Audit log — an append-only audit trail records member and configuration actions. See Audit log.

​

Deploying the architecture

The full stack — web console, platform service, workers, and supporting services — is defined in the platform’s Docker Compose deployment. See Deployment for production configuration, scaling, and the environment reference.

​

Related