Core Concepts

OASM (Open Attack Surface Management) is an open-source platform that continuously discovers, monitors, and analyzes your internet-facing assets. It turns raw scanning results into an organized inventory of assets, vulnerabilities, and triage issues that your security team can act on. This page builds the mental model you need to use the platform effectively: the vocabulary, the moving parts, and how data flows through the system. Open-source and licensed under GPL-3.0.

​

Who this is for

OASM is built for security teams and platform owners who need continuous visibility into what they expose:

• Security analysts track the attack surface, review vulnerabilities, and triage findings into issues.
• SRE and platform teams keep an inventory of internet-facing services and detect drift or forgotten infrastructure.
• Managed service providers run isolated workspaces per client on a single instance.

The sections below assume you have completed the onboarding and joined at least one workspace. If you have not deployed OASM yet, start with the Deployment guide.

​

Platform architecture at a glance

OASM runs as three cooperating parts:

• Console — the web application you use to manage workspaces, targets, assets, vulnerabilities, and workflows.
• Core engine — the service that holds the business logic, stores data, and coordinates every scan.
• Workers — the components that pull work from the core engine and execute scanning tools against your attack surface.

Behind the core engine, a set of supporting services provides storage and enrichment:

• Database — the primary data store for assets, scan results, vulnerabilities, and system state.
• Queue — coordinates scan jobs and keeps the system responsive under load.
• Geo IP service — resolves geographic information for discovered assets.
• Object storage — stores artifacts such as screenshots and scan outputs.

See Architecture for the full system design.

​

How it fits together

Everything in OASM is organized around one loop: you define targets, the platform discovers assets, tools find vulnerabilities, and your team triages them into issues. The discovery pipeline works as follows:

​

The core loop

A concise way to remember the pipeline: target → discovery job → worker executes tools → inventory updated → vulnerabilities → issues → reports and notifications. New detections and vulnerability findings trigger Notifications, and dashboards and reports reflect the updated inventory — so what you see is only as fresh as the last completed discovery job.

​

Targets and scope

A Target is the root you ask the platform to investigate: a root domain, an IP address, or a CIDR range. Every target carries a scope type — Internal or External — because the two classes of infrastructure are treated differently. External scope is infrastructure facing the internet; internal scope is your own ranges, modeled separately so the platform can distinguish what should not be publicly reachable. See Targets.

​

Discovery jobs and the job registry

Discovery is job-driven. A job is a unit of work in the job registry with a category, a run type (manual or scheduled), and a status. A scan can be Queued, Running, Completed, Failed, or Cancelled. Jobs are picked up by workers as capacity frees up — a job stays Queued until a worker claims it. The job registry gives you a single place to watch every scan, discovery, and execution job in the workspace. See Jobs and Workers.

​

Assets and enrichment

When a job completes, new findings are added to your inventory automatically. Assets are discovered internet-facing entities — domains, IP addresses, and services — enriched with technologies, certificates, screenshots, and geographic data. Configuration matters here too: the workspace’s Asset discovery and Auto enable assets settings decide whether discovery runs and whether new assets are automatically enabled. See Assets, Tools, and Workspaces.

​

Vulnerabilities and issues

Detected weaknesses become Vulnerabilities with a severity rating, tags, first/last seen timestamps, the scanning tool, and optional AI analysis. Vulnerabilities are ranked Critical, High, Medium, Low, or Informational. Vulnerabilities are findings; Issues are the triage layer on top — they wrap findings, carry an Open or Closed status, and support comments so a team can track remediation. Dismissing a finding records why: it was a false positive, used in a test, or not going to be fixed. See Vulnerabilities and Issues.

​

Automation and alerting

Workflows turn the pipeline into repeatable automation that starts jobs — reference templates include domain discovery, IP address discovery, and basic vulnerability scanning. Notifications arrive when a new asset is discovered, a new vulnerability is found, a vulnerability analysis finishes, someone is invited to the workspace, or a workspace is created. Reports let you export and summarize what the pipeline has produced. See Workflows, Notifications, Reports, and Integrations.

​

Glossary (A–Z)

Each entry defines the term and explains where it fits in the platform.

API Key

A workspace credential that identifies automated callers and proves they may interact with that workspace. Workers and your own automation all authenticate with it. Each workspace has a single active key that can be rotated; rotating invalidates the old key immediately. See also: API keys, Workers.

Asset

A discovered, internet-facing entity: a domain, an IP address, or a service. Assets carry enriched metadata such as technologies, certificates, and screenshots. See also: Assets, Tools.

Asset Group

A named collection of assets used to scope discovery and automated workflows. Groups let you operate on a subset of assets — attach scanning tools and run scheduled jobs against only the members of the group. See also: Groups.

Integration

An external connection configured in the workspace: Cloudflare as a cloud provider, Slack, Telegram, or Webhook for notifications, and Jira for ticketing (marked Coming soon). Integrations extend what OASM can reach — from pulling provider context to pushing alerts and issues out. See also: Integrations.

Issue

A triage wrapper around one or more vulnerabilities. Issues carry an Open or Closed status and support comments, so a team can track a finding from first report to remediation. Closed issues leave active workflows but remain accessible for review. See also: Issues.

Job

A unit of work in the job registry. A job carries a category, a run type (manual or scheduled), and a status — Queued, Running, Completed, Failed, or Cancelled. Jobs are picked up by workers and their progress is visible in the console. See also: Jobs, Workers.

MCP

The Model Context Protocol server built into OASM. It exposes workspace data to AI assistants (Claude, Cursor, VS Code, and other MCP-compatible clients), letting you query assets, vulnerabilities, and statistics in natural language. See also: MCP Server.

Notification

An event-driven alert sent through configured integrations. Notifications arrive when a new asset is discovered, a new vulnerability is found, a vulnerability analysis finishes, someone is invited to the workspace, or a workspace is created. Event and severity filters decide which alerts reach your channels. See also: Notifications, Integrations.

Permission Group

A role definition that bundles read/write permissions for a workspace. OASM ships Owner, Admin, and Read only groups plus custom groups you can build. See also: Permissions, Members, Users and roles.

Scan / Discovery

The job-driven process of investigating a target. Discovery runs in categories — subdomain discovery, HTTP probing, port scanning, vulnerability scanning, and screenshots — each mapped to tools that produce assets, services, or vulnerabilities. Discovery can run manually or on a schedule. See also: Targets, Groups, Tools.

Target

A root you ask the platform to investigate: a root domain, an IP address, or a CIDR range. Each target carries a scope type — Internal or External — which shapes how it is scanned and treated. Targets are the input to every discovery pipeline. See also: Targets.

Tool & Provider

The extensible scanner framework that OASM workers execute. Tools are the concrete scanners (for example subdomain enumeration, HTTP probing, port scanning, vulnerability detection, screenshots); providers supply integration with external services. The console reflects which tools are installed. See also: Tools, Workers.

Vulnerability

A finding produced by a scanning tool. Each vulnerability records a severity — Critical, High, Medium, Low, or Informational — along with tags, first/last seen timestamps, the tool that scanned it, and optionally AI analysis. When dismissed, a reason is recorded — a false positive, used in a test, or not going to be fixed — so the decision is auditable. See also: Vulnerabilities, Issues.

Worker

An agent that pulls jobs from the core engine and executes scanning tools. Workers authenticate with a workspace API key and run under a Workspace or Global scope. They are stateless and horizontally scalable — add more workers to increase processing capacity. See also: Workers.

Workflow

A repeatable automation that starts jobs. Workflows combine asset selection, tool configuration, and scheduling in one place. Reference templates include domain discovery, IP address discovery, and basic vulnerability scanning. See also: Groups, Targets.

Workspace

An isolated tenant for a team or organization and the foundation of OASM’s multi-tenancy. Everything — settings, members, API keys, targets, assets, and the audit log — is scoped to a workspace and invisible to other workspaces. You must belong to at least one workspace to use the platform. See also: Workspaces, Onboarding.

​

An example discovery cycle

To see these concepts in action, Onboarding walks one full cycle step by step. In short: you register a target, a workflow starts a discovery job, the results update your inventory, and your team triages findings into issues.

​

Best practices

• Start with a single, well-defined target and one discovery category, then widen scope as you gain confidence in the results.
• Use asset groups to keep recurring scans scoped to the assets that matter instead of rescanning everything.
• Treat workspaces as strict tenants — one per client, team, or environment.
• Let the pipeline inform your investigations: work from assets to vulnerabilities to issues, and use notifications to stay ahead of new detections.
• Rotate API keys regularly and keep them out of source control; the key is the trust boundary for workers and automation.

​

Related