Tools & Providers

Tools are the extensible scanning framework of OASM. A tool performs one discrete security action — subdomain discovery, website probing, port scanning, vulnerability scanning, or screenshots — and is installed into the platform and executed by workers. A provider supplies the actual implementation behind one or more tools. The framework keeps the platform decoupled from any specific scanner: the tool model describes what the platform needs to run, and providers make how it runs pluggable. Adding a new scanning capability is a matter of installing a tool and, when the tool needs external authentication, attaching a provider API key.

​

Key concepts

​

Tool

A tool is a unit of scanning capability that workers can execute as part of a job. Each tool belongs to a single category that describes the kind of security action it performs.

​

Tool types

Tools come in a few types, each performing a different security action:

​

Provider

A provider supplies the actual tool implementation. It has a name, an optional company, and a website. Providers are listed in the Console with a status so you can tell which ones are ready to use.

​

Install vs. add to workspace

These are two different operations:

• Install makes the tool available to the platform as a whole. An installed tool can be executed by workers.
• Add to workspace associates an installed tool with a specific workspace, making it usable inside that workspace’s scans.

A tool must be installed before it can be added to a workspace.

​

API keys for tools

Some tools authenticate against external services (for example, a vulnerability scanner’s cloud API). Each tool can hold its own API key, stored per tool and managed in the console. Keep these credentials rotated and protected — they are separate from the workspace API key used by workers and API clients.

​

Browse tools

​

Install a tool

​

Add a tool to a workspace

Once a tool is installed, make it available inside a workspace:

​

Manage tool API keys

Tools that integrate with external providers can carry their own API key. You can read, set, or update the stored key from the tool’s page in the console.

​

Manage providers

Existing providers can be edited and inspected directly from the providers list.

​

How tools map to what they discover

Each tool type feeds a specific kind of information into your assets inventory. This mapping determines what your inventory gains when a tool runs: The pattern to remember: host-level findings (subdomains, open ports, vulnerabilities) describe the asset itself, while service-level findings (website probes, screenshots) describe a specific service it runs.

Why do some tools describe the asset and others its services?

Findings that describe a host — such as a newly enumerated subdomain or an open port — belong to the asset itself. Findings that describe a specific running service on a host — such as a website probe result or a screenshot of a web service — belong to that service. This keeps the asset inventory clean: one asset with many services, each service carrying its own service-level evidence.

​

Best practices

• Install only what you need. Every installed tool adds execution surface for workers and potential findings to process. Start with the types that match your scanning priorities and add more as your program grows.
• Keep provider API keys rotated. Treat tool API keys like the workspace API key: rotate them regularly and after personnel changes. Use the workspace API key rotation guidance as your baseline policy.
• Match tools to your target scope. Host-level enumeration and port scanning describe assets; probing and screenshots describe services. Choose tool types that produce the information you actually track.
• Assign provider API keys per tool, not per workspace. Tool keys are stored on the tool itself, which keeps credentials with the capability that consumes them.
• Review the providers table periodically. The Status column tells you which providers are usable; clean up providers you no longer maintain.

​

Related