> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oasm.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Tools & Providers

> Install and manage scanning tools and their providers in OASM

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](/worker). 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](/target). 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:

<Table>
  | Tool type              | What it does                                      |
  | ---------------------- | ------------------------------------------------- |
  | Subdomain discovery    | Finds subdomains belonging to your domains        |
  | Website probing        | Checks which websites and services respond        |
  | Port scanning          | Finds open ports and the services running on them |
  | Vulnerability scanning | Searches for security weaknesses                  |
  | Screenshots            | Captures visual previews of discovered websites   |
</Table>

### 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](/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](/api-keys) used by workers and API clients.

## Browse tools

<Steps>
  <Step title="Open Management → Tools">
    Navigate to **Management → Tools** in the console.
  </Step>

  <Step title="Review the tool list">
    The page lists the tools available to the platform. Each row shows a status badge — **Built-in** for tools shipped with OASM, **Installed** for tools you have installed.
  </Step>

  <Step title="Open a tool detail page">
    Select a tool to view its detail page, including its type and install state.
  </Step>
</Steps>

## Install a tool

<Steps>
  <Step title="Open the tool">
    Navigate to **Management → Tools** and open the tool you want to install.
  </Step>

  <Step title="Install the tool">
    Trigger the install action for the tool. Installing makes the tool available to the platform so workers can execute it.
  </Step>

  <Step title="Verify the status badge">
    After installation completes, the tool's status badge changes to **Installed**.
  </Step>
</Steps>

## Add a tool to a workspace

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

<Steps>
  <Step title="Confirm the tool is installed">
    The tool must show the **Installed** badge before it can be added to a workspace.
  </Step>

  <Step title="Add the tool to the workspace">
    Trigger the add-to-workspace action for the tool against the workspace you want to enable it in.
  </Step>
</Steps>

<Info>
  **Uninstalling** a tool removes it from the platform. Consider whether any workspace still depends on the tool before uninstalling it.
</Info>

## 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.

<Danger>
  **Store tool API keys in a secret manager. Never commit them to version control, and rotate them whenever a team member who had access to them leaves.** Tool keys are credentials with the same sensitivity as the workspace API key.
</Danger>

## Manage providers

<Steps>
  <Step title="Open the Providers page">
    Navigate to the **Providers** page in the console.
  </Step>

  <Step title="Review existing providers">
    The page shows a table of providers with **Name**, **Company**, **Website**, and **Status** columns.
  </Step>

  <Step title="Create a provider">
    Click the **Create** button to open the creation form.
  </Step>

  <Step title="Fill in the provider details">
    Provide the provider **name**, **company**, and **website**.
  </Step>

  <Step title="Save the provider">
    Submit the form. The new provider appears in the providers table and is ready for use.
  </Step>
</Steps>

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](/asset) inventory. This mapping determines what your inventory gains when a tool runs:

<Table>
  | Tool type              | What it adds to your assets            |
  | ---------------------- | -------------------------------------- |
  | Subdomain discovery    | Newly found subdomains                 |
  | Website probing        | Live websites and services             |
  | Port scanning          | Open ports and hosts                   |
  | Vulnerability scanning | Security findings attached to assets   |
  | Screenshots            | Visual previews of discovered websites |
</Table>

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.

<Accordion title="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.
</Accordion>

## 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](/api-keys) 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

<Card icon="cpu" title="Worker" horizontal href="/worker">
  Understand how workers execute installed tools as scan jobs
</Card>

<Card icon="target" title="Targets" horizontal href="/target">
  Define the scan targets that installed tools run against
</Card>

<Card icon="box" title="Assets" horizontal href="/asset">
  See the assets and services that tool findings feed
</Card>