# Core Concepts
Source: https://docs.osto.one/getting-started/core-concepts

A short tour of the model Osto uses across every module.

Once these four ideas are familiar, every other doc reads more easily.

## Assets — *what you're protecting*

Assets are the things in your environment Osto secures. You'll find them under **Assets** in the left sidebar:

* **Domains** — the websites, web apps, and subdomains you want Osto to protect. Manage the domains themselves and their TLS certificates.
* **Endpoint Users** — the people in your organization, with the devices they use. Osto applies endpoint protection and access policies through this list.
* **Server Access** — the servers Osto brokers access to:
  * **Secure Server** — a host where you install Osto's agent directly so access is granted through Osto.
  * **Secure Gateway** — a Linux host that brokers access to multiple child servers behind it (no agent install needed per child).
* **APIs** — discovered automatically from your protected domains and surfaced in dashboards under Insights. You don't register APIs manually.

<Note>
  Every policy, scan, and compliance control eventually points back to one of these assets. Onboard them early — the rest of the platform unlocks once they're in.
</Note>

## Objects — *reusable building blocks*

Objects are configurations you define once and reuse across many policies. They sit under **Objects** in the sidebar:

* **Domain Category** — group domains for policy targeting (e.g. *production sites*, *marketing sites*).
* **Application** — named applications used in App Control and DLP rules.
* **Port** — named network ports referenced in access and firewall rules.
* **Schedule** — time windows (e.g. *business hours*, *maintenance windows*) referenced in access policies.

<Tip>
  Objects keep policies short and consistent. Change a domain category in one place and every policy targeting that category updates with it.
</Tip>

## Policies — *how Osto behaves*

Policies attach security behavior to assets. The **Policies** section has three top-level sub-sections, organized by the asset type a policy applies to:

* **Endpoint Users** → Device Control, App Control, Domain Filtering, Data Leakage Prevention (with App File Access), Global Policy — controls what users can run, plug in, browse to, and copy out.
* **Domains** → Global Policies (DDoS, Bot) and Local Policies (Advanced, Custom Routing Rules, Policy Exceptions, API Discovery) — controls what reaches your websites and APIs, and how they're inspected.
* **Server Access** — the rules-list of who can reach which Secure Server (or child server behind a Secure Gateway), on which ports.

Customer-facing docs in this Knowledge Base cover these as three task-focused guides: the [User Protection Policy](/how-to-guides/policy-configuration/user-protection-policy), the [Website Protection Policy](/how-to-guides/policy-configuration/website-protection-policy), and the [Secure Server Access Policy](/how-to-guides/policy-configuration/secure-server-access-policy).

<Note>
  **Defaults that ship out of the box.** Osto comes with recommended defaults for every policy. You don't have to configure anything for protection to start — you only tune what's specific to your environment.
</Note>

## Modules you'll work alongside

Beyond Assets, Objects, and Policies, several sidebar sections layer additional capabilities on top of the model:

* **Scanner** — continuous vulnerability scanning for your domains (**Web Scanner**) and mobile apps (**App Scanner**).
* **Code Security** — source-code static analysis (**SAST**), integrated into your CI/CD.
* **Posture Management → Cloud Security** — connects AWS, Azure, and GCP for misconfiguration and drift detection.
* **Compliance** — controls, tasks, frameworks, and **Awareness Training** for SOC 2, ISO 27001, HIPAA, GDPR, and PCI DSS, drawing evidence from every other module.
* **Logs** — centralized records (Web App, Secure Server, Domain Filtering, Incident, Audit, Auth) usable for both daily monitoring and audit evidence.
* **Management** — admin access and usage / billing.

## Where to next

* New to the dashboard? Jump to the [Quick Start Guide](/getting-started/quick-start).
* Ready to bring assets onboard? See [Asset Management](/how-to-guides/asset-management/index).
* Want to tune protection? See [Policy Configuration](/how-to-guides/policy-configuration/index).


# Quick Start Guide
Source: https://docs.osto.one/getting-started/quick-start

Five steps from a brand-new Osto account to a dashboard reporting live security telemetry. Most teams finish in under an hour.

<Tip>
  If you haven't read [Core Concepts](/getting-started/core-concepts) yet, it's worth a 5-minute skim — every step below uses its vocabulary (Assets, Objects, Policies).
</Tip>

<Steps>
  <Step title="Create your account">
    1. Go to [**osto.one**](https://osto.one) and click **Sign Up**.
    2. Register with your work email, Google Workspace, or Microsoft account.
    3. Enter the OTP sent to your email to verify.
    4. Complete the short onboarding (organization name, primary contact).
    5. You'll land on the **Insights → Dashboard** view.
  </Step>

  <Step title="Take stock of the dashboard">
    Your home view — **Insights → Dashboard** — is the *Security Snapshot*: four headline KPIs (Security Adoption Score, Total Endpoints, Total APIs Discovered, Current Active Users) plus charts for Website Security Incidents, Top Web Categories, and Endpoint OS Distribution. They'll populate as you add assets.

    <img alt="Insights → Dashboard" />

    The **left sidebar** is your map to every module:

    | Section                                                | Purpose                         | When to use                |
    | ------------------------------------------------------ | ------------------------------- | -------------------------- |
    | **Assets**                                             | Register what you're protecting | Step 3                     |
    | **Objects**                                            | Define reusable building blocks | Optional, as policies grow |
    | **Policies**                                           | Tune protection behavior        | Step 4                     |
    | **Scanner**, **Code Security**, **Posture Management** | Continuous assessment           | Step 5                     |
    | **Compliance**, **Logs**                               | Evidence and monitoring         | Ongoing                    |
  </Step>

  <Step title="Add your first assets">
    Go to **Assets** in the sidebar and add at least one of each:

    * **Assets → Domains → Manage Domains** — add a domain or subdomain you want Osto to protect. APIs and certificates on that domain are discovered automatically.
    * **Assets → Endpoint Users** — invite the people in your organization. They'll be prompted to install the Osto agent on their laptops; once installed, endpoint posture and DLP policies start applying.
    * **Assets → Server Access → Secure Server** — register the servers you want Osto to broker access to. Follow the in-page setup instructions to install the connector.

    For a deeper walk-through of any of these, see [Asset Management](/how-to-guides/asset-management/index).
  </Step>

  <Step title="Apply the right policies">
    Osto ships with sensible defaults — you only configure exceptions. Open **Policies** and review:

    * **Policies → Endpoint Users** — Device Control, App Control, Domain Filtering, Data Leakage Prevention (with App File Access), and Global Policy for the people in your org. Detailed guide: [User Protection Policy](/how-to-guides/policy-configuration/user-protection-policy).
    * **Policies → Domains** — Global Policies (DDoS, Bot) and Local Policies (Advanced, Custom Routing Rules, Policy Exceptions, API Discovery) for the websites you added. Detailed guide: [Website Protection Policy](/how-to-guides/policy-configuration/website-protection-policy).
    * **Policies → Server Access** — rules for who can reach which Secure Server. See [Secure Server Access Policy](/how-to-guides/policy-configuration/secure-server-access-policy).
  </Step>

  <Step title="Turn on continuous assessment">
    You're protected — now make the protection observable.

    * **Posture Management → Cloud Security** — connect AWS, Azure, or GCP to start scanning your cloud configuration. Guides: [AWS](/how-to-guides/posture-management/connecting-aws), [Azure](/how-to-guides/posture-management/connecting-azure), [GCP](/how-to-guides/posture-management/connecting-gcp).
    * **Scanner → Web Scanner / App Scanner** — kick off continuous vulnerability scans on the domains and mobile apps you registered.
    * **Code Security → SAST** — wire your repository into CI for static analysis.
    * **Compliance → Frameworks** — pick the frameworks that apply (SOC 2 Type II, ISO 27001, HIPAA, GDPR, PCI DSS); Osto starts mapping evidence automatically from everything you turned on above.
    * **Logs** — Web App, Secure Server, Domain Filtering, Incident, Audit, and Auth logs are now flowing. Use them for daily monitoring and as evidence at audit time.
  </Step>
</Steps>

## You're live. What now?

Within an hour of finishing Step 3, the dashboard should be showing real activity. From here:

* Browse [How To Guides](/how-to-guides/asset-management/index) for module-specific walkthroughs.
* Skim [Best Practices](/support/best-practices) for configurations other teams have settled on.
* Bookmark [Troubleshooting Common Issues](/support/troubleshooting) and [FAQs](/support/faqs) for when something doesn't behave as expected.

<Tip>
  Need help? Contact your Osto representative at [connect@osto.one](mailto:connect@osto.one) or post in your shared support channel.
</Tip>


# Asset Management
Source: https://docs.osto.one/how-to-guides/asset-management/index

Everything you onboard into Osto for protection — domains, users, servers, and certificates.

Asset Management covers everything you onboard into Osto for protection. It maps to the **Assets** section in the dashboard sidebar:

```
Assets
├─ Domains
│  ├─ Manage Domains       → see Managing Websites & Subdomains
│  └─ Manage Certificate   → see Managing SSL Certificates
├─ Endpoint Users          → see Managing Users & Groups
└─ Server Access
   ├─ Secure Server        → standalone hosts (install script per host)
   └─ Secure Gateway       → broker + child servers behind it (private IPs)
```

## In this section

* [**Managing Websites & Subdomains**](/how-to-guides/asset-management/managing-websites) — register the web properties Osto should protect.
* [**Managing SSL Certificates**](/how-to-guides/asset-management/managing-ssl-certificates) — upload the certificates Osto presents to your origin servers.
* [**Managing Users & Groups**](/how-to-guides/asset-management/managing-users-groups) — onboard endpoint users and organize them into Usergroups.
* [**Managing Secure Servers**](/how-to-guides/asset-management/managing-secure-servers) — register the servers Osto brokers access to. Covers both standalone Secure Servers and Secure Gateways with child servers.

## Two paths for server access

Osto offers two ways to put a server behind Zero Trust access:

1. **Standalone Secure Server** — install Osto's agent directly on each server. Best for a small number of hosts, or hosts on different networks. **Linux and Windows** supported.
2. **Secure Gateway with Child Servers** — install the gateway agent once on a Linux host inside your network; then register child servers by their private IP. The gateway brokers connections to them — no per-server install needed. Best when many internal hosts share a network segment.

Both approaches are covered in [Managing Secure Servers](/how-to-guides/asset-management/managing-secure-servers).

## A typical onboarding order

1. **Domains first** — add your root domain (or just a subdomain) and update DNS to point traffic through Osto. Inbound protection becomes active immediately.
2. **Certificates** — upload a certificate so traffic between Osto and your origin stays encrypted.
3. **Endpoint Users** — invite your team. They install the Osto agent and start receiving endpoint policies.
4. **Secure Servers** — register the hosts you want Osto to broker access to (either standalone or behind a Gateway).

Once these are in, the rest of the platform (Scanner, Code Security, Posture Management, Compliance) has something to work with.


# Managing Secure Servers
Source: https://docs.osto.one/how-to-guides/asset-management/managing-secure-servers

Register the servers you want Osto to broker Zero Trust access to.

Once registered, end users can only reach the server through Osto — never directly.

Osto offers two patterns:

* **Standalone Secure Server** — install Osto's agent on each server.
* **Secure Gateway with Child Servers** — install one gateway, then register child servers by private IP. The gateway brokers the connections.

Both share the same access controls and policies; the difference is operational.

***

## Standalone Secure Server

> **Path:** Assets → Server Access → Secure Server

### Adding a Secure Server

<Steps>
  <Step title="Navigate to Secure Server">
    In the sidebar, go to **Assets → Server Access → Secure Server** and click **Add Secure Server +**.
  </Step>

  <Step title="Fill in the server details">
    * **Name** — a unique, identifiable name (appears in policies and logs).
    * **Secure Session Window** — how long a brokered session stays active, in minutes. Default is **60 minutes**.
    * **Multi-Factor Authentication** — enabled by default. We recommend leaving it on.
  </Step>

  <Step title="Generate the install script">
    Click **Generate Script**. The server appears in the list immediately, and a "Copy Installation Script:" panel opens with two buttons.
  </Step>

  <Step title="Copy and run the script on your server">
    Click **Script for Linux** or **Script for Windows** — the install command copies to your clipboard. SSH (or use RDP/PowerShell on Windows) into the server and execute the command.
  </Step>

  <Step title="Confirm registration">
    Once the script finishes, the server is registered. You can re-copy either script anytime from the **Linux** / **Windows** buttons in the Install Command column on the list.
  </Step>
</Steps>

#### Supported platforms

* **Linux:** Ubuntu 18.04, 20.04, 22.04, 24.04; Debian 10 (Buster), 11 (Bullseye), 12 (Bookworm).
* **Windows:** Windows Server 2019, 2022; Windows Enterprise Multi-Session 10, 11.

For any platform outside this list, talk to your Osto contact before deploying.

### Editing a Secure Server

1. Click the **edit (pencil)** icon on the server's row.
2. Update its name, session window, or MFA setting.
3. Save.

### Deleting a Secure Server

1. Click the **delete (trash)** icon on the server's row.
2. Confirm in the prompt.

<Warning>
  Deleting a Secure Server is irreversible. It removes the registration, revokes all access policies that reference it, and invalidates any active sessions. The agent on the server becomes orphaned — re-onboard with a fresh script if you intend to re-register it.
</Warning>

***

## Secure Gateway with Child Servers

> **Path:** Assets → Server Access → Secure Gateway

A Secure Gateway lets one Linux host inside your network broker access to many child servers. Child servers don't need the Osto agent installed — they're identified by private IP, and the gateway routes traffic to them.

### Adding a Secure Gateway

<Steps>
  <Step title="Navigate to Secure Gateway">
    Go to **Assets → Server Access → Secure Gateway** and click **Add Secure Gateway +**.
  </Step>

  <Step title="Name the gateway">
    Enter a **Name** for the gateway and click **Create Secure Gateway**. The gateway row appears with a "Copy Installation Script:" panel.
  </Step>

  <Step title="Install the gateway agent">
    Click **Script for Linux** — the install command copies to your clipboard. SSH into the gateway host and run the command.
  </Step>
</Steps>

<Note>
  Secure Gateway is **Linux-only** — Ubuntu, Debian, and similar distributions. Windows hosts can be Secure Servers (standalone) but not Gateways.
</Note>

### Adding child servers to a Gateway

Once the gateway is configured:

1. In the Secure Gateway list, click the **+ Add** button on the gateway's row.
2. The "Edit Secure Gateway" dialog opens with:
   * **Child Name** — a unique name for the child server.
   * **Private IP** — the internal IP address of the child host.
   * **Multi-Factor Authentication** — enabled by default.
   * **Session Window** — default 60 minutes.
3. Click **Add Child Server**.
4. Repeat for each child server you want behind this gateway.
5. Click **Save**.

Child servers don't require any agent installation. The gateway handles all brokering.

### Deleting a Gateway

Click the **delete (trash)** icon on the gateway's row and confirm.

<Warning>
  Deleting a Gateway removes the gateway *and* every child server it brokered, and invalidates all associated policies. The agent on the gateway becomes orphaned. The gateway's name cannot be edited after creation — to rename a gateway, you'd need to delete and recreate it (and re-add all child servers).
</Warning>

***

## Related

* [Secure Server Access Policy](/how-to-guides/policy-configuration/secure-server-access-policy) — define who can access which server, when, and for how long.
* [Core Concepts → Server Access](/getting-started/core-concepts) — the model behind Secure Server vs. Secure Gateway.


# Managing SSL Certificates
Source: https://docs.osto.one/how-to-guides/asset-management/managing-ssl-certificates

Upload and manage the certificates Osto uses to encrypt traffic between your origin and the internet.

Osto encrypts both legs of every request — between the user and Osto, and between Osto and your origin. There are two ways to control which certificate Osto presents:

1. **Auto-generate** — Osto provisions and renews a free SSL certificate for you (ACME-based, requires a one-time CNAME at your DNS provider).
2. **Bring your own** — you upload your own certificate bundle and Osto uses it.

This page describes managing the certificate pool you can pick from when you choose option 2. The auto-generate flow happens entirely inside the *Add Website* wizard — see [Managing Websites & Subdomains](/how-to-guides/asset-management/managing-websites).

> **Path:** Assets → Domains → Manage Certificate

## The certificate list

| Column         | What it shows                                                                  |
| -------------- | ------------------------------------------------------------------------------ |
| **Name**       | The name of the certificate (derived from the bundle or the domain it serves). |
| **Valid To**   | The certificate's expiry date.                                                 |
| **Status**     | Current state — e.g. *active*, *expired*.                                      |
| **Managed By** | Whether Osto auto-generated and manages this certificate, or you uploaded it.  |
| **Actions**    | **Delete** only — see *Editing* below.                                         |

## Adding an SSL Certificate

Certificates land in your pool from two places:

1. **Directly here**, via *Add Certificate +* on this page.
2. **Inside the Add Website wizard**, when you uncheck *Auto-generate certificate* and upload a ZIP — that upload is added to the pool for future reuse.

To add one from this page:

<Steps>
  <Step title="Navigate to Manage Certificate">
    Go to **Assets → Domains → Manage Certificate**.
  </Step>

  <Step title="Open the upload dialog">
    Click **Add Certificate +**.
  </Step>

  <Step title="Upload your certificate archive">
    In the *Upload Certificate Archive* dialog, drag-and-drop or click to upload a `.zip` file containing your certificate bundle.

    The ZIP must contain valid certificate files (`.crt` or `.pem`) and private key files (`.key` or `.pem`).
  </Step>

  <Step title="Confirm the certificate appears">
    The certificate appears in the list with its Name, Valid To, Status, and Managed By columns populated from the bundle contents.
  </Step>
</Steps>

<Note>
  The upload accepts only a single `.zip` file. If you have separate cert and key files, package them together into a ZIP before uploading.
</Note>

## Editing a certificate

There is no edit action on this page. To replace or update a certificate (for instance after renewal), **delete the existing one and upload the new one**. Domains that referenced the old certificate will pick up the new one automatically, as long as the new cert covers the same domain.

## Deleting a certificate

1. Click the **Delete** button on the certificate's row.
2. Confirm.

<Warning>
  A certificate can't be deleted while it's actively serving traffic for a registered domain. Switch the domain to *Auto-generate*, or upload a replacement first, before deleting an in-use cert.
</Warning>

## Tips

* **Wildcard certificates simplify operations.** One `*.example.com` upload covers every subdomain you register. Use them unless you have a compliance reason to issue per-host.
* **Don't have a certificate?** Use the *Auto-generate certificate* option in *Add Website* — Osto handles provisioning and renewal for you.
* **Track your own renewal cycle for uploaded certs.** Osto surfaces expiry in the **Valid To** and **Status** columns and in alerts, but renewal happens at your CA.

## Related

* [Managing Websites & Subdomains](/how-to-guides/asset-management/managing-websites) — the Add Website wizard step that uses these certs (and where the auto-generate flow lives).
* [What is Web Application Protection](/overview/what-is-web-app-protection) — how Osto's dual-layer TLS works in practice.


# Managing Users & Groups
Source: https://docs.osto.one/how-to-guides/asset-management/managing-users-groups

Onboard your team into Osto and organize them into Usergroups for role-based policy targeting.

A default group called **Common** ships with every account; new users land in Common unless you create them in another group.

> **Path:** Assets → Endpoint Users

## Creating a Usergroup

1. Go to **Assets → Endpoint Users**.
2. Click **Create Usergroup +**.
3. Fill in:
   * **Name** (required) — e.g. *Developers*, *Marketing*, *Contractors*.
   * **Description** (optional) — helpful for future you when the group list grows.
4. Click **Save**. The group appears in the list with a count of 0 users.

## Editing or deleting a Usergroup

* **Edit:** open the group from the list, update the name or description, and save.
* **Delete:** click the group's **delete** icon. A group can only be deleted when it contains zero users — move users out first.

<Note>
  The default **Common** group can't be deleted.
</Note>

## Adding users

You can add users manually or in bulk via CSV.

### Add Manually

1. Go to **Assets → Endpoint Users** and locate the target Usergroup.
2. Click **+ Add Users** on that group's row.
3. In the dialog, the **+ Add Manually** tab is selected by default. Fill in:
   * **Name** (required)
   * **Email** (required)
   * **Date of Birth** (optional, DD-MM-YYYY)
   * **Phone Number** (optional, with country-code dropdown — defaults to your account's region)
4. Click **Save**. The user receives an email with a link to download the Osto agent.

### Import via CSV

1. In the **Add User** dialog, switch to the **Import** tab.
2. Click **Download Sample CSV** to grab the template with the right column headers.
3. Fill it with your user list and save.
4. Click **Upload CSV** and select your file.
5. Save. Each user receives the same agent-install email.

## Editing or removing a user

* **Edit:** click the **edit (pencil)** icon on the user's row. You can update **Name, Email, Date of Birth, and Phone Number**.
* **Remove:** click the user's **delete (trash)** icon. The user is unenrolled and their agent stops reporting in. Policies that targeted them via group continue to apply to others.

<Note>
  The Edit User dialog doesn't include a group selector. Moving an existing user between groups isn't supported from the edit view today — if you need to reorganize users across groups, talk to your Osto contact.
</Note>

## Agent install status

The **App Installed** column shows the agent's status per user:

* **Red dot** — agent not yet installed (the user hasn't followed the email link yet).
* **Green dot** — agent installed and reporting in.

When no user has installed the agent, you'll see a warning banner at the top: *"No users have installed the agent application. See details."*

## Related

* [User Protection Policy](/how-to-guides/policy-configuration/user-protection-policy) — the policies that apply to users in each group (Device Control, App Control, Domain Filtering, DLP).
* [Core Concepts](/getting-started/core-concepts) — how Endpoint Users fit into the broader asset model.


# Managing Websites & Subdomains
Source: https://docs.osto.one/how-to-guides/asset-management/managing-websites

Add the websites and subdomains you want Osto to protect.

Once added and DNS-pointed, every request to them flows through Osto for inspection before reaching your origin.

> **Path:** Assets → Domains → Manage Domains

## The domain list

The Manage Domains page shows every domain you've registered with these columns:

| Column            | What it shows                                                                                                     |
| ----------------- | ----------------------------------------------------------------------------------------------------------------- |
| **FQDN**          | The full domain name (e.g. `api.example.com`).                                                                    |
| **Updated At**    | Timestamp of the last configuration change.                                                                       |
| **Website Name**  | Friendly name for the website (auto-derived from the FQDN by default).                                            |
| **Status**        | Current state — *draft*, *active*, etc. New domains start as *draft* until DNS is pointed and traffic is flowing. |
| **Firewall Mode** | Per-domain toggle: **Detect Mode** (observe and log only) or **Prevent Mode** (actively block).                   |
| **Actions**       | Edit (pencil) and **Delete Website** affordances.                                                                 |

The top-right **WAF Details** button surfaces protection summaries.

## Firewall Mode — Detect vs. Prevent

Each registered domain has a Firewall Mode toggle directly in the table. This controls how Osto handles malicious requests it identifies:

* **Detect Mode** — Osto inspects every request and logs anything suspicious, but **does not block**. Use this when onboarding a new domain so you can review what Osto would have blocked before going live.
* **Prevent Mode** — Osto inspects every request and **actively blocks** anything malicious. This is the production setting.

<Tip>
  **Recommended onboarding pattern:** start in **Detect Mode** for the first few days, watch Logs → Web App for false positives, then flip to **Prevent Mode** once you're confident the policies are correctly tuned.
</Tip>

## Adding a Website or Subdomain

The same flow handles root domains and subdomains alike. It's a two-step wizard.

### Step 1 — Domain, origin, TLS & CDN

<Steps>
  <Step title="Open the Add Website dialog">
    Go to **Assets → Domains → Manage Domains** and click **Add Website +**.
  </Step>

  <Step title="Enter and verify your domain">
    In the **Domain Name** field, enter the domain (e.g. `example.com` or `app.example.com`) and click **Verify**. On success you'll see *"Domain verified successfully"* with a green check.
  </Step>

  <Step title="Configure origin servers">
    The form expands with two **Server IP or LB Domain** fields. Suggested origin IPs appear as chips below each — click a chip to fill, or type your own. Use both fields for high availability; use only the first for a single-origin setup. For multiple IPs in one field, separate them with commas.
  </Step>

  <Step title="Set TLS version">
    Multi-select dropdown. Defaults to **TLS 1.2 + TLS 1.3** (shown as *"2 selected"*). TLS 1.1 is available but off by default.
  </Step>

  <Step title="Select CDN usage">
    Choose your CDN if your site sits behind one — Osto adjusts request-header handling so client IPs and other forwarded metadata are interpreted correctly. Options: Not Using CDN, AWS CloudFront, Google Cloud CDN, Azure CDN, Others.
  </Step>

  <Step title="Proceed to certificate setup">
    Click **Next** to move to certificate setup.
  </Step>
</Steps>

### Step 2 — Certificate Configuration

This is where Osto figures out which TLS certificate to present to clients hitting your domain. You have two paths:

#### Option A — Auto-generate (default, recommended)

Leave **Auto-generate certificate** checked. Osto provisions a free SSL certificate on your behalf using industry-standard ACME validation. To prove you own the domain, you add one CNAME record at your DNS provider:

| Field     | Value                                                                    |
| --------- | ------------------------------------------------------------------------ |
| **Type**  | CNAME                                                                    |
| **Name**  | `_acme-challenge.<your-domain>` (shown in the dialog with a copy button) |
| **Value** | the target shown in the dialog — use the copy button                     |
| **TTL**   | 60                                                                       |

After adding the record, wait a few minutes for DNS to propagate, then click **Verify CNAME Record**. Once verified, Osto issues the certificate and the domain moves out of *draft*.

#### Option B — Bring your own certificate

Uncheck **Auto-generate certificate**. Two sub-options appear:

* **Select Certificate** — dropdown listing every certificate you've already uploaded under [Manage Certificate](/how-to-guides/asset-management/managing-ssl-certificates). Pick the one whose Common Name covers your domain.
* **Certificate Archive (ZIP)** — drag-and-drop a `.zip` file containing the certificate and private key, or click to browse.

<Note>
  The ZIP must contain valid certificate files (`.crt`, `.pem`) and private key files (`.key`, `.pem`).
</Note>

Click **Next** to finish. The uploaded certificate also appears in Manage Certificate for future reuse.

### Step 3 — Point your DNS

Once the dialog closes, the domain appears in the list with status **draft**. The final step is at your DNS provider:

* Update the domain's **A record** to the Osto IP shown after Save.
* Set TTL to **600 seconds** for fast propagation.

Status flips from *draft* to *active* once Osto observes traffic flowing through.

## Editing a Website or Subdomain

Click the **edit (pencil)** icon on the row. The dialog opens directly to the Step 1 form with your existing values pre-loaded — you can update origin IPs, TLS versions, or CDN usage and click **Save**.

To change a domain's **Firewall Mode**, click the *Detect Mode* or *Prevent Mode* button directly in the row — no need to open the edit dialog.

## Deleting a Website or Subdomain

Click **Delete Website** on the row and confirm.

<Warning>
  A parent domain can't be deleted while it still has registered subdomains — delete the subdomains first. After deletion, traffic to that domain bypasses Osto until you also revert the DNS A record at your provider.
</Warning>

## What happens after a domain is active

1. Every request hits Osto first.
2. Attack Detection runs (TLS, protocol, headers).
3. Advanced checks (OWASP, DDoS, bot mitigation) inspect the request body and behavior. Whether they block or merely log depends on Firewall Mode.
4. Clean requests forward to your origin; malicious ones are blocked (in Prevent Mode) or recorded (in Detect Mode).
5. Findings stream into **Logs → Web App Logs** and into the **Compliance Engine** as evidence.

## Related

* [What is Web Application Protection](/overview/what-is-web-app-protection) — the detailed protection model.
* [Website Protection Policy](/how-to-guides/policy-configuration/website-protection-policy) — tune the protection behavior per domain.
* [Managing SSL Certificates](/how-to-guides/asset-management/managing-ssl-certificates) — upload, view, and remove certificates.


# SAST
Source: https://docs.osto.one/how-to-guides/code-security/sast

Connect your Git provider to run static analysis, dependency scanning, and secret detection across your source code.

**SAST** (under **Code Security**) secures your codebase *before it ships*. Connect a Git provider and Osto runs static analysis, software composition analysis (dependency scanning), and secret detection across your repositories — all in one place.

> **Path:** Code Security → SAST

<Frame>
  <img alt="SAST onboarding page titled 'Secure your codebase before it ships' with a Connect a provider button and a three-step how-it-works guide" />
</Frame>

## How it works

Getting started takes three steps:

| Step                      | What happens                                                                                 |
| ------------------------- | -------------------------------------------------------------------------------------------- |
| **1. Connect a provider** | Link GitHub, GitLab, or Bitbucket so Osto can reach your repositories securely.              |
| **2. Sync repositories**  | Osto pulls your repository list and branches so you can choose what to scan.                 |
| **3. Run scans**          | Kick off static analysis, dependency, and secret checks from the Repositories or Scans tabs. |

## Connect a provider

Click **Connect a provider** to open the connection dialog, then choose your Git host:

<CardGroup>
  <Card title="GitHub" icon="github">
    Connect with a GitHub App or a personal access token.
  </Card>

  <Card title="GitLab" icon="gitlab">
    Connect gitlab.com or a self-hosted instance via OAuth or a token.
  </Card>

  <Card title="Bitbucket" icon="bitbucket">
    Connect with OAuth or an app password.
  </Card>
</CardGroup>

<Frame>
  <img alt="Connect provider dialog showing GitHub, GitLab, and Bitbucket as Git host options" />
</Frame>

### Choose how to connect

After picking a host, choose a connection method:

<Frame>
  <img alt="Connection method step offering Sign in with the provider or Personal Access Token" />
</Frame>

* **Sign in with the provider** — opens a secure browser window to authorize Osto. Recommended for most teams; there's no token to copy.
* **Personal Access Token** — paste a token or app password. Useful for automation, air-gapped environments, or restricted organizations. You'll give the connection a name and paste the token, then select **Add connection**.

<Note>
  Connecting **GitLab** adds one extra choice: **gitlab.com (cloud)** or a **self-hosted GitLab** instance (your own CE/EE URL). Self-hosted instances connect with a personal access token.
</Note>

## After connecting

Once a provider is linked, SAST opens up into five tabs across the top of the page, and a top-right **Report** button is available throughout. Until a provider is connected, SAST shows the onboarding screen above.

### Integrations

Your home base once connected. The top cards summarize your **Connections**, **Repositories**, **Findings**, and **Scans**, followed by a severity breakdown of all findings (Critical / High / Medium / Low) and how many are **fixable**.

<Frame>
  <img alt="SAST Integrations tab with Connections, Repositories, Findings, and Scans counts, a findings severity breakdown, and a connected GitHub provider" />
</Frame>

Below that, the **Connections** list shows each linked provider with its status, repository count, and last sync time. Use **Sync** to refresh a single connection (or **Sync All**) and **Test** to verify the connection still works.

### Repositories

Every repository Osto can see, with at-a-glance counts: total repositories, how many are inaccessible, the percentage scanned, how many auto-scan on push, how many have critical findings, and how many are clean. A **Top Languages** panel and a **Most Vulnerable** panel (ranked by Osto Risk Score) sit above the table.

<Frame>
  <img alt="SAST Repositories tab showing coverage cards, top languages, most vulnerable repo, and a repository table" />
</Frame>

Each row lists the repository (with an **Auto-scan on push** indicator when enabled), provider, branches, languages, and size. Use the per-row **Scan** button to run a scan on demand, or **View details** to drill in.

### Scans

A record of every scan run. The summary cards cover total scans, scans in the last 7 days, anything running or queued, your success rate, average duration, and any runs with errors. The **Scan Runs** table lists each run with its repository, status, progress, total findings, and critical count.

<Frame>
  <img alt="SAST Scans tab showing total scans, success rate, average duration, and a Scan Runs table" />
</Frame>

### Issues

The heart of SAST — every finding across your code. Summary cards show the **Total**, **Critical**, **High**, **KEV** (known-exploited), **Fixable**, and **Open** counts, alongside **Top Rules** (most-triggered rules) and **Top Files** (the hottest spots in your code).

<Frame>
  <img alt="SAST Issues tab with finding counts, top rules, top files, and a findings table" />
</Frame>

The findings table can be grouped (flat list, or by file, component, severity, type, or rule) and exported. Each finding shows its repository, risk score, severity, **type** — **VULN** (vulnerable dependency), **SECRET** (exposed credential), or **SAST** (code-analysis issue) — status, and the rule and message.

Select **View details** on any finding to open the **Finding Detail** panel:

<Frame>
  <img alt="Finding Detail panel showing Osto Risk Score breakdown, CVE description, affected file and component, fix version, CWE, and triage controls" />
</Frame>

It explains the **Osto Risk Score** — how CVSS severity, exploit likelihood, and known-exploited (KEV) status combine — describes the finding (with its CVE where relevant), and pinpoints the affected **file**, **component**, recommended **fix version**, and **CWE**. From the **Triage** section you can **mark a finding as triaged** to mute it (and its matches across branches and repos) when it's a false positive, accepted risk, or a test-only path.

### Reports

Export your current results on demand. The **Download now** section offers two exports:

| Export               | What you get                                                                               |
| -------------------- | ------------------------------------------------------------------------------------------ |
| **Executive report** | An org-wide HTML overview — severity distribution, top vulnerable repos, and recent scans. |
| **Findings CSV**     | The full findings list as a compliance-friendly CSV (up to 10,000 rows).                   |

<Frame>
  <img alt="SAST Reports tab with Download now exports (Executive report, Findings CSV) and a Schedules section" />
</Frame>

<Note>
  Downloading a report under **Download now** exports the current state — it doesn't trigger a new scan.
</Note>

## Schedules

Below the on-demand exports, the **Schedules** area lets you automate recurring scans and have a fresh report emailed to your team when each run completes. With no schedules set up it shows *"No schedules yet."* Click **New schedule** to open the schedule builder.

<Frame>
  <img alt="New schedule dialog with Name, Frequency, Scope, Email a fresh report toggle, Recipients, Format, and content options" />
</Frame>

The dialog has these options:

| Field                                     | Options / notes                                                                                                          |
| ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| **Name** *(required)*                     | A label for the schedule (e.g. "Weekly Security Review").                                                                |
| **Frequency**                             | **Daily** (02:00 IST), **Weekly** (Mon 02:00 IST), or **Monthly** (1st, 02:00 IST).                                      |
| **Scope**                                 | **All repositories** (everything across all connected providers), a **single connection**, or **multiple repositories**. |
| **Email a fresh report**                  | A toggle (on by default). When enabled, each completed run emails a freshly built report to the recipients below.        |
| **Recipients** *(required when emailing)* | Add one or more recipients — press Enter, comma, or space to add each.                                                   |
| **Format**                                | **HTML**, **PDF**, or **CSV**.                                                                                           |
| **Report contents**                       | Choose what the email includes: **Executive summary PDF**, **Per-scan detail**, and/or **Findings CSV**.                 |

Fill in the fields and select **Create schedule**. Each run then scans the chosen scope on the set cadence and — if email is enabled — delivers the report automatically.


# AutoComply
Source: https://docs.osto.one/how-to-guides/compliance/autocomply

Get your workspace audit-ready — activate a compliance framework, generate policies, track controls and tasks, and run security awareness training.

**AutoComply** (under **Compliance**) automates the busywork of getting audit-ready. Activate a framework like SOC 2, and Osto maps out the requirements, controls, policies, and tasks you need — then helps you generate policies, assign training, and track everything to completion in one place.

> **Path:** Compliance → AutoComply

## First-run setup

The first time you open AutoComply, a **Guided Setup** assistant walks you through enabling compliance for your workspace. It captures a few essentials used throughout your policies and attestations:

<Frame>
  <img alt="Compliance guided setup assistant asking for the organization's legal name" />
</Frame>

1. **Enable compliance** for your workspace.
2. **Organization legal name** — exactly as it should appear on contracts and audit documents.
3. **Default policy author** — chosen from your workspace admins; listed as the author on generated policies.
4. **Policy logo** — branding for generated documents.
5. **Activate your first framework**.

<Note>
  Everything you enter during setup can be edited later under **Compliance → Settings**.
</Note>

Once setup completes, Compliance expands into the full AutoComply console, with sections for Frameworks, Policies, Tasks, Awareness Training, and Settings. A role switcher in the top-right toggles between the **Admin** console and the **Employee** self-service view.

## Frameworks

The **Frameworks** page lists the compliance standards you can work toward. **SOC 2 Type II** is available to activate today; others — CCPA, FedRAMP, GDPR, HIPAA, ISO 27001:2022, ISO 42001:2023, and PCI-DSS v4.0 — are on the roadmap and marked *Coming soon*.

<Frame>
  <img alt="Frameworks page showing SOC 2 Type II active and other standards marked coming soon" />
</Frame>

Select **View compliance status** on an active framework to open its requirements:

<Frame>
  <img alt="SOC 2 requirements page with an overview of requirements and controls and a list of controls by criterion" />
</Frame>

The detail view summarizes the framework's **requirements** and **controls** with how many are completed, partial, or pending, and lets you filter by status or search. Each requirement (mapped to its criterion) lists the controls that satisfy it, and you can **add a control** where needed.

## Policies

The **Policies** page is your library of company policies, pre-mapped to your active framework. Each policy moves through a workflow — **Not started → Draft → Needs approval → Approved** — and the summary counts show where everything stands.

<Frame>
  <img alt="Company Policies page listing policies with status, framework, and Setup now actions" />
</Frame>

Use **Generate Policies** to draft them from Osto's templates (populated with your organization details), filter by framework, and **Setup now** on any row to work through a single policy. The table shows each policy's **status** and **framework**.

## Tasks

The **Tasks** page is your compliance pipeline — the concrete to-dos that move you toward audit-readiness.

<Frame>
  <img alt="Compliance Tasks page with status and type breakdowns and a filterable task list" />
</Frame>

Tasks are summarized **by status** (Open, In progress, Done, Failing) and **by type** (Automated vs. Manual). **Automated** tasks are checked by Osto from the platform itself (for example, WAF/WAAP protection, DLP policies, endpoint screen lock, TLS certificates); **manual** tasks are evidence you record yourself (risk assessments, HR documentation, audits). Filter by status, category, or type, and **Sync** to refresh automated checks.

## Awareness Training

AutoComply includes a full **security awareness training** module so you can satisfy the "train your people" controls every framework requires — build programs from a starter pack, assign them to employees, and track completion. It's a feature in its own right:

<Card title="Awareness Training" icon="graduation-cap" href="/how-to-guides/compliance/awareness-training">
  Build training programs and modules, assign them to employees, and track completion — plus the employee self-service experience for completing training and acknowledging policies.
</Card>

## Settings

**Settings** holds the organization details captured during setup — used to populate policy templates and attestations — plus your policy logo.

<Frame>
  <img alt="Compliance Settings page with organization details and a policy logo upload" />
</Frame>

Under **Organisation Details** you can edit your legal name, company domain, industry, country, website, default policy author and approver, and default review frequency. Under **Policy Logo**, upload the logo that appears on generated documents. These values flow into every policy and report AutoComply produces.


# Awareness Training
Source: https://docs.osto.one/how-to-guides/compliance/awareness-training

Build security awareness training programs, assign them to employees, and track completion — plus the employee experience for completing training and acknowledging policies.

**Awareness Training** (under **Compliance**) is AutoComply's built-in security awareness program. Admins build training programs from a ready-made starter pack, assign them to employees, and track completion; employees complete their assigned modules and acknowledge company policies from a self-service portal. Together this satisfies the security-training and policy-acknowledgment controls that frameworks like SOC 2 require.

> **Path:** Compliance → Awareness Training

Awareness Training has two sides: the **admin** experience (build and assign) and the **employee** experience (learn and acknowledge). Use the **role switcher** in the top-right to move between them.

## Admin experience

As an admin, you build training programs, assign them to employees, and track completion across the **Training Dashboard**, **Programs**, **Modules**, and **Employees** pages.

### Training Dashboard

The **Training Dashboard** is your command center. Once programs are assigned, it shows coverage and progress at a glance:

<Frame>
  <img alt="Compliance Training Dashboard with KPI cards for training programs, employees in scope, assignments, and completion rate" />
</Frame>

| Metric                 | What it shows                                            |
| ---------------------- | -------------------------------------------------------- |
| **Training Programs**  | Published programs in your catalog.                      |
| **Employees in Scope** | How many employees are assigned vs. unassigned.          |
| **Assignments**        | Total assignments, split into pending and in-progress.   |
| **Completion Rate**    | Percentage completed, with completed and overdue counts. |

Below the KPIs, an **Assignment Status Mix** bar (Completed / In Progress / Pending) and **Quick Insights** summarize coverage, average load per employee, and whether everything is on track.

### Programs

The **Programs** page is your training catalog. Create a program from scratch or **Add starter content** — a ready-made *Security Awareness Training* program covering core cybersecurity topics. Each program can be edited, duplicated, or deleted.

Open **View Details** on a program to manage its settings and assignments:

<Frame>
  <img alt="Security Awareness Training program detail with program name, description, and quiz configuration" />
</Frame>

* **Program details** — name and description.
* **Quiz configuration** — set the **passing score**, **questions per quiz**, **max attempts**, and whether learners must finish the content before the quiz.
* **Assign to Employees** / **Send Reminder** — roll the program out and nudge people who haven't finished.

### Modules

**View Modules** opens the program's lessons. The starter pack ships with eight modules — **Passwords, Data Handling, Computer Theft, Phishing & Ransomware, Removable Media, Vishing, Internet Downloads,** and **Public Wi-Fi** — and you can **Add Module** or **Manage Module** to edit each one's content items and quiz questions.

<Frame>
  <img alt="Training Modules page listing eight security awareness modules" />
</Frame>

### Employees

The **Employees** page is where you manage who is being trained. It gives you a single, roster-wide view of every employee's training status and progress, surfaces anyone who hasn't been assigned a program yet, and is the place you roll programs out and chase down completions. Use it to keep coverage at 100% and to evidence — for an audit — that your people have been trained.

<Frame>
  <img alt="Awareness Training Employees page showing training status filters and employees without training" />
</Frame>

Available actions on this page:

| Action                         | What it does                                                                                                                                                         |
| ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Status filter**              | Narrow the roster to a single training status — **All Statuses**, **Pending**, **In Progress**, **Completed**, or **Cancelled** — to find who still needs attention. |
| **Program for actions**        | Select which training program the assign and reminder actions below apply to.                                                                                        |
| **Assign Training**            | Assign the selected program to employees, putting their assignment into a *Pending* state.                                                                           |
| **Send Reminder**              | Email a nudge to employees whose assigned training is still incomplete.                                                                                              |
| **Employees without Training** | A grouped list of anyone with no assignments yet (shown with a *No assignments* badge) so gaps in coverage are easy to spot and fix.                                 |

## Employee experience

Switching the top-right role selector to **Employee** opens the **Compliance Center** — a self-service portal where employees see exactly what needs their attention: assigned training and policy acknowledgments.

<Frame>
  <img alt="Employee Compliance Center with Policy documents and Awareness training cards" />
</Frame>

### Completing training

From **Awareness Training**, an employee sees each assigned program with its **progress** and **due date**, and clicks **Continue** to keep going. A program is made up of modules that **unlock in order** — you finish one before the next opens.

Inside a module, content is delivered step by step (you can't skip ahead). Steps include **reading lessons** (with key takeaways) and short **video lessons**, each with an estimated time:

<Frame>
  <img alt="Employee training module step showing a reading lesson with key takeaways and a progress bar" />
</Frame>

Work through the steps with **Next**, then **Complete module** on the last one. The module is marked 100%, your overall progress updates, and the next module unlocks. Programs can also require a **quiz** — with a passing score and limited attempts, as configured by your admin.

### Acknowledging policies

The **Policies** tab is where employees **read and acknowledge** the company policies their organization has published. Until policies are approved and published (from the admin **Policies** workflow), this page shows an empty state:

<Frame>
  <img alt="Employee Policies page empty state explaining published policies will appear for acknowledgment" />
</Frame>

<Note>
  Policies only appear for employees to acknowledge once an admin has taken them through **Compliance → Policies** (set up → draft → approve → publish).
</Note>


# Audit Logs
Source: https://docs.osto.one/how-to-guides/logs/audit-logs

An accountability trail of configuration and admin actions taken in your workspace.

**Audit Logs** is your accountability trail — a record of configuration and admin actions taken in your workspace. It's the log you'll reference for compliance and change tracking.

> **Path:** Logs → Audit Logs

<Frame>
  <img alt="Audit Logs listing performed-at time, performed-by user, audit type, feature, status, and a View Details link" />
</Frame>

The table includes these columns:

| Column           | Description                                               |
| ---------------- | --------------------------------------------------------- |
| **Performed At** | When the action took place.                               |
| **Performed By** | The user who performed it.                                |
| **Audit Type**   | The kind of action (for example, creating a record).      |
| **Feature**      | The area affected — such as a user, user group, or scan.  |
| **Status**       | The outcome (for example, success).                       |
| **Details**      | A **View Details** link to the full record of the change. |


# Auth Logs
Source: https://docs.osto.one/how-to-guides/logs/auth-logs

A record of authentication and session events, including role switches.

**Auth Logs** records authentication and session activity — who signed in, from where, on what device, and any switches between the admin and employee views.

> **Path:** Logs → Auth Logs

<Frame>
  <img alt="Auth Logs listing timestamp, login ID, login and logout time, status, reason, user agent, source IP, and user OS" />
</Frame>

The table includes these columns:

| Column                           | Description                                                                                               |
| -------------------------------- | --------------------------------------------------------------------------------------------------------- |
| **Timestamp**                    | When the event occurred.                                                                                  |
| **Login ID**                     | The account involved.                                                                                     |
| **Login Time** / **Logout Time** | When the session started and ended.                                                                       |
| **Status**                       | Whether the session is active or inactive.                                                                |
| **Reason**                       | The event reason — such as a successful authentication, or a switch between the admin and employee views. |
| **User Agent**                   | The browser used.                                                                                         |
| **Source IP**                    | Where the sign-in originated.                                                                             |
| **User OS**                      | The operating system of the device.                                                                       |


# Domain Filtering Logs
Source: https://docs.osto.one/how-to-guides/logs/domain-filtering-logs

Endpoint domain requests and the filtering decision applied to each.

**Domain Filtering Logs** records the domains your endpoints request and how each request was handled under your domain-filtering policies.

> **Path:** Logs → Domain Filtering Logs

<Frame>
  <img alt="Domain Filtering Logs table with Timestamp, User, Domain, Source IP, Category Name, and Action columns" />
</Frame>

The table includes these columns:

| Column            | Description                                                       |
| ----------------- | ----------------------------------------------------------------- |
| **Timestamp**     | When the request was made.                                        |
| **User**          | The endpoint user who made the request.                           |
| **Domain**        | The domain that was requested.                                    |
| **Source IP**     | Where the request originated.                                     |
| **Category Name** | The domain category the request fell under.                       |
| **Action**        | The filtering decision applied (for example, allowed or blocked). |

Entries appear once endpoints with domain-filtering policies are active; until then the table shows *"No Rows To Show."*


# Incident Logs
Source: https://docs.osto.one/how-to-guides/logs/incident-logs

A consolidated view of security incidents across the platform.

**Incident Logs** brings security incidents into one consolidated view, so you can triage what happened, where, and under which policy.

> **Path:** Logs → Incident Logs

<Frame>
  <img alt="Incident Logs table with Incident Time, Log Type, Source User, Source Endpoint, Policy, Destination, and Severity columns" />
</Frame>

The table includes these columns:

| Column              | Description                           |
| ------------------- | ------------------------------------- |
| **Incident Time**   | When the incident occurred.           |
| **Log Type**        | The kind of incident.                 |
| **Source User**     | The user involved, where applicable.  |
| **Source Endpoint** | The endpoint involved.                |
| **Policy**          | The policy that flagged the incident. |
| **Destination**     | The target of the activity.           |
| **Severity**        | How serious the incident is.          |

Entries appear as incidents are raised across the platform; until then the table shows *"No Rows To Show."*


# Logs
Source: https://docs.osto.one/how-to-guides/logs/index

Searchable, filterable records of web traffic and threats, secure-server sessions, domain filtering, incidents, admin actions, and authentication events.

**Logs** give you a searchable, filterable history of everything happening across your Osto-protected estate — web traffic and blocked attacks, secure-server sessions, endpoint domain filtering, incidents, admin actions, and sign-ins. Every log table has per-column filters and pagination so you can drill into exactly what you need.

> **Path:** Logs

Logs are split into six views:

<CardGroup>
  <Card title="Web App Logs" icon="globe" href="/how-to-guides/logs/web-app-logs">
    Web traffic, detected threats, and policy violations for your protected sites.
  </Card>

  <Card title="Secure Server Logs" icon="server" href="/how-to-guides/logs/secure-server-logs">
    Sessions opened to your secure servers.
  </Card>

  <Card title="Domain Filtering Logs" icon="filter" href="/how-to-guides/logs/domain-filtering-logs">
    Endpoint domain requests and the filtering decision applied.
  </Card>

  <Card title="Incident Logs" icon="triangle-exclamation" href="/how-to-guides/logs/incident-logs">
    Consolidated security incidents across the platform.
  </Card>

  <Card title="Audit Logs" icon="clipboard-list" href="/how-to-guides/logs/audit-logs">
    Configuration and admin actions taken in your workspace.
  </Card>

  <Card title="Auth Logs" icon="right-to-bracket" href="/how-to-guides/logs/auth-logs">
    Authentication and session events, including role switches.
  </Card>
</CardGroup>

<Note>
  Every log view supports column filters and pagination. Tables stay empty until there's activity to report — for example, Secure Server and Domain Filtering logs populate once those features see live traffic.
</Note>


# Secure Server Logs
Source: https://docs.osto.one/how-to-guides/logs/secure-server-logs

A record of sessions opened to your secure servers.

**Secure Server Logs** records the sessions users open to your secure servers through Secure Server Access.

> **Path:** Logs → Secure Server Logs

<Frame>
  <img alt="Secure Server Logs table with Timestamp, User, Secure Server, Source IP, Source Port, Service, and Duration columns" />
</Frame>

The table includes these columns:

| Column            | Description                      |
| ----------------- | -------------------------------- |
| **Timestamp**     | When the session occurred.       |
| **User**          | The user who connected.          |
| **Secure Server** | The server they connected to.    |
| **Source IP**     | Where the connection originated. |
| **Source Port**   | The source port used.            |
| **Service**       | The service accessed.            |
| **Duration**      | How long the session lasted.     |

Entries appear here as users connect through Secure Server Access; until then the table shows *"No Rows To Show."* Use the column filters to find sessions by user, server, or time.


# Web App Logs
Source: https://docs.osto.one/how-to-guides/logs/web-app-logs

A live record of traffic hitting your protected websites — detected threats, the full access log, and policy violations.

**Web App Logs** is the most active log view — a live record of traffic hitting your protected websites. It's organized into three tabs.

> **Path:** Logs → Web App Logs

<Frame>
  <img alt="Web App Logs Threat Logs tab listing detected threats with timestamp, severity, incident type, source IP, host, and method" />
</Frame>

| Tab                       | Columns                                                                             | What it shows                                       |
| ------------------------- | ----------------------------------------------------------------------------------- | --------------------------------------------------- |
| **Threat Logs**           | Timestamp, Severity, Incident Type, Source IP, Host, Method, User Agent, Request ID | Every attack Osto detected and blocked.             |
| **Access Logs**           | Timestamp, Source IP, Host, Method, URI, Status Code, Protocol                      | The full request access log for your sites.         |
| **Policy Violation Logs** | Timestamp, Severity, Incident Type, Source IP, Host, Method, User Agent             | Requests that tripped one of your protection rules. |

Use the per-column filters to narrow by severity, host, source IP, or time, and the **Request ID** to correlate a threat entry with its underlying request.


# Objects Management
Source: https://docs.osto.one/how-to-guides/objects/index

Reusable building blocks — domain categories, application groups, port objects, and schedules — that you reference when defining policies.

**Objects** are the reusable building blocks you reference when writing policies. Instead of repeating the same domains, ports, or time windows in every rule, you define them once as an object and reuse them across your policies. Osto ships with a large set of predefined objects, and you can add your own.

> **Path:** Objects

Objects come in four types:

<CardGroup>
  <Card title="Domain Category" icon="globe">
    Named groups of domains used by domain-filtering policies.
  </Card>

  <Card title="Application" icon="grid-2">
    Predefined application groups used by app-control policies.
  </Card>

  <Card title="Port" icon="ethernet">
    Protocol/port definitions used by server-access policies.
  </Card>

  <Card title="Schedule" icon="clock">
    Time-based classes that control when a policy applies.
  </Card>
</CardGroup>

## Domain Category

A **domain category** is a named collection of domains. Osto includes 66 **predefined** categories (Web Hosting, Web Analytics, URL Shorteners, Violence, and many more) that domain-filtering policies use to allow or block whole classes of sites at once. You can also create your own.

<Frame>
  <img alt="Domain Category page listing predefined domain categories with Name, Type, and Actions columns" />
</Frame>

The table shows each category's **Name** and **Type** (predefined categories are read-only). Use **Search Domain Category** to find one, or **Add Domain Category** to create a custom one:

* **Name** and an optional **Description**.
* **Add Manually** — type a comma-separated list of domains; wildcards are supported (e.g. `google.com, *.facebook.com`). **Discover Related Domains** helps expand the list.
* **Import Domains** — upload a `.txt` file of domains (a sample file is available to download).

## Application

The **Application** page lists Osto's predefined application classification groups — **Instant Messaging, Web Browser, P2P, VPN,** and **All Apps**. These are the groups your **App Control** policy uses to allow or restrict categories of apps. The list is reference-only (you select these groups from within policies rather than editing them here).

<Frame>
  <img alt="Application page listing predefined application groups with Name and Description" />
</Frame>

## Port

A **port object** names a protocol and port (or set of ports) so you can reference it in **secure-server access** policies. Osto includes common services (DNS, LDAP, SMB, SYSLOG, IKE, and more).

<Frame>
  <img alt="Port page listing port objects with Name, Protocol, Type, Ports, and Actions" />
</Frame>

The table shows each object's **Name**, **Protocol**, **Type**, and **Ports**. To add one, click **Add Port Objects** and provide:

* **Name**.
* **Protocol** — **TCP** or **UDP**.
* **Type** — **Single Port**, **Port Range**, or **Port List** — then the matching port value(s).

## Schedule

A **schedule** controls *when* a policy is in effect. The built-in **Forever** schedule applies a policy at all times; you can add time-bound schedules for policies that should only apply during certain windows. Schedules appear as the **Schedule Class** option in endpoint policies.

<Frame>
  <img alt="Schedule page listing schedule objects with Name, Description, Duration, and Actions" />
</Frame>

To add one, click **Add Schedule** and set a **Name**, optional **Description**, and a **Duration**:

* **Forever** — always active.
* **On Time** — active only within a date range and during specific time windows. You set a **From Date** and **To Date**, then add one or more **day + from-time/to-time** entries (use **Add Time Entry** for multiple windows).


# How to Create a Policy Exception on the Dashboard
Source: https://docs.osto.one/how-to-guides/policy-configuration/how-to-create-a-policy-exception

Create a new policy exception in the Osto dashboard to control how traffic matching certain conditions is handled for a selected website.

This guide walks through creating a new policy exception in the Osto dashboard. A policy exception lets you define how traffic matching certain conditions should be handled (accepted, skipped, or dropped) for a selected website.

## Before you start

* Log in to the dashboard and go to Policies, then Exceptions.
* Make sure the website you want to add the exception for is already onboarded and visible in dropdown.

## Step 1: Check the logs to find what to except

Before creating an exception, go to Logs and open the relevant log tab (for example Threat Logs). Look at the Matched Data column. This tells you what was detected and why the rule triggered, which is the information you need to build a matching exception.

For example, an entry like `Matched Data: <script> found within REQUEST_FILENAME: /id=<script>` means the request was flagged because `/id=<script>` appeared in the request filename. If this is legitimate traffic, you can create an exception for it.

<Frame>
  <img alt="Threat Logs showing the Matched Data column" />
</Frame>

## Step 2: Open the exception form

Go to the Policies page, then open Exceptions and click the Create exception button. The New policy exception panel opens on the right.

<Frame>
  <img alt="New policy exception panel" />
</Frame>

## Step 3: Enter a rule name

In the Rule name field, type any name to identify this exception, for example exception1 or allow-admin-api. Use a name that makes the rule easy to recognize later.

## Step 4: Select the website

Open the Website dropdown and pick the site you want to add the exception for. Only onboarded websites appear in this list.

## Step 5: Select the action

Under When traffic matches, open the Then (action) dropdown and choose what should happen when traffic matches your condition:

* **Accept** allow the matching traffic through.
* **Skip** bypass policy checks for the matching traffic.
* **Drop** block the matching traffic.

## Step 6: Select the match type

Open the Match dropdown and choose what part of the request the rule should match on. Available match types are:

* URL
* URL parameter
* Header
* Cookie
* Body
* Source IP

## Step 7: Enter the match values

In the Match values section, fill in the value for the match type you picked. For example, if you chose URL, enter the URL path such as /some/path. If you chose a different type like URL parameter, header, or cookie, enter the corresponding value for that field.

<Frame>
  <img alt="Match values section of the new policy exception panel" />
</Frame>

## Step 8: Save

Review your entries and click Save to create the exception. The new rule now appears in the Exceptions list. To discard without saving, click Cancel.

## Quick summary

1. Check the logs and the Matched Data column to see why a request was flagged.
2. Go to the Policies page and click Create exception.
3. Enter any rule name, for example exception1.
4. Select your website from the dropdown.
5. Select the action (Accept, Skip, or Drop).
6. Select the match type (URL, parameter, header, cookie, body, or source IP).
7. Enter the match values for that type.
8. Click Save.


# Policy Configuration
Source: https://docs.osto.one/how-to-guides/policy-configuration/index

Policies are how you tell Osto what to enforce — what's allowed, what's blocked, and how.

Policies reference the assets you've already registered (users, servers, domains) and determine what's allowed, what's blocked, and how.

> **Path:** Policies in the sidebar

The Policies section is organized by the kind of asset being protected:

```
Policies
├─ Endpoint Users       → policies that apply to your team's devices
│  ├─ Device Control
│  ├─ App Control
│  ├─ Domain Filtering
│  ├─ Data Leakage Prevention → App File Access
│  └─ Global Policy
├─ Domains              → policies that apply to inbound web traffic
│  ├─ Global Policies: DDoS, Bot
│  └─ Local Policies: Advanced, Custom Routing Rules, Policy Exceptions, API Discovery
└─ Server Access        → policies that govern who reaches which server
```

## In this section

### [User Protection Policy](/how-to-guides/policy-configuration/user-protection-policy)

Endpoint policies — what users on managed devices can run, plug in, access on the web, or send out. Covers **Device Control**, **App Control**, **Domain Filtering**, **App File Access** (DLP), and the baseline **Global Policy**.

### [Secure Server Access Policy](/how-to-guides/policy-configuration/secure-server-access-policy)

Who can reach which server, when, and what services they can use. Rules-list page with **Priority / Source / Destination / Service / Action** columns. Default is deny-all (an implicit *Drop the traffic* rule at the bottom).

### [Website Protection Policy](/how-to-guides/policy-configuration/website-protection-policy)

How Osto inspects inbound traffic to your registered domains. Split into **Global Policies** that apply account-wide (DDoS, Bot Mitigation) and **Local Policies** that apply per-domain (Advanced WAF protections, Custom Routing Rules, Policy Exceptions, API Discovery).

## Two UI patterns you'll see

Osto's policy UX comes in two distinct shapes across the dashboard:

1. **Configuration-on-target pages** — most policies. You see a list of the assets the policy can apply to (users, groups, or domains), select one or more, and click **Edit \[Policy Type] +** to configure the policy for that selection.
2. **Rules-list pages** — *Server Access* and *Policy Exceptions*. You see an ordered list of explicit rules (Priority, Name, Source, Destination, Action). New rules are added with a top-level Add button. The first matching rule wins (with an implicit deny at the bottom for Server Access).

## A note on OWASP coverage

Osto's protection against the OWASP Top 10 (SQL injection, XSS, parameter tampering, sensitive data exposure, etc.) is built into the **Advanced** policy under **Policies → Domains → Advanced** — specifically the *Url Protection*, *Parameter Protection*, and *Data Theft Protection* toggles. There is no separate "OWASP" page; configure it through Advanced.


# Secure Server Access Policy
Source: https://docs.osto.one/how-to-guides/policy-configuration/secure-server-access-policy

Define who can reach which Secure Server, on which ports, and what happens to unmatched traffic.

The Server Access policy decides who can reach which Secure Server (or child server behind a Secure Gateway), on which ports, and what happens to traffic that doesn't match any rule. Default behavior is **deny all** — an implicit *Drop the traffic* rule sits at the lowest priority and only matching allow-rules let traffic through.

> **Path:** Policies → Server Access

## The page

The Server Access policy page is a single ordered table of rules, grouped by priority bucket.

| Column                     | What it shows                                                                                                |
| -------------------------- | ------------------------------------------------------------------------------------------------------------ |
| **Priority**               | Rule precedence. Rules group by bucket: *High*, *Medium*, *Low*. Within a bucket, the rule added first wins. |
| **Name**                   | Friendly name for the rule.                                                                                  |
| **Source**                 | Who the rule applies to — a Usergroup, an individual user, or *Any*.                                         |
| **Destination → Objects**  | Which servers — a specific Secure Server, a group, or *Any Server*.                                          |
| **Destination → Services** | Which ports/services — SSH, RDP, or a custom Service object defined under Objects.                           |
| **Action**                 | **Accept the traffic** or **Drop the traffic**.                                                              |
| **Actions**                | Edit and delete affordances per rule row.                                                                    |

A built-in **Implicit Policy** row sits at the bottom in the *Low* bucket with everything set to *Any* and Action *Drop the traffic*. It catches everything not explicitly allowed and **cannot be deleted** — it can only be out-prioritized by other rules.

<Note>
  First added policy has more precedence in the same priority bucket. Order within a priority bucket matters.
</Note>

## Adding a rule

<Steps>
  <Step title="Navigate to Server Access">
    Go to **Policies → Server Access** and click **Add Secure Server Access Policy +**.
  </Step>

  <Step title="Fill in the rule details">
    * **Name** — descriptive (e.g. *DevOps SSH to prod*).
    * **Priority** — dropdown. Default **High**. Other values: *Medium*, *Low*.
    * **Source** — dropdown of Usergroups and users from [Managing Users & Groups](/how-to-guides/asset-management/managing-users-groups). Tick **Any** to apply to all sources.
    * **Destination** — dropdown of registered Secure Servers from [Managing Secure Servers](/how-to-guides/asset-management/managing-secure-servers). Tick **Any Server** to apply to all.
    * **Service** — dropdown of services/ports defined as Objects. Tick **Any** to apply to all services.
    * **Action** — radio buttons: **Accept the traffic** (permit) or **Drop the traffic** (block).
  </Step>

  <Step title="Save">
    Click **Save**. The rule appears in the table in the priority bucket you chose.
  </Step>
</Steps>

## Editing a rule

Click the **edit** icon on the rule's row, change the relevant fields, and save.

## Deleting a rule

Click the **delete** icon on the rule's row and confirm. The implicit deny-all row at the bottom cannot be deleted.

## Things to remember

* **Default is deny.** Until you add an *Accept the traffic* rule, no one can reach any Secure Server through Osto.
* **Order within a priority bucket matters** — the first matching rule wins. If two rules in the *Medium* bucket both match, the one you added first takes effect.
* **Use specific over generic.** Prefer *user → specific server → specific service* rules over broad *Any* rules. The audit trail in Logs → Secure Server is far more useful that way.

## Related

* [Managing Secure Servers](/how-to-guides/asset-management/managing-secure-servers) — register the servers these rules target.
* [Managing Users & Groups](/how-to-guides/asset-management/managing-users-groups) — define the Sources.
* [Core Concepts](/getting-started/core-concepts) — the model behind Objects (Services, Ports, Schedules).


# User Protection Policy
Source: https://docs.osto.one/how-to-guides/policy-configuration/user-protection-policy

Control what people on your team can do from their managed devices — apps, peripherals, websites, and data.

User Protection policies control what people on your team can do from their managed devices — what apps they can run, what peripherals they can use, what websites they can reach, and what data they can move. Each sub-policy targets one slice of that behavior.

> **Path:** Policies → Endpoint Users

Every sub-policy page shares the same target-list shape: rows of your **Usergroups** (expandable to individual users) with a **Policy Type** column showing what's currently assigned. The button at the top reads **Edit \[Policy Type] +** and is disabled until you tick a row. Selecting a Usergroup applies the change to everyone in it.

| Column             | What it shows                                                                                                               |
| ------------------ | --------------------------------------------------------------------------------------------------------------------------- |
| **Usergroup/Name** | Groups expand to reveal users. Defined in [Managing Users & Groups](/how-to-guides/asset-management/managing-users-groups). |
| **Email**          | The user's email.                                                                                                           |
| **Policy Type**    | *User Group Policy* (inherited from the group), *No Policy*, or a specific override.                                        |

***

## Device Control

> **Sub-path:** Policies → Endpoint Users → Device Control

Controls which physical peripherals managed devices may use.

**Edit Device Policy dialog:**

* **Schedule Class** — dropdown. Default *Forever*. Use to restrict the policy to specific time windows defined in **Objects → Schedule**.
* **Devices** — seven toggles, each defaulting to *Allow* unless noted:

| Device              | Default | Notes                                                                 |
| ------------------- | ------- | --------------------------------------------------------------------- |
| USB Storage Devices | Allow   | Has a **Read Only** checkbox sub-option to permit mount-as-read-only. |
| Portable Devices    | Allow   | Phones, cameras, media players.                                       |
| Wifi                | Allow   | The device's own Wi-Fi adapter.                                       |
| Webcam              | Allow   |                                                                       |
| Local Printers      | Allow   |                                                                       |
| Network Sharing     | **Off** | File / network sharing protocols.                                     |
| Bluetooth           | Allow   |                                                                       |

***

## App Control

> **Sub-path:** Policies → Endpoint Users → App Control

Controls which applications (or app categories) managed devices may run.

**Edit App Policy dialog:**

* **Schedule Class** — dropdown. Default *Forever*.
* **App Categories** — table of category-level rules:

| App Name          | Priority Level      | Action       |
| ----------------- | ------------------- | ------------ |
| All Apps          | Very Low (Default)  | Allow toggle |
| Instant Messaging | Low / Medium / High | Allow toggle |
| VPN               | Low / Medium / High | Allow toggle |
| Web Browser       | Low / Medium / High | Allow toggle |
| P2P               | Low / Medium / High | Allow toggle |

Priority Level determines which rule takes effect if an app matches more than one category — *High* outranks *Medium* outranks *Low*. *All Apps* is the catch-all baseline.

***

## Domain Filtering

> **Sub-path:** Policies → Endpoint Users → Domain Filtering

Controls which categories of websites managed devices can resolve and visit.

**Edit Policy dialog:**

* **Schedule Class** — dropdown. Default *Forever*.
* **Domain Categories** — long list of categories, each with an **Allow** toggle. Categories include *Abortion, Academic Fraud, Activism, Adult & Pornography* (off by default), *Advertising, Armed Forces, Artificial Intelligence Technology, Arts & Fashion*, and many more. *Adult & Pornography* is the only category that defaults to denied.

***

## Data Leakage Prevention → App File Access

> **Sub-path:** Policies → Endpoint Users → Data Leakage Prevention → App File Access

DLP rules for which applications can read which classes of sensitive data on a managed device.

**Edit DLP Policy dialog:**

* **Schedule Class** — dropdown. Default *Forever*.
* **Rules** — ordered list. *Rules at the top have higher priority. Drag to reorder.*
* Each rule is a row with:
  * **PRIORITY \[N]** badge.
  * **If source is** — multi-select dropdown over data classifications (e.g. *PII*, *FINANCE*, …).
  * **apply to** — dropdown to pick the application(s) the rule applies to.
  * **ALLOW** / **BLOCK** toggle.
  * Delete (trash) icon.
* **Add execution rule** button to append a new rule at the bottom.

***

## Global Policy

> **Sub-path:** Policies → Endpoint Users → Global Policy

The baseline posture policy that applies to every managed device in a group.

**Edit Global Policy dialog:**

* **Screen lock**
  * Checkbox: *"Require screen lock when idle"* (default off). Locks the session after inactivity for users in this group.
* **Disk encryption**
  * Checkbox: *"Require full-disk encryption"* (default off). Devices for this group must report encryption as compliant.

***

## A typical configuration order

1. Set Global Policy on the **Common** group first as your baseline (screen lock + disk encryption).
2. Tune Device Control if your environment requires restricting USB storage, Bluetooth, or other peripherals.
3. Configure App Control based on what your team uses (and prohibits).
4. Set Domain Filtering categories.
5. Add DLP rules under App File Access for any sensitive-data flows you care about.
6. Repeat per group if different teams need different policies.

## Related

* [Managing Users & Groups](/how-to-guides/asset-management/managing-users-groups) — define the Usergroups these policies target.
* [Core Concepts](/getting-started/core-concepts) — how Osto thinks about Assets, Objects, and Policies.


# Website Protection Policy
Source: https://docs.osto.one/how-to-guides/policy-configuration/website-protection-policy

Configure how Osto inspects inbound web traffic to your registered domains — global and per-domain policies.

Website Protection policies govern how Osto inspects inbound web traffic to your registered domains. They split into **Global Policies** (apply across all your domains) and **Local Policies** (per-domain overlays).

> **Path:** Policies → Domains

***

## Global Policies

These apply account-wide. Each one is a single page with a master on/off toggle and a list of pre-defined attack/bot rules.

### DDoS

> **Sub-path:** Policies → Domains → DDoS

Volumetric and protocol-level denial-of-service mitigation.

**Page:** Master `DDoS Protection` toggle (default on) above a read-only table of 10 attack types:

| Column          | Values                                                                                                                                                                                                                                                             |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Attack Type** | Floating Point DoS Attack · Generic DoS Attack · Other · Range: Invalid Last Byte Value · Range: Too many fields · Slowloris Attack · WordPress DoS Attack · WordPress Pingback zombie Attack · WordPress trackback resource exhaustion attack · XMLRPC DoS Attack |
| **Severity**    | *low*, *medium*, *high* — assigned per attack type                                                                                                                                                                                                                 |

Severities are pre-defined and not editable. The configurable surface is the global toggle.

### Bot

> **Sub-path:** Policies → Domains → Bot

Bot detection and mitigation across a large catalog of known automated agents and patterns.

**Page:** Master `Bot Mitigation` toggle (default on) above a read-only, paginated table of **54 bot rules**, each with a *low* / *medium* / *high* severity. Examples: *Block Bad bot [www.80legs.com](http://www.80legs.com)*, *Block Badbot User-Agent*, *Block Blackseo bot*, *Block CryptoPHP*, *Block DRM bot*, *Block DataCha0s bot*, *Block Datanyze bot* (medium), *Block Fake zoominfo search bot*, *Block ICS bot*, and more.

As with DDoS, severities are pre-defined and the global toggle is the configurable surface.

***

## Local Policies

These apply per-domain. The first three are configuration pages; the last (API Discovery) is observational.

### Advanced

> **Sub-path:** Policies → Domains → Advanced

The richest WAF policy in Osto — covers the OWASP-class protections (URL injection, parameter tampering, sensitive-data leakage) along with cookie security and rate limiting.

**Page columns** (per registered domain): Website Name, FQDN, Data Theft, Cloaking, Parameter (Protection), URL Protection, Cookie Security, Actions (with **Edit** pencil).

**Edit Policy dialog** (per domain) — seven feature toggles, each with its own deeper-config pencil:

| Feature                   | Default | What it covers                                                                                             |
| ------------------------- | ------- | ---------------------------------------------------------------------------------------------------------- |
| **Request Limit**         | On      | Caps request size and shape (headers, body bytes, parameter counts).                                       |
| **Cookie Security**       | Off     | Cookie signing / tamper detection.                                                                         |
| **Url Protection**        | On      | URL-pattern validation — covers OWASP path-injection and traversal classes.                                |
| **Parameter Protection**  | Off     | Query/body parameter validation — covers OWASP injection (SQL, XSS, command injection) classes.            |
| **Cloaking**              | Off     | Hides origin server fingerprints in responses.                                                             |
| **Data Theft Protection** | Off     | Inspects responses for sensitive data leakage (PII, credentials) — covers OWASP *Sensitive Data Exposure*. |
| **Rate Limit**            | Off     | Per-client request-rate ceiling for the domain.                                                            |

<Note>
  **OWASP Top 10 coverage lives here.** Url Protection + Parameter Protection + Data Theft Protection together cover the OWASP injection, broken-access-control, and sensitive-data-exposure classes. There is no separate "OWASP" page in the dashboard.
</Note>

### Custom Routing Rules

> **Sub-path:** Policies → Domains → Custom Routing Rules

Per-domain rules to direct matching traffic to specific origin endpoints.

**Page columns:** Website / rule, Route Matching, Prefix Match, Exact Match, Regex Match, Actions.

Each registered domain appears as an expandable group with:

* A built-in **Default Rule** at path prefix `/` (cannot be deleted) that catches everything not matched by a more specific rule.
* An **+ Add routing rule** button on the group row to append new rules.

Match types available per rule:

* **Prefix Match** — match URL path beginning with a specified prefix.
* **Exact Match** — match a specific URL path exactly.
* **Regex Match** — match against a regular expression.

### Policy Exceptions

> **Sub-path:** Policies → Domains → Policy Exceptions

Named carve-outs that let specific traffic bypass otherwise-applicable protections. Use sparingly — only when a known-legitimate request shape is being incorrectly flagged.

**Page columns:** Name, Hostname, Action, Parameter Location, Parameter Name, Parameter Value, Actions.

**New policy exception dialog:**

* **Rule name** — placeholder *"e.g. allow-admin-api"*.
* **Website** — dropdown selecting which registered website this exception applies to.
* **WHEN TRAFFIC MATCHES** — match conditions:
  * **Then** — dropdown choosing the action to apply when matched (allow/skip-check/etc.).
  * **Match** — dropdown choosing the match type.
  * **Match values → URL path** — the specific URL path that triggers this exception.

### API Discovery

> **Sub-path:** Policies → Domains → API Discovery

Observation page (browser title: *API Inventory*) showing every API endpoint Osto has automatically discovered under your protected domains by inspecting live traffic. There is no configuration on this page — only a `Refresh` button to re-pull the latest inventory.

**Page columns:** Host, Method, URI, Hits, Last Seen, Response Content (type/length summaries).

Use this view to spot shadow APIs, unintended exposures, or endpoints that should be hidden behind authentication.

***

## A typical configuration order for a new domain

1. Confirm **DDoS** and **Bot** are toggled on (account-wide, you usually only do this once).
2. Open **Advanced**, click **Edit** on the row for the new domain, and enable the relevant feature toggles. Start with *Url Protection* and *Parameter Protection* on; add *Data Theft Protection*, *Cookie Security*, and *Rate Limit* as needed for the workload.
3. If different paths on the domain need different origins, configure **Custom Routing Rules**.
4. Watch **API Discovery** for a few days to see what endpoints get discovered.
5. Add **Policy Exceptions** only when a real positive is being incorrectly blocked.
6. Pair the protection with the per-domain **Firewall Mode** toggle on **Manage Domains** — start in *Detect Mode* to observe what would be blocked, then flip to *Prevent Mode*.

## Related

* [What is Web Application Protection](/overview/what-is-web-app-protection) — the underlying protection model and request flow.
* [Managing Websites & Subdomains](/how-to-guides/asset-management/managing-websites) — register the domains these policies target. Includes the Firewall Mode toggle.


# Connecting AWS to Osto
Source: https://docs.osto.one/how-to-guides/posture-management/connecting-aws

Securely connect your AWS account to Osto for continuous cloud security posture management.

This guide walks you through securely connecting your AWS account to Osto for continuous visibility, scanning, and cloud security posture management.

**Before you begin:**

* Open the [AWS Management Console](https://aws.amazon.com/console/) and sign in with your AWS credentials.
* You'll need to collect a few identifiers and credentials during this setup — follow the steps below carefully.

<Frame>
  <img alt="Connect to Amazon Web Services form with Name, Description, Account ID, Access Key ID, and Secret Access Key fields" />
</Frame>

<Steps>
  <Step title="Find Your AWS Account ID">
    Your **AWS Account ID** uniquely identifies your AWS account and is required for integration.

    To find it:

    1. In the AWS Console, search for **IAM**.
    2. Open the **IAM (Identity and Access Management)** service.
    3. On the **IAM Dashboard**, locate the **AWS Account** section.
    4. Copy the **Account ID** and save it — you'll need it later.
  </Step>

  <Step title="Create or Use an Existing IAM User">
    Osto connects to AWS using an IAM user with restricted, read-only permissions. If you don't already have one, create it:

    1. In the IAM sidebar, click **Users**.
    2. Click **Create user**.
    3. Enter a user name (for example, `osto-cloud-security-posture-management`).
    4. Click **Next**.
  </Step>

  <Step title="Assign Permissions to the IAM User">
    Osto requires read-only access to scan and assess your cloud resources. Assign the following AWS-managed policies:

    1. Under **Set permissions**, choose **Attach policies directly**.
    2. Search for and select the following policies:
       * **SecurityAudit**
       * **ViewOnlyAccess**
    3. Click **Next**, review details, and then click **Create user**.
  </Step>

  <Step title="Create Access Keys">
    Osto authenticates using access keys associated with your IAM user. To create one:

    1. Return to **IAM → Users**.
    2. Click on the user you created.
    3. Go to the **Security credentials** tab.
    4. Scroll down to **Access keys** and click **Create access key**.
    5. Choose **Third-party service** (for integrations and monitoring).
    6. Check the confirmation box and click **Next**.
  </Step>

  <Step title="(Optional) Add a Description Tag">
    * Add a tag description such as **"Osto integration key for monitoring resources"**.
    * Click **Create access key**.
  </Step>

  <Step title="Retrieve and Secure Your Keys">
    After the access key is created, the console will display:

    * **Access Key ID**
    * **Secret Access Key**

    <Warning>
      The Secret Access Key is only shown once. Copy and store it securely — if it's lost, you must create a new key.
    </Warning>

    Click **Done** after securely saving both values.
  </Step>

  <Step title="Fill in the Osto Cloud Connector Form">
    In the Osto platform, open the **Connect a Cloud Provider** window and select **Amazon Web Services (AWS)**.

    Fill in the fields as follows:

    * **Name:** A friendly name for your AWS connection (e.g., "Prod AWS Account").
    * **Description:** Optional description for easier identification.
    * **Account ID:** The AWS account ID you copied earlier.
    * **Access Key ID:** The Access Key ID from the IAM user you created.
    * **Secret Access Key:** The Secret Access Key generated in the previous step.

    Once filled, click **Connect** to authenticate and establish the integration.
  </Step>

  <Step title="Verify Connection">
    After connecting successfully:

    * Your AWS assets will start syncing automatically.
    * The **Osto Dashboard** will display asset count and necessary metrics.
    * The connector's status will change to **Active**.
  </Step>
</Steps>

## Permissions Reference

At minimum, the IAM user must have:

* `SecurityAudit`
* `ViewOnlyAccess`

If your organization enforces least privilege, you may instead assign a custom IAM role restricted to Osto's required read-only actions.

## Summary of Required Values

| Parameter         | Source                             | Example                                    |
| ----------------- | ---------------------------------- | ------------------------------------------ |
| AWS Account ID    | IAM Dashboard → AWS Account        | `123456789012`                             |
| Access Key ID     | IAM → Users → Security credentials | `AKIAIOSFODNN7EXAMPLE`                     |
| Secret Access Key | Shown once upon key creation       | `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY` |

## Troubleshooting

<AccordionGroup>
  <Accordion title="Connection fails — verify attached policies">
    If the connection fails, verify that the IAM user has both **SecurityAudit** and **ViewOnlyAccess** policies attached.
  </Accordion>

  <Accordion title="Check Access Key and Secret">
    Double-check that your **Access Key ID** and **Secret Access Key** are correct.
  </Accordion>

  <Accordion title="Lost Secret Access Key">
    If the **Secret Access Key** is lost, create a new access key — it cannot be retrieved later.
  </Accordion>

  <Accordion title="Network connectivity">
    Ensure your network allows outbound connections to Osto's API endpoints.
  </Accordion>
</AccordionGroup>


# Connecting Microsoft Azure to Osto
Source: https://docs.osto.one/how-to-guides/posture-management/connecting-azure

Securely connect your Azure subscription to Osto for continuous cloud security posture management.

This guide will walk you through securely connecting your Microsoft Azure subscription to Osto for continuous visibility, scanning, and cloud security posture management.

**Before you begin:**

* Navigate to the [Azure Portal](https://portal.azure.com/).
* Sign in using your Azure account credentials.
* You'll need to collect a few identifiers and credentials during this setup — follow the steps below carefully.

<Frame>
  <img alt="Connect to Microsoft Azure form with Name, Description, Subscription ID, Client ID, Client Secret, and Tenant ID fields" />
</Frame>

<Steps>
  <Step title="Find Your Tenant ID">
    Your **Tenant ID** uniquely identifies your Azure Active Directory (Microsoft Entra ID) instance.

    To find it:

    1. In the Azure Portal, search for **"Microsoft Entra ID"** (or **"Azure Active Directory"** in older interfaces).
    2. Click **Overview** in the sidebar.
    3. Copy the **Tenant ID** displayed there — you'll need it later for the Osto connection form.
  </Step>

  <Step title="Locate Your Subscription ID">
    Your **Subscription ID** represents the Azure billing account that Osto will access.

    To locate it:

    1. In the Azure Portal search bar, type **"Subscriptions"**.
    2. Select your active subscription from the list.
    3. On the **Overview** tab, copy the **Subscription ID**.
  </Step>

  <Step title="Create or Use an Existing Service Principal">
    Osto connects to Azure via a **Service Principal (App Registration)**. If you don't already have one, create it as follows:

    1. In Azure Portal, go to **Microsoft Entra ID → App registrations**.
    2. Click **+ New registration**.
    3. Provide a name (e.g., `Osto-Azure-Connector`).
    4. Under "Supported account types," choose **Accounts in this organizational directory only (Single tenant)**.
    5. Click **Register**.
    6. Copy the **Application (client) ID** — this is your **Client ID**.
  </Step>

  <Step title="Generate a Client Secret">
    1. In your App Registration, navigate to **Certificates & secrets**.
    2. Under **Client secrets**, click **+ New client secret**.
    3. Provide a description (e.g., "Osto integration key") and select an expiry period (e.g., 1 year).
    4. Click **Add**.
    5. Copy the **Value** immediately — this is your **Client Secret**.

    <Warning>
      You will not be able to view the client secret again after you leave the page. Copy and store it securely before navigating away.
    </Warning>
  </Step>

  <Step title="Fill in the Osto Cloud Connector Form">
    Return to your **Osto platform** and open the **Connect a Cloud Provider** window. Select **Microsoft Azure**.

    Fill in the fields as follows:

    * **Name:** A friendly name for your Azure connection (e.g., "Prod Subscription").
    * **Description:** Optional description for easier identification.
    * **Subscription ID:** The Azure Subscription ID you copied earlier.
    * **Client ID:** The Application (client) ID from your registered app.
    * **Client Secret:** The secret value created under Certificates & Secrets.
    * **Tenant ID:** The Tenant ID from Microsoft Entra ID.

    Once filled, click **Connect** to authenticate and establish the integration.
  </Step>

  <Step title="Verify Connection">
    After connecting successfully:

    * Your Azure assets will start syncing automatically.
    * You'll see the total number of assets and a severity breakdown on your Osto dashboard.
    * The connector's status will change to **Active**.
  </Step>

  <Step title="Optional: Assign Specific Azure Roles">
    Ensure your Service Principal has adequate permissions to allow asset discovery.

    * At a minimum, assign the **Reader** role at the subscription level.
    * If your organization enforces least privilege policies, you may also use a custom role scoped to Osto's required actions.
  </Step>
</Steps>

***

## Summary of Required Values

| Parameter           | Source                                    | Example                                |
| ------------------- | ----------------------------------------- | -------------------------------------- |
| **Tenant ID**       | Microsoft Entra ID → Overview             | `c09e8f8a-xxxx-xxxx-xxxx-xxxxxxxxxxxx` |
| **Subscription ID** | Subscriptions → Overview                  | `7f53e0a3-xxxx-xxxx-xxxx-xxxxxxxxxxxx` |
| **Client ID**       | App Registration → Overview               | `23dbb6af-xxxx-xxxx-xxxx-xxxxxxxxxxxx` |
| **Client Secret**   | App Registration → Certificates & secrets | `Value from secret (hidden)`           |

***

## Troubleshooting

<AccordionGroup>
  <Accordion title="Error: &#x22;Invalid credentials&#x22;">
    Double-check Client ID, Client Secret, and Tenant ID values entered in the Osto connector form.
  </Accordion>

  <Accordion title="Error: &#x22;Insufficient permissions&#x22;">
    Ensure your Service Principal has the **Reader** role assigned at the subscription level or the appropriate custom role that grants Osto the required permissions.
  </Accordion>

  <Accordion title="Secret Expired">
    Generate a new client secret in Azure (App Registration → Certificates & secrets) and update it in Osto.
  </Accordion>
</AccordionGroup>


# Connecting GCP to Osto
Source: https://docs.osto.one/how-to-guides/posture-management/connecting-gcp

Securely connect your Google Cloud Platform project to Osto for continuous cloud security posture management.

This guide will walk you through securely connecting your Google Cloud Platform (GCP) project to Osto for continuous visibility, scanning, and cloud security posture management.

**Before you begin:**

* Navigate to the [Google Cloud Console](https://console.cloud.google.com/).
* Sign in using your Google account credentials.
* You'll need to collect a few identifiers and credentials during this setup — follow the steps below carefully.

<Frame>
  <img alt="Connect to Google Cloud Platform form with Name, Description, Project ID, and Service Account Key (JSON) fields" />
</Frame>

<Steps>
  <Step title="Find Your Project ID">
    Your **Project ID** uniquely identifies your Google Cloud project.

    To find it:

    1. In the Google Cloud Console, open the **Project Selector** at the top.
    2. Locate the project you want to connect to Osto.
    3. Copy the **Project ID** — you'll need it later for the Osto connection form.
  </Step>

  <Step title="Create a Service Account">
    Osto connects to GCP using a **Service Account** with read-only permissions.

    To create one:

    1. Navigate to **IAM & Admin → Service Accounts**.
    2. Click **Create Service Account**.
    3. Provide a name such as `osto-cloud-security-posture-management`.
    4. Add an optional description (e.g., "Osto to monitor resources").
    5. Click **Create and continue**.
  </Step>

  <Step title="Assign the Viewer Role">
    Your service account must have read-only access.

    To assign permissions:

    1. In the role selector, search for **Viewer**.
    2. Select **Viewer** (basic read-only role) and click **Continue**.

    <Note>
      This ensures the service account can **only view resources**, not modify them.
    </Note>
  </Step>

  <Step title="Skip Optional Access Settings">
    You may optionally grant others access to the service account. If not needed, click **Done**.
  </Step>

  <Step title="Generate a JSON Key">
    To generate the credentials Osto will use:

    1. Open the newly created service account.
    2. Go to the **Keys** tab.
    3. Click **Add key → Create new key**.
    4. Choose **JSON**.
    5. Click **Create**.

    A JSON key file will download automatically — store it securely.
  </Step>

  <Step title="Fill in the Osto Cloud Connector Form">
    Return to your Osto platform and open the **Connect a Cloud Provider** window. Select **Google Cloud Platform (GCP)**.

    Fill in the fields as follows:

    * **Name:** A friendly name for your GCP connection (e.g., "Prod GCP Project").
    * **Description:** Optional description for easier identification.
    * **Project ID:** The Project ID you copied earlier.
    * **Service Account Key (JSON):** Paste the contents of the JSON key file you downloaded earlier.

    Once filled, click **Connect** to authenticate and establish the integration.
  </Step>

  <Step title="Verify Connection">
    After connecting successfully:

    * Your GCP assets will begin syncing automatically.
    * The Osto Dashboard will display asset count and severity findings.
    * The connector's status will change to **Active**.
  </Step>
</Steps>

## Summary of Required Values

| Parameter            | Source                               | Example                                  |
| -------------------- | ------------------------------------ | ---------------------------------------- |
| Service Account Name | IAM & Admin → Service Accounts       | `osto-cloud-security-posture-management` |
| Role                 | Permissions Assigned During Creation | `Viewer`                                 |
| Key Type             | Keys → Create new key (JSON)         | `osto-gcp-credentials.json`              |

## Troubleshooting

<AccordionGroup>
  <Accordion title="Error: &#x22;Invalid key or credentials&#x22;">
    Ensure that the JSON key file you uploaded is valid and corresponds to the correct service account.
  </Accordion>

  <Accordion title="Error: &#x22;Insufficient permissions&#x22;">
    Verify that the service account has the **Viewer** role.
  </Accordion>

  <Accordion title="Key Lost or Deleted">
    Generate a new JSON key in the GCP Console and update it in Osto.
  </Accordion>

  <Accordion title="Connection Fails">
    Confirm your GCP project allows API access and that no firewall rules are blocking outbound requests.
  </Accordion>
</AccordionGroup>


# Cloud Security
Source: https://docs.osto.one/how-to-guides/posture-management/index

Connect your cloud accounts to Osto for continuous visibility, asset inventory, and security findings across AWS, Azure, and GCP.

Cloud Security (under **Posture Management**) connects your cloud accounts to Osto so it can continuously discover your cloud assets and surface security findings — all in one consolidated, multi-cloud view.

> **Path:** Posture Management → Cloud Security

## Connect a cloud provider

Click **Connect provider** (top-left) to open the **Connect a Cloud Provider** dialog, then choose one of the three supported providers:

<CardGroup>
  <Card title="Amazon Web Services" href="/how-to-guides/posture-management/connecting-aws" />

  <Card title="Microsoft Azure" href="/how-to-guides/posture-management/connecting-azure" />

  <Card title="Google Cloud Platform" href="/how-to-guides/posture-management/connecting-gcp" />
</CardGroup>

<Frame>
  <img alt="Connect a Cloud Provider dialog showing Microsoft Azure, Amazon Web Services, and Google Cloud Platform options" />
</Frame>

Selecting a provider opens its connection form. Each form starts with a friendly **Name** and an optional **Description**, followed by the credentials specific to that provider. Every form also links to a step-by-step setup guide ("Review the guide" / "Read the docs") — the same walkthroughs linked above. Fill in the fields and click **Connect**.

<Note>
  Osto connects with **read-only** credentials and never makes changes to your cloud environment. Each provider guide walks through creating a service account or access key scoped to the minimum read-only permissions Osto needs.
</Note>

## The Cloud Security page

The top of the page shows summary cards that update depending on which tab you're viewing, and the work area below is split into three tabs.

### Providers

Your connected accounts at a glance. Summary cards: **Providers Distribution**, **Total Providers**, **Total Assets**, **Coverage Overview**, and **Severity Breakdown**. Until you connect an account, this tab shows *"No Providers Connected"* with a **Connect Your First Provider** button.

### Inventory

The cloud assets Osto has discovered across your connected accounts. Summary cards: **Resource Type Distribution** and **Geographical Distribution**, alongside a service-distribution view. Use this tab to see what Osto found and where it lives.

### Findings

The security findings raised against your discovered assets. Summary cards: **Top Resources** (most-affected assets) and **Severity Distribution**. Use this tab to triage what needs attention first.

## Reports

The top-right **Download Global Report** button exports a report covering every connected account. Its dropdown also offers **Download Individual Report** for a single account.

## After connecting

Once an account is connected, Osto begins discovering assets and raising findings automatically; the summary cards and the Inventory and Findings tabs populate as the scan completes. Findings are organized by severity and by the resources they affect.


# App Scanner
Source: https://docs.osto.one/how-to-guides/scanner/app-scanner

Upload an Android or iOS app package to scan it for vulnerabilities, privacy risks, and hardcoded secrets.

The **App Scanner** analyzes your mobile application builds for security and privacy issues. Upload an app package and Osto inspects it, then reports vulnerabilities, high-severity findings, privacy risks, and hardcoded secrets.

> **Path:** Scanner → App Scanner

<Frame>
  <img alt="App Scanner page with a Vulnerabilities Overview donut chart and four metric cards: Security Score, High Severity Findings, Privacy Risk, and Hardcoded Secrets" />
</Frame>

## Upload an app

Click **Upload Application File** (top-left) to open the upload panel, then drag in your file or click to browse.

<Frame>
  <img alt="Upload Application File panel with a drag-and-drop area and supported platforms Android (.apk) and iOS (.ipa)" />
</Frame>

**Supported platforms and formats:**

| Platform    | File type    |
| ----------- | ------------ |
| **Android** | `.apk` files |
| **iOS**     | `.ipa` files |

The maximum file size is **100 MB**.

<Note>
  Uploading a build only submits it for analysis. Osto never publishes, distributes, or modifies your app.
</Note>

## Vulnerabilities Overview

Once you've uploaded an app, the **Vulnerabilities Overview** summarizes what the scan found — a donut chart breaks the findings down by severity (High / Warning / Info) with an overall risk rating in the center. Until your first scan completes it shows *"No scans yet — Upload an app to see vulnerability analysis."*

Alongside it, four metric cards give you a quick read on the app's posture:

| Metric                     | What it measures                                         |
| -------------------------- | -------------------------------------------------------- |
| **Security Score**         | The app's overall security rating (the *Overall score*). |
| **High Severity Findings** | The count of issues needing immediate attention.         |
| **Privacy Risk**           | The number of trackers found in the app.                 |
| **Hardcoded Secrets**      | Credentials, keys, or tokens exposed in the code.        |

## Scanned Applications

The **Scanned Applications** table lists every app you've submitted, so you can revisit past results and compare builds over time. Each row shows:

| Column             | Description                                     |
| ------------------ | ----------------------------------------------- |
| **App Name**       | The application's name.                         |
| **Package Name**   | The package identifier of the uploaded build.   |
| **Version**        | The app version.                                |
| **Hash**           | A fingerprint of the uploaded file.             |
| **Status**         | The scan status (for example, *Completed*).     |
| **Security Score** | The score out of 100.                           |
| **Risk Level**     | An overall rating such as Low, Medium, or High. |

Before your first upload it shows *"No scanned applications yet — Upload your first application to start security scanning."* Select **View Details** on any row to open its full report.

## The app report

Opening **View Details** shows the complete analysis for that build.

<Frame>
  <img alt="App report showing app metadata, a security score out of 100, a Critical Findings panel, and tabs for Code Vulnerabilities, Attack Surface, Permissions, Secrets, and Network" />
</Frame>

At the top you'll find the app's **metadata** — version, size, target and minimum SDK, and file hashes (MD5 and SHA-256) — next to its score out of 100. A **Critical Findings** panel highlights the most serious issues first.

The report then organizes everything into five tabs:

| Tab                      | What it covers                                                                                                                            |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------- |
| **Code Vulnerabilities** | Issues found in the app's code, each with a severity, type, description, and the exact file locations.                                    |
| **Attack Surface**       | Exposed components — activities, services, and broadcast receivers — and configuration weaknesses that widen the app's attack surface.    |
| **Permissions**          | Every permission the app requests, with a description and a protection level (such as *normal* or *dangerous*).                           |
| **Secrets**              | Hardcoded keys, tokens, and other secrets discovered in the code.                                                                         |
| **Network**              | Trackers bundled in the app, Firebase endpoints and their configuration, and URLs embedded in the code (with the file each was found in). |

## After a scan

When analysis completes, the Vulnerabilities Overview and the four metric cards populate with results, and the app appears in the Scanned Applications list. Upload a new build whenever you want to re-check an app after addressing its findings.


# Scanner
Source: https://docs.osto.one/how-to-guides/scanner/index

Scan your websites and mobile apps for security vulnerabilities with Osto's Web Scanner and App Scanner.

The **Scanner** gives you on-demand security testing for the two surfaces attackers probe most: your public websites and your mobile applications. Each scanner runs against assets you've already registered (or uploaded) and reports the vulnerabilities, severities, and fixes that matter.

> **Path:** Scanner

<CardGroup>
  <Card title="Web Scanner" icon="globe" href="/how-to-guides/scanner/web-scanner">
    Scan your registered domains for web vulnerabilities and track a security score over time.
  </Card>

  <Card title="App Scanner" icon="mobile" href="/how-to-guides/scanner/app-scanner">
    Upload an Android or iOS app package to analyze it for vulnerabilities, privacy risks, and hardcoded secrets.
  </Card>
</CardGroup>

## Which scanner do I use?

* **Web Scanner** — for the websites and subdomains you manage in Osto. It scans live domains and surfaces vulnerabilities, top attack paths, and a security score.
* **App Scanner** — for mobile app builds. Upload an `.apk` (Android) or `.ipa` (iOS) file and Osto analyzes the binary for security and privacy issues.

<Note>
  Both scanners are read-only assessments. Running a web scan doesn't change your site, and uploading an app build doesn't publish or modify it anywhere.
</Note>


# Web Scanner
Source: https://docs.osto.one/how-to-guides/scanner/web-scanner

Scan your registered domains for web vulnerabilities, track a security score, and generate scheduled security reports.

The **Web Scanner** tests the websites you manage in Osto for security vulnerabilities. It scans your live domains, scores their security posture, and highlights the issues and attack paths most worth your attention.

> **Path:** Scanner → Web Scanner

<Frame>
  <img alt="Web Scanner page showing a security score out of 10, a Total Vulnerabilities donut chart with severity counts, a Top Vulnerabilities list, and a Top Attack Paths panel" />
</Frame>

## Run a scan

Click **Run Scan Now** (top-left) to start a scan immediately — there's no extra setup or dialog. A confirmation banner appears: *"Scan started — We have started your scan. Results will appear shortly."*

The scan runs in the background against the domain currently selected in the domain dropdown (or across **all domains** if that's selected). Results populate the page automatically once the scan completes.

<Note>
  The scanner only assesses your sites — it never modifies them. You can run a scan as often as you need.
</Note>

## Choosing what to scan

The domain selector below the score lets you focus on a single site or view everything together:

* **All Domains** — the aggregated view across every domain you've registered, with a combined vulnerability count.
* **Individual domain** — each registered domain is listed with its own vulnerability count and scan status (for example, *"Not scanned"* until its first scan completes).

Domains come from your **Manage Domains** list under Assets, so any site you add there becomes available to scan here.

## Security Score

At the top of the page, Osto shows a **Security Score** out of 10 with a plain-language rating beneath it (such as *High Security*). The score reflects the results of your most recent scan for the selected scope, giving you an at-a-glance sense of where a site stands.

## Vulnerabilities tab

The **Vulnerabilities** tab is your results dashboard, organized into three summary views plus a detailed findings table:

| View                      | What it shows                                                                                                                               |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| **Total Vulnerabilities** | A donut chart with the count of findings by severity — **Critical**, **High**, **Medium**, **Low**, and **Informational** — plus the total. |
| **Top Vulnerabilities**   | The most significant findings, each shown with its severity, identifier, and a short description.                                           |
| **Top Attack Paths**      | The routes an attacker could chain together to reach sensitive areas.                                                                       |

Before your first scan returns data, each view shows *"No scan data found yet."*

### All Vulnerabilities table

Below the summary views, the **All Vulnerabilities** table lists every finding from the scan:

| Column           | Description                                            |
| ---------------- | ------------------------------------------------------ |
| **CWE-ID**       | The weakness identifier (links to a full detail view). |
| **API Endpoint** | The address that was tested.                           |
| **Description**  | What the issue is.                                     |
| **Name**         | A short title for the finding.                         |
| **Severity**     | Critical, High, Medium, Low, or Informational.         |
| **Solution**     | Recommended remediation.                               |

The table is paginated, with a selectable page size.

<Frame>
  <img alt="All Vulnerabilities table with columns for CWE-ID, API Endpoint, Description, Name, Severity, and Solution" />
</Frame>

### Finding details

Click any finding's identifier to open a **Vulnerability Details** panel with the complete write-up: severity, the affected endpoint and URL, a full description and recommended solution, the scanner's confidence level, the supporting evidence, and tags. The identifier also links out to the public reference for that weakness.

<Frame>
  <img alt="Vulnerability Details side panel showing CWE ID, severity, API endpoint, affected URL, name, description, solution, confidence, evidence, and tags" />
</Frame>

## Reports tab

The **Reports** tab keeps your generated security reports and explains the delivery cadences:

* **Security Reports** — the list of reports Osto has generated. It's empty until your first report is produced.
* **Reports Schedule** — describes how often reports are delivered:
  * **Daily Reports** — delivered within 24 hours of the selected daily schedule.
  * **Weekly Reports** — delivered within 7 days of the selected weekly schedule.
  * **Monthly Reports** — delivered within 30 days of the selected monthly schedule.

## After a scan

Once a scan finishes, the Security Score, the three Vulnerabilities views, and the results panel update with your findings, and reports become available under the Reports tab. Re-run a scan any time to refresh the picture after you've shipped fixes.


# Welcome to Osto
Source: https://docs.osto.one/index

One platform for security, compliance, and VAPT — built for fast-moving startups and scaling businesses.

**Osto is your trusted cybersecurity partner, built to simplify security for growing businesses.** Instead of stitching together a WAF, an endpoint tool, a CSPM, a compliance platform, and a VAPT firm — Osto delivers all of it as a single operating layer. You get real security, continuously mapped compliance, and audit-ready evidence, without needing a large IT or security team.

Compliance is the byproduct of security. We fix both.

## What you get

* **Real-time security** across cloud, application, endpoint, and network — live in hours.
* **Continuous compliance** with SOC 2 Type II, ISO 27001, HIPAA, GDPR, and PCI DSS — controls mapped and evidence collected automatically.
* **OSCP-led VAPT** with a 7-day testing cycle, remediation support, and final diligence-ready reports.
* **One dashboard** — 20+ modules, one invoice, one source of truth.

<img alt="Osto Platform Overview" />

Every module ships from one platform and rolls up to one dashboard — so security, compliance evidence, and VAPT findings stay in sync.

## Platform modules

### ☁️ Cloud Security

* **Web App Protection** — OWASP Top 10, DDoS, bot blocking, and virtual patching.
* **Web API Protection** — Shadow API discovery, schema enforcement, and malicious traffic blocking.
* **Web Scanner** — Continuous vulnerability scanning of internet-facing applications.
* **Mobile App Scanner** — iOS and Android security testing before release.
* **Cloud Posture (CSPM)** — Misconfiguration and drift detection across AWS, Azure, and GCP.

### 💻 Code Security

* **SAST** — Static analysis integrated into your CI/CD.
* **SBOM** — Software bill of materials for every build.
* **SCA** — Dependency and vulnerability scanning.
* **License Compliance** — Open-source license policy enforcement in CI.

### 🖥️ Endpoint Security

* **App Control** — Whitelist approved applications and reduce unauthorized execution.
* **Device Control** — Govern USB, Wi-Fi, Bluetooth, and removable media.
* **File Access DLP** — Sensitive file access controls and data-loss prevention.
* **Disk Encryption** — FileVault and BitLocker enforcement.
* **Screen Lock** — Idle-session protection.

### 🌐 Network Security

* **ZTNA Secure Access** — Zero Trust with 2FA, time-based permissions, and instant blocking.
* **Domain Filtering** — Block malicious domains and enforce browsing policies.

### 📋 Compliance

* **Compliance Automation** — Continuously mapped controls and audit-ready evidence for SOC 2 Type II, ISO 27001, HIPAA, GDPR, and PCI DSS.
* **Security Awareness Training** — Continuous employee training with participation evidence audit-ready.

### 🔬 VAPT

* **Web App & API** — Black-box and grey-box testing.
* **Network & Infrastructure** — Internal and external attack simulation.
* **Mobile App Assessment** — iOS and Android security testing.
* **Source Code Assessment** — Secure SDLC and code-level findings.

### 📂 Audits

* **Logs Analyzer** — Centralized logs and audit-ready posture across every module.

## Why teams choose Osto

* **Days, not months.** Security controls live on Day 0. SOC 2 / ISO readiness in 7 days. ISO audit complete by Day 21.
* **Built in-house, end to end.** Every module is built and maintained by Osto — no third-party patchwork.
* **Proven on our own stack.** Osto is itself SOC 2 Type II and ISO 27001 certified, using the same platform we sell.

### Zero to SOC 2 Type II ready

```mermaid theme={null}
timeline
    title From deployment to audit-ready in under 4 months
    Day 0   : Security controls live across Cloud, App, Endpoint & Network
            : VAPT scope finalized
    Day 7   : VAPT findings delivered for remediation
            : SOC 2 & ISO 27001 control readiness reached
            : Internal & external audit kicked off
            : SOC 2 evidence collection on
    Day 21  : HIPAA readiness signed off
            : GDPR readiness (ROPA, DPIA, data map)
            : ISO 27001 external audit complete
    Day 97  : 90-day SOC 2 evidence period complete
            : Documents sent for external audit
    Day 118 : SOC 2 Type II readiness achieved
```

## Next steps

New to Osto? Start here:

* [Quick Start Guide](/getting-started/quick-start) — get up and running in minutes.
* [Core Concepts](/getting-started/core-concepts) — the foundations you'll work with day to day.
* [Posture Management](/how-to-guides/posture-management/connecting-aws) — connect your cloud accounts.

Need help? See [Best Practices](/support/best-practices), [FAQs](/support/faqs), or [Troubleshooting](/support/troubleshooting).


# High Level Architecture
Source: https://docs.osto.one/overview/high-level-architecture

A look at how Osto sits between the public internet and your environment.

This page is a companion to the [Overview](/index) — read that first for what each module does; this page explains how they fit together and how data flows.

<img alt="Osto Platform - High Level Architecture" />

## The three zones

### 🌐 Internet

Everything reaching your assets from the public web — legitimate users, partners, and integrations on one side; bots, scanners, and attackers on the other. Traffic enters Osto Cloud before it ever touches your origin.

### ☁️ Osto Cloud

The platform itself. All 13 modules run here and share a single dashboard, a single identity model, and a single log stream — so a finding in one place becomes evidence for compliance in another without you wiring anything up.

### 🏢 Your environment

The things Osto protects: your websites and APIs, your servers and databases, your cloud accounts on AWS / Azure / GCP, your source code repositories and CI, your end-user devices, and your mobile app binaries. Osto reaches in only where you grant access — read-only API for cloud posture, CI integration for code, agent-based for endpoints, and brokered access for servers.

## What each Osto Cloud module does

### Protecting traffic

* **Web App Protection** — inspects every request reaching your websites; blocks OWASP-class attacks, DDoS, and bot traffic before it lands on your origin.
* **API Protection & Discovery** — discovers shadow APIs, enforces schema, and blocks malicious calls.
* **Domain Filtering / DNS** — controls which destinations users on your network can resolve.

### Continuous assessment

* **Web Scanner** — crawls your public-facing properties for vulnerabilities on a schedule.
* **App Scanner** — tests iOS and Android binaries for mobile security issues.
* **SAST** — runs static analysis on source code in CI.
* **SBOM / SCA** — inventories dependencies and flags known CVEs.
* **Cloud Posture (CSPM)** — reads cloud provider APIs to detect misconfigurations across AWS, Azure, and GCP.

### Endpoint & access

* **Endpoint Agent** — installs on laptops and desktops. Enforces Device Control (USB, Bluetooth, Wi-Fi), App Control, Domain Filtering, DLP (App File Access), Screen Lock, and Disk Encryption.
* **Secure Server / Gateway** — brokers Zero Trust access to servers. Users connect through Osto; direct SSH/RDP to the origin is blocked. MFA is enforced per session.

### Compliance & evidence

* **Compliance Engine** — maps findings and telemetry from every module to SOC 2 Type II, ISO 27001, HIPAA, GDPR, and PCI DSS controls; collects evidence automatically.
* **Awareness Training** — delivers security training to your team and records completion as compliance evidence.
* **Logs** — centralizes Web App, Secure Server, Domain Filtering, Incident, Audit, and Auth logs across all modules into a single audit-ready stream.

## How traffic flows — Web App Protection

1. A request hits the Osto edge (your DNS A record points here).
2. TLS is terminated. Osto presents your certificate (auto-generated or uploaded).
3. The request passes through **Attack Detection** — TLS validation, protocol checks, header inspection.
4. Advanced checks run: **DDoS mitigation**, **Bot detection**, **OWASP rule set** (SQL injection, XSS, path traversal, etc.).
5. Clean traffic is forwarded to your origin over an encrypted connection. Malicious traffic is blocked (in Prevent Mode) or logged (in Detect Mode).
6. The response comes back through Osto. **Data Theft Protection** optionally inspects it for outbound sensitive-data leakage.
7. The full transaction is written to **Logs → Web App** and counted toward **Compliance** evidence.

## How access flows — Secure Server

1. A user authenticates to the Osto portal (SSO + MFA).
2. The user selects the server they want to reach. The **Server Access Policy** is evaluated.
3. If the policy permits the connection, Osto opens a brokered session (SSH, RDP, or custom port) for the duration of the configured **Session Window**.
4. The origin server is never directly reachable — its inbound firewall allows only the Osto gateway IP.
5. Session events stream to **Logs → Secure Server** as audit evidence.


# WAF Availability & Uptime
Source: https://docs.osto.one/overview/waf-availability

How Osto keeps your Web App & API Protection (WAF) layer online — our uptime target, how we measure it, the architecture behind it, and how we respond to incidents.

Osto's Web App & API Protection (WAF) sits inline, in front of every request — so its availability is your availability. Here's the uptime we target for the protection layer, how we measure it, and the architecture that keeps your site online. Backed by numbers, not adjectives.

<CardGroup>
  <Card title="99.9%" icon="wave-pulse">
    The monthly uptime we target for the Osto protection layer, measured honestly.
  </Card>

  <Card title="Inline proxy" icon="shield-halved">
    A reverse proxy that inspects every request and forwards clean traffic to your origin.
  </Card>

  <Card title="24/7" icon="satellite-dish">
    Real-time monitoring of the protection infrastructure, every minute of every day.
  </Card>

  <Card title="Before your origin" icon="ban">
    DDoS floods, bad bots, and OWASP-class attacks are filtered before they reach your origin.
  </Card>
</CardGroup>

<Info>
  **We target 99.9% monthly uptime for the Osto protection layer.** Need it in writing?
  We're happy to put a contractual SLA with service credits in your agreement — just
  [talk to us](mailto:connect@osto.one).
</Info>

## Our uptime target

We target **99.9% monthly availability** for the Osto protection layer — the reverse proxy that inspects your traffic and forwards clean requests to your origin. It's a number we stand behind and measure honestly, so you get real availability you can plan around.

Here's what different availability levels mean in concrete terms:

| Availability            | Downtime per month | Downtime per year |   |
| ----------------------- | ------------------ | ----------------- | - |
| 99%                     | \~7.2 hours        | \~3.65 days       |   |
| **99.9% — Osto target** | **\~43.8 minutes** | **\~8.8 hours**   | ✅ |
| 99.95%                  | \~21.9 minutes     | \~4.4 hours       |   |
| 99.99%                  | \~4.4 minutes      | \~52.6 minutes    |   |

<Note>
  The target covers the Osto protection layer accepting, inspecting, and forwarding your
  traffic. Your own origin's uptime is a separate layer — and Osto helps you keep that
  online too, with redundant origins and real-time health alerts (see
  [How we keep you online](#how-we-keep-you-online)).
</Note>

## How we measure uptime

A number is only as good as its method, so here's ours:

* **Window** — availability is measured per calendar month.
* **Sampling** — the protection layer is health-checked continuously, and availability is averaged across those checks over the month rather than judged on a single snapshot.
* **The formula** — `Availability = (total minutes in the month − minutes unavailable) ÷ total minutes in the month`.
* **What "unavailable" means** — a request to a healthy origin cannot be accepted, inspected, and forwarded by the Osto protection layer.
* **What we watch** — Osto continuously monitors the protection infrastructure in real time. When you're signed in, the live **All Systems Operational** indicator in the dashboard reflects that monitoring.

## What the target covers

We measure availability fairly: the target covers what Osto controls — the protection layer — and sets clear expectations so there's never a question during an incident.

| Counts toward the Osto target                                              | Sits outside it                                                                                  |
| -------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
| The protection layer accepting and forwarding requests to a healthy origin | Your **origin server** being down, overloaded, or returning errors                               |
| Osto proxying clean traffic without error                                  | **DNS** not yet pointed at Osto, or a change still propagating                                   |
| Osto's infrastructure inspecting every request                             | **Configuration** on your side (e.g. a policy or origin set incorrectly)                         |
|                                                                            | Events beyond anyone's control (**force majeure**, third-party networks)                         |
|                                                                            | **Scheduled maintenance** announced in advance (see [Planned maintenance](#planned-maintenance)) |

Osto helps you stay on top of the "outside it" column too — redundant origins and [WAF Upstream Health Alerts](#how-we-keep-you-online) catch origin problems early, and [Shared responsibility](#shared-responsibility) lays out who owns what.

## How we keep you online

The uptime target is backed by design. Every request flows through Osto as a high-performance reverse proxy that's built to keep serving traffic even when parts of the system — or your own origin — fail.

<Frame>
  <img alt="Osto reverse-proxy protection model" />
</Frame>

<CardGroup>
  <Card title="Built for redundancy" icon="sitemap">
    The protection layer runs across independent, health-checked capacity, so a fault in
    any single component reroutes automatically instead of taking your site down.
  </Card>

  <Card title="Redundant origins" icon="server">
    When you register a website you can add **two *Server IP or LB Domain* entries** — the
    second gives Osto a healthy backend to route to if the first becomes unreachable, so
    your site stays up.
  </Card>

  <Card title="Origin health alerts" icon="bell">
    **WAF Upstream Health Alerts** notify you in real time the moment an origin server goes
    down — so you know before your users do.
  </Card>

  <Card title="Always-encrypted path" icon="lock">
    Dual-layer TLS keeps both legs encrypted — user-to-Osto and Osto-to-origin. The free,
    auto-generated certificate is issued in minutes and renewed automatically before it
    expires, so certificate expiry is one less thing to worry about.
  </Card>
</CardGroup>

## Staying up under attack

For a WAF, "available" and "under attack" are the same moment — and keeping you online through an attack is exactly what the protection layer is built for.

* **DDoS Protection** is on by default, absorbing volumetric and application-layer floods before they reach your origin. For the largest, most targeted campaigns, our team works alongside you with a tailored response.
* **Bot Mitigation** blocks automated abuse — scraping, credential stuffing, and brute-force attempts — that would otherwise exhaust your origin.
* **OWASP Top 10 protection**, virtual patching, and API protection stop injection, cross-site scripting, path traversal, and schema abuse before they land.

<Tip>
  New domains can start in **Detect Mode**, which observes and logs threats without
  blocking, so you can validate traffic patterns with zero risk to availability before
  switching to **Prevent Mode**. It's the safest way to onboard a production site.
</Tip>

<Frame>
  <img alt="Osto attack detection and security flow" />
</Frame>

## Real-time monitoring & incident response

Staying available is about prevention *and* how quickly and openly we respond.

* **Continuous monitoring.** The protection infrastructure is monitored in real time, 24/7. The dashboard's **All Systems Operational** indicator reflects that live monitoring whenever you're signed in.
* **Proactive alerts.** WAF Upstream Health Alerts surface origin problems the moment they happen, and every request — allowed or blocked — is written to your **Web App Logs** for investigation.
* **Human response.** During an incident, reach the team at [connect@osto.one](mailto:connect@osto.one). Your agreement can include named response-time targets by severity.
* **Clear communication.** When an incident affects the protection layer, we tell you what happened and what we're doing about it — before you have to ask.

<Note>
  Today you can see live protection-layer status right in your dashboard, and we notify
  you directly about any incident that affects your domains. A public, independently
  hosted status page is coming soon to make that history visible outside the dashboard
  too.
</Note>

## Planned maintenance

Improvements to the protection layer are designed to ship without taking your traffic offline. When a change does need a maintenance window:

* We schedule it during low-traffic periods and announce it in advance.
* Maintenance windows announced ahead of time don't count against the uptime target.
* Provisioning and renewal of the auto-generated certificate are automated, so routine SSL work on it never needs a maintenance window or a manual step from you.

## Shared responsibility

Keeping your site online is a partnership. Drawing the line clearly means no surprises during a real incident.

| Osto keeps up                                                        | You keep up                                                                                            |
| -------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| Availability and capacity of the protection layer                    | Your **origin server**, healthy and reachable                                                          |
| Inspecting traffic and filtering DDoS, bots, and OWASP-class attacks | **DNS** pointed at Osto, with current records                                                          |
| Issuing and renewing the **auto-generated** SSL certificate          | Renewing any certificate you upload yourself, and valid **policy and origin configuration** per domain |
| Monitoring the infrastructure and alerting you to origin health      | Acting on **WAF Upstream Health Alerts** and log findings                                              |

<Tip>
  Two quick wins for your own resilience: add a **second origin** when you register a
  website, and keep a **low DNS TTL** (around 600 seconds) so failover and routing changes
  take effect quickly.
</Tip>

## Availability FAQ

<AccordionGroup>
  <Accordion title="Is the Osto WAF a single point of failure for my site?">
    No. The protection layer runs across redundant, health-checked capacity, so a fault in
    a single component reroutes rather than taking your site down. On your side, register a
    **second *Server IP or LB Domain*** so Osto always has a healthy backend to route to,
    and turn on **WAF Upstream Health Alerts** to be notified the moment an origin goes
    unhealthy. Have specific failover requirements for a domain?
    [Contact us](mailto:connect@osto.one) and we'll tailor them to your setup.
  </Accordion>

  <Accordion title="What happens if my origin server goes down?">
    Osto has you covered on both sides: add a second origin for high availability so Osto
    can route around a failed backend, and **WAF Upstream Health Alerts** notify you in
    real time so you can respond before users are affected.
  </Accordion>

  <Accordion title="Can I get a contractual SLA with service credits?">
    Yes. 99.9% is our standing operational target, and when you need it in writing we'll
    put a contractual SLA with service credits in your agreement. Where a documented SLA
    applies, its terms are the source of truth. [Talk to us](mailto:connect@osto.one) for
    terms.
  </Accordion>

  <Accordion title="Does downtime caused by a DDoS attack count against me?">
    No — keeping you online through an attack is exactly what the protection layer is for.
    DDoS Protection is on by default and filters floods before they reach your origin, and
    for the most targeted campaigns our team works with you directly.
  </Accordion>

  <Accordion title="How do I get started with a formal SLA?">
    Reach out at [connect@osto.one](mailto:connect@osto.one). We'll walk through the SLA
    terms, service credits, and support response targets available for your plan and put
    them in your agreement.
  </Accordion>
</AccordionGroup>

## Independently audited controls

Osto runs on the same platform we sell, and that platform's security and operational controls are independently audited — **SOC 2 Type II** and **ISO 27001** certified. These attest to how we build and run the service; reports are available to prospects and customers on request.

## Related

<CardGroup>
  <Card title="What is Web App Protection" icon="shield-check" href="/overview/what-is-web-app-protection">
    How the reverse-proxy protection model safeguards your applications and APIs.
  </Card>

  <Card title="Managing Websites" icon="globe" href="/how-to-guides/asset-management/managing-websites">
    Register a domain, add redundant origins, and choose Detect or Prevent mode.
  </Card>

  <Card title="Web App Logs" icon="list-check" href="/how-to-guides/logs/web-app-logs">
    Review threats, access, and policy violations for your protected domains.
  </Card>
</CardGroup>

***

<sub>Last updated: 2 July 2026. This page describes Osto's operational availability target and architecture for the Web App & API Protection layer. Where your agreement includes a documented SLA, that agreement's terms govern.</sub>


# What is Web Application Protection
Source: https://docs.osto.one/overview/what-is-web-app-protection

How Osto's reverse-proxy protection model safeguards your web applications and APIs.

Osto provides the Web App & API Protection Module, designed to safeguard web applications and APIs from a wide range of attack vectors and security exploits. This module delivers essential protection by examining and controlling HTTP/HTTPS traffic between applications and the internet, defending against threats such as DDoS attacks, malicious bots, and OWASP-identified vulnerabilities.

<img alt="How it works" />

Deploying the Osto Web App & API Protection Module in front of a web application creates a protective barrier between the application and internet traffic. Unlike a standard proxy server that simply masks client identity, the Osto module functions as a reverse-proxy system, shielding servers from direct exposure by requiring all client requests to pass through it before reaching the application.

## SSL Certificate Management

Osto provides a free SSL certificate for encrypting traffic between users and the Osto service. Your original SSL certificate remains on your server unchanged, maintaining encryption between Osto and your backend. This creates dual-layer encryption — users connect securely to Osto, and Osto connects securely to your server.

The setup requires no changes to your existing SSL configuration while providing automatic certificate management for the public-facing connection. All traffic remains encrypted end-to-end through both certificate layers.

<img alt="SSL dual-layer encryption diagram" />

## Attack Detection and Security Flow

All incoming HTTPS requests first go through Attack Detection, which checks all the essential protocols. Valid requests with no suspicious patterns are forwarded to your origin server. Invalid or suspicious requests are blocked and rejected.

Requests that pass initial checks but contain potential threats go through advanced Security Checks for DDoS protection, bot mitigation, and OWASP Top 10 vulnerability detection. When malicious patterns like SQL injection are detected, the request is blocked before reaching your server, ensuring only clean traffic gets through.

<img alt="Attack Detection and Security Flow" />

## API Protection

API Protection ensures only legitimate traffic reaches your origin servers. Each HTTP/S request is subjected to advanced security checks. Valid requests are allowed after passing all validations, while malicious ones — such as SQL injection or other pattern-based attacks — are blocked.

The system includes high-level monitoring of application/json APIs to detect anomalies, abuse, or misuse in real time. This layered defense protects APIs, ensures reliability, and prevents backend compromise.

<img alt="API Protection" />

## AI Web Vulnerability Scanning

Osto's AI-powered web scanner automatically analyzes your website security and provides a comprehensive security score to assess your overall protection level. The intelligent system scans all your domains using machine learning algorithms to categorize discovered vulnerabilities by severity and help you prioritize critical fixes first.

It identifies the most frequently targeted areas of your website and generates detailed reports showing exactly where vulnerabilities exist. The AI scanner runs on configurable schedules and provides specific remediation guidance for each discovered issue.

<img alt="AI Web Vulnerability Scanning" />

## How Requests Are Processed

The Osto Web App & API Protection Module operates as a high-performance reverse-proxy in front of your applications. Every incoming request flows through Osto's protection engine, which applies security rules and filters malicious traffic. Clean requests are forwarded to your origin servers; malicious requests are blocked at the protection layer before they ever reach you.

<img alt="Request processing architecture" />

<img alt="Request processing flow detail" />

## Learn More

To discover what other security solutions Osto provides, contact us at [connect@osto.one](mailto:connect@osto.one).


# Release Notes
Source: https://docs.osto.one/release-notes

Latest updates and improvements to the Osto platform.

## Version 9.3.1.0

*August 19, 2026*

* **Container Image Scanning:** Code Security now scans container images alongside your source code, reporting vulnerable operating-system packages and application dependencies in the layers you actually ship. The image you deploy is assessed on the same terms as the repository it was built from.
* **Expanded Application Control Signatures:** 386 new application signatures across Windows, Linux, and macOS, covering development tools, AI assistant clients, cloud storage, video conferencing, social media, remote access, email clients, and office and productivity software — so App Control policies recognize far more of what your teams actually run.
* **ISO 27001 and HIPAA Alongside SOC 2:** Compliance now runs several frameworks at once. **ISO 27001** is laid out the way an auditor expects it — the management-system clauses grouped as parent sections, with the Annex A control set kept separate — and **HIPAA** arrives organized by its administrative, physical, and technical safeguards. Activate a framework and its full requirement and control library loads, with starter policy templates pre-loaded so you are not writing from a blank page.
* **Shared Controls Across Frameworks:** Every control carries a badge for each framework it satisfies, and tasks can be filtered by framework. A control that serves SOC 2 and ISO 27001 both is satisfied once and counted in both places, so adding a second framework is a fraction of the work of the first rather than a parallel program.
* **Risk Register:** Compliance now includes a formal risk register, shared across every framework you run. Record a risk with its description, category, and owner; rate it for likelihood and impact to get an inherent score; choose a treatment — mitigate, accept, transfer, or avoid; then link the controls that address it and re-rate to a residual score. Risks track to closure and export with the rest of your evidence, so a single register answers the risk-assessment requirement in SOC 2, ISO 27001, and HIPAA alike instead of being rebuilt for each audit.
* **Immediate Domain Filtering Enforcement:** A change to a domain filtering policy now reaches managed devices as you save it, so a category you block or allow takes effect across the fleet right away rather than at the next check-in.
* **Time-Zone-Aware Endpoint Scheduling:** Scheduled endpoint and domain filtering policies now follow each device's own local time zone, detected automatically from the device. A working-hours policy applies during the user's working hours, wherever they are.

### Enhancements

**Endpoint Security**

* **Single Linux Build:** One agent build now covers Ubuntu 22, 24, and 26, so rolling the agent out across a mixed Linux fleet is a single package rather than one per release.
* **Redesigned macOS Installation:** The macOS installer presents every setting on a single screen, and the provisioning profile and related system settings are applied as part of the same flow.
* **Protection in Safe Mode:** Endpoint protection stays active when a device boots into safe or minimal mode, including with network support, so a restart into safe mode is no longer a gap in coverage.
* **Clear Unsupported-Version Messaging:** Linux and macOS devices running an operating system version outside the supported range now report that state explicitly, so an unprotected device is visible in your fleet rather than silently absent.
* **Standardized Notifications:** Endpoint notifications share one format and tone across Windows, Linux, and macOS.

**Threat Intelligence**

* **Expanded Threat Feed:** Domain filtering draws on a broadened threat intelligence feed combining reputation and geolocation sources, which also powers automatic device time-zone detection.

**Code Security**

* **Branch-Level Findings and Reports:** Findings and generated reports can be scoped to a specific branch, so a feature branch is assessed on its own rather than against your default branch.

<Info>
  Compliance now covers **SOC 2 Type II, ISO 27001, and HIPAA**, with a risk register alongside them — and **Container Image Scanning** extends Code Security from source to shipped artifact, so the same finding, severity, and risk model covers your images as well as your repositories.
</Info>

***

## Version 9.3.0.1

*August 4, 2026*

* **Dormant Administrator Detection:** Administrator accounts with no sign-in for 90 days are flagged automatically on the Administrators list, so privileged access nobody is using surfaces in your access review instead of persisting unnoticed. A flagged account can be disabled from the same list.
* **Provider-Scoped Posture Reports:** A posture report can now be scoped to an entire cloud provider — every connected AWS, Azure, or Google Cloud account in one export — as well as to a single account or across your whole estate. Each report covers connected accounts, discovered assets, open findings, and the severity breakdown, as a readable report or a spreadsheet, so a request for evidence on one provider does not mean handing over the others.

### Enhancements

**Cloud Security**

* **Cloud Account Removal Clears Its Findings:** Removing a cloud account clears its inventory and findings with it, so your open-findings count reflects the accounts you actually run. Export that account's posture report before you remove it if you need to retain the evidence.
* **Attributable Cloud Audit Entries:** Cloud audit entries now carry the account name and the provider — AWS, Azure, or Google Cloud — as columns in the audit trail, so a configuration change is attributable to the account it was made in without resolving an account identifier against the inventory first.

**Endpoint Security**

* **Application Control Priority on Block Rules:** Application control rules now show their evaluation priority for block rules as well as allow rules, so where an allow rule and a block rule cover the same application you can confirm which one wins before the policy reaches your fleet.
* **Updated Classification Definitions:** The current application, file, and device classification definition set extends coverage to recently released collaboration and AI assistant clients, further installer and archive file types, and additional removable-media and peripheral device classes. Adoption stays under your control — check your classification settings to confirm your organization is running the current set — and classifications you wrote yourself are never overwritten.

### Security Updates

* **Verified-Domain Single Sign-On:** Single sign-on is restricted to your organization's own verified domain, so only identities in that domain can authenticate into your organization. Administrators you invite directly are unaffected.
* **Immediate Session Invalidation:** Signing out invalidates that session immediately, and each device session holds its own token, so ending a session on one device leaves your other devices untouched.

<Info>
  **Endpoint Detection & Response** and a dedicated **Identity & Access Management** module are both in active development and coming soon.
</Info>

***

## Version 9.3.0.0

*July 30, 2026*

* **Insights Rebuilt as Security Analytics:** Insights now carries more than thirty views across web attack, DNS, endpoint, identity, certificate, and configuration data. New views cover attack volume and attack origin over time, the most-targeted URLs and paths on your protected sites, DNS query volume split by allowed and blocked, top web categories, riskiest users, endpoint operating-system mix, multi-factor adoption, control pass rate, certificate expiry, and configuration-change activity by module — web protection, endpoint, and cloud.
* **API Schema Validation:** Upload an OpenAPI definition for a protected API and Osto enforces it at the edge. Requests that violate the declared paths, methods, parameter types, or required fields are rejected before they reach your service, and the API inventory flags any endpoint serving traffic outside the schema you published for it.
* **Custom Protection Rules:** Write your own detection rules against request paths, parameters, headers, cookies, and body content; choose block, log, or challenge; and order them against the managed ruleset. An attack pattern specific to your application is covered on your own timetable rather than on a signature release cycle.
* **Log Forwarding to Your SIEM:** Stream web protection, domain filtering, endpoint, secure server access, and audit events to your own SIEM or log platform, choosing the event types and minimum severity you forward. Osto remains your control plane while your existing detection pipeline keeps a complete picture.
* **Newly Seen API Paths:** The API inventory introduced in 9.1.2.0 now separates paths seen for the first time in the last seven days from those it has been tracking, so an endpoint that appeared this week is something you are shown rather than something you go looking for.
* **Deny Rules Refuse the Connection Outright:** A secure server access rule set to deny refuses the connection outright, and the attempt is recorded in your logs as a policy denial. A denial is attributable to the rule that made it, so an access review reads your policy decisions directly.
* **Cookie Security Exemptions:** You can now name specific cookies to exclude from cookie-security enforcement, so third-party or legacy cookies that must keep their original attributes keep working while every other cookie on the site stays hardened. Exemptions are written per site in the advanced policy editor and listed with the rest of that site's policy, so a deliberate exception stays visible rather than becoming an unexplained gap.

### Enhancements

* **Certificate Validation Before a Site Goes Live:** Duplicate and expired certificates are flagged before you attach one to a site, so a site does not go live behind a certificate that is already invalid.

<Info>
  With **API schema validation**, **custom protection rules**, and **log forwarding**, this release closes the loop: Osto enforces what your APIs declare, lets you write the rules only you could write, and hands every event to the pipeline you already run.
</Info>

***

## Version 9.2.2.0

*June 30, 2026*

* **Expanded Cloud Posture Check Coverage:** Twenty-six new posture checks across AWS, Azure, and Google Cloud: over-permissive roles, access keys past their rotation age, and unused privileged identities; storage containers, database endpoints, and network rules reachable from the internet; and unencrypted volumes, snapshots, and managed database instances. The new checks are evaluated on your next scheduled scan and appear in your findings and posture reports alongside the rest.
* **Expanded Data Classification Patterns:** The classification library behind data loss prevention gained new built-in patterns — payment card and bank account numbers, national and tax identifiers across additional regions, health record identifiers, and credentials such as private keys and provider access tokens carried in files. Any App File Access policy already scoped to a classification picks up the wider coverage without an edit.
* **Device Posture Checks Before Access:** A secure server access policy can now require the connecting device to meet your endpoint standard — agent present, disk encryption enabled, screen lock enforced — before a session is established, so an access decision accounts for the state of the machine and not only the identity behind it.
* **On-Demand Cloud Posture Scans:** Re-scan a connected cloud account whenever you need with a *Scan now* action rather than waiting for the next scheduled run, so you can confirm a misconfiguration is genuinely closed at the moment you remediate it.
* **Configurable Origin Response Timeout per Website:** Set how long Osto waits for your origin to respond, per protected website, from that website's settings, and lift the limit entirely for long-running endpoints. A report builder, a bulk export, or any other slow path stays behind full inspection while it runs.

### Enhancements

* **Access Logs at Full Traffic Volume:** Access log paging and export return the complete record set at any traffic volume, so an export doing evidentiary work — an incident timeline, or the sample an auditor asked for — carries every matching record.
* **Google Cloud Connection Diagnostics:** A failed Google Cloud connection names the exact permission or service to enable, and the connection test succeeds for projects that run no compute instances, so a project built on storage, functions, or managed databases can be brought under posture scanning.

<Info>
  Access decisions now weigh the **device** as well as the identity — an unencrypted or unmanaged machine can be kept out of your infrastructure even when the credentials are perfectly valid.
</Info>

***

## Version 9.2.1.1

*May 29, 2026*

* **One-Click Bypass Rules for False Positives:** When a legitimate request is blocked, click Bypass directly on that log entry and Osto writes a precise exception — for that one rule, on that one URL, query-string or request-body parameter, header, cookie, or source address, and for that origin alone. Every bypass rule is listed, reviewable, and removable, so a tuning decision made months ago is still visible to whoever reviews your policy next. Policy exceptions written under 9.2.0.0 keep working alongside them; review yours and retire any that a narrower bypass rule now covers.
* **Account-Wide Bot and Denial-of-Service Protection:** Bot and denial-of-service protection are now set once for your whole account rather than site by site, so your posture is uniform across every protected site and a site you add tomorrow inherits it rather than starting from its own configuration.
* **Time-Based Policy Windows:** Application control and data protection policies can now be scoped to a date range and to specific days and times of the week, so a control applies during working hours, a contractor engagement, or a change freeze rather than permanently.

### Enhancements

* **Path Rewrite and Per-Rule Protection for Routing Rules:** Custom routing rules can now rewrite the request path before it reaches your origin, and each rule carries its own web protection switch — so you can exempt a single callback route from inspection without loosening the policy covering the rest of the domain.
* **Screen Lock and Disk Encryption in One Device Policy:** Automatic screen lock and enforced full-disk encryption are set together in a single device policy per user group, so the two controls cannot drift apart across the same set of devices.
* **End-to-End Request Tracing in Web Protection Logs:** Web protection logs now carry the client user agent, request identifier, connection scheme, and rule tags — enough to follow a single request from the edge to the control that acted on it, and to line it up against your own application logs.
* **Protection Mode and Policy Changes in the Audit Trail:** The audit trail now records protection mode switches with their before and after values, user group membership changes, and device policy edits, so any change in enforcement posture is attributable to a person and a time.

***

## Version 9.2.1.0

*May 4, 2026*

**Code Security**

* **Repository, Dependency, Secret, and Infrastructure Scanning:** Connect a GitHub, GitLab, or Bitbucket account — cloud or self-hosted — and Osto scans every repository for insecure code, vulnerable open-source dependencies, hard-coded secrets in both working code and commit history, and misconfigured infrastructure definitions. Browse findings by repository, branch, language, and severity.
* **Software Bill of Materials per Repository:** Every scanned repository produces a bill of materials listing the open-source components you ship and the license attached to each, so a license question or a newly disclosed component vulnerability is answered by lookup rather than by investigation.
* **Osto Risk Score:** Every finding carries a single 0-100 value that blends technical severity with real-world exploit likelihood, whether the flaw appears on the public catalog of actively exploited vulnerabilities, and whether the vulnerable code is reachable from your running application. A list of a thousand alerts collapses to the few dozen that warrant action.
* **Scanning Inside the Development Workflow:** Scans run on every push and on every pull request, commenting inline on the exact changed lines. Results are split into new, pre-existing, and fixed against the merge target, so a pull request is judged only on what it introduces. Scheduled scans cover everything else, with findings emailed to the recipients you name.
* **Triage with Expiring Suppressions:** Mute a finding or accept a false positive against an expiry date, so nothing is dismissed permanently by accident and every suppression returns for review.
* **Validated Secret Findings:** A detected secret is verified against the service it belongs to, so a finding tells you whether the credential is still live and needs rotating today or was already revoked — the difference between an incident and a backlog item.

**Compliance Automation**

* **SOC 2 with Automated Evidence Collection:** Enable SOC 2 and Osto builds the program — the full control library, a task list with owners and due dates, and a readiness dashboard showing which requirements are satisfied, partially satisfied, or outstanding. Evidence is drawn continuously from the rest of your Osto estate: web application protection, data loss prevention, domain filtering, endpoint device policy, cloud posture, sign-in records, and audit trails. Control status therefore reflects your live configuration rather than a screenshot taken once. You can still upload your own evidence, add custom controls, and create your own tasks.
* **Policy Library with Enforced Approval Separation:** More than twenty ready-written policies cover the ground auditors ask about, including information security, access control, incident response, and vendor management. Each is pre-filled with your company details, editable in the browser, and versioned with a change summary. Every policy routes through a formal approval step in which an author cannot approve their own document, then publishes as a branded PDF and goes out to staff for acknowledgment.
* **Security Awareness Training with Recurring Assignment:** Build training programs from reusable modules with knowledge-check quizzes and assign them to individuals or groups. Osto re-assigns a program automatically before the previous completion expires, so coverage never lapses unnoticed. Acknowledgment and completion records feed your compliance evidence directly.

**Endpoint Security**

* **Enforced Full-Disk Encryption with Recovery Credentials:** Require full-disk encryption on managed devices as part of a device policy. Recovery credentials are made available to the administrators you nominate, so an encrypted machine is always recoverable by someone named in advance.
* **Software Inventory Across Managed Devices:** Managed devices report the applications installed on them — publisher, version, architecture, install date, and signature status — and the inventory refreshes as software is installed or removed. It is searchable and filterable, so "which of our machines still run that version" has an answer during an incident rather than after one.

### Enhancements

**Web Protection**

* **Scheduled Security Reports:** Osto sends your administrators a recurring web protection summary as an HTML or PDF attachment covering request volumes, top threats broken down by severity, policy violations, and how the period compares with the one before it. Choose the reporting window and the severities you want included.

<Info>
  Two new modules land together: **Code Security**, which secures your codebase before it ships, and **Compliance Automation**, which turns SOC 2 from a screenshot exercise into evidence your platform collects for you.
</Info>

***

## Version 9.2.0.0

*April 21, 2026*

* **Rebuilt Web Application Threat Detection Engine:** The engine that inspects traffic to your protected domains has been rebuilt, with a refreshed detection ruleset covering SQL and command injection, cross-site scripting, path traversal, request smuggling, and insecure deserialization. Set it to Blocking or Detection-Only, choose how much audit detail each match records, and apply that choice globally or to an individual origin. Mode and ruleset changes take effect without dropping traffic.
* **False-Positive Tuning with Policy Exceptions:** When a legitimate request is blocked, raise the matching exception in one step directly from the traffic log. Exceptions can also be written by hand against a URL, a query-string or request-body parameter, a header, a cookie, or a source address, each with accept, skip, or drop behavior, and an existing exception can be edited in place rather than deleted and recreated.
* **App File Access Data Loss Prevention:** A new policy type controls which applications may — or may not — open which classes of files on managed devices. Pick the file classifications, pick the application groups, choose block or allow, and apply the rule to individual people or whole groups, optionally limited to a schedule. Osto ships ready-made classifications and you can add your own.
* **Custom Routing Rules for Protected Domains:** Shape traffic per domain without touching your own infrastructure. Match requests by path prefix, exact path, or pattern; route them to a chosen backend or issue a redirect with the status code you want; rewrite the host or path; force HTTPS; and order rules by priority. A rule can also exclude its route from threat inspection where an origin requires requests to arrive unmodified.
* **AI Security Questionnaires:** Upload a customer or vendor security questionnaire, or paste it in as text, and Osto drafts each answer from your own published policies and your declared security stack. Edit any answer, regenerate it with extra context, mark it reviewed, and export the completed questionnaire.

### Enhancements

* **Individually Switchable Advanced Protections:** Sensitive-data leak prevention, response cloaking, parameter protection, and cookie security can each be turned on or off per domain from the Advanced Policy page, so a domain that needs one of them relaxed does not lose the other three.
* **Dedicated Rate Limiting:** Rate limiting is now separate from general request limits, so you can hold a strict request rate without also constraining request size, and tune the two against different thresholds.
* **Status Code, Rule Tag, and Matched Sample in Every Log:** Traffic, error, and policy violation logs gained status code, rule tag, and matched-sample columns, and log filters now support contains and contains-any matching — so you can pull back every request that tripped one named rule.
* **Global Device Policy:** Device-wide settings are managed from a single Global Policy page, starting with enforced automatic screen lock, applied to individuals or user groups with per-group overrides.

<Info>
  **Detection-Only** mode is the safe way to trial the new threat detection engine — every request is evaluated and everything that would have been blocked is recorded, without affecting live traffic.
</Info>

***

## Version 9.1.2.4

*March 19, 2026*

* **Access Revocation Reaches Live Sessions:** A change to your secure server access rules — including removing a person and removing a server — is pushed to connected clients as you make it, so it reaches sessions that are already open. When you cut someone off during an offboarding or pull a server out mid-incident, the change applies to live connections.
* **Versioned Classification Definitions You Choose to Adopt:** The built-in file, application, and device classifications behind data loss prevention, application control, and device control are now versioned. You can see whether your organization is running the current definition set, choose when to adopt a new one rather than having it applied to your fleet unannounced, and rely on any classification you wrote yourself never being overwritten by an update. New organizations start on the current version.
* **Certificate Renewal Alerts and Standalone Upload:** You are now emailed on both outcomes — when a certificate renews and when a renewal fails — so a lapse is something you are told about rather than something your users discover. You can also upload a certificate on its own without attaching it to a site first: Osto reads the covered domain out of the certificate itself, so a certificate is filed against the domain it actually covers rather than the one someone typed.

### Enhancements

* **Refreshed Web Protection Rulesets:** The detection rulesets behind web application and API protection were updated with current signatures for request smuggling and desync, server-side template injection, insecure deserialization, and server-side request forgery.
* **DNS Settings Delivered to Linux Endpoints:** Linux clients now receive their DNS settings as part of connecting, so private service names resolve and your domain filtering policy applies from the moment the tunnel comes up, instead of depending on how the machine happens to be configured locally.

### Security Updates

* **Least-Privilege Read-Only Administrators:** Administrators holding a read-only role are shown only the actions that role permits, so an access review of your read-only administrators reflects real capability rather than what the console offers.

***

## Version 9.1.2.3

*March 5, 2026*

* **Cloud Posture Reporting and Grouped Findings:** Export your cloud posture as a formatted report or a spreadsheet covering connected accounts, discovered assets, open findings, and a breakdown by severity — for your whole estate or scoped to a single cloud account, so you can hand an auditor or an account owner exactly the scope they asked for. Findings can now be grouped by severity, cloud account, service, or check rather than read as one flat list, and each connected account reports live scan progress. A scan that cannot complete states why — expired credentials, missing permissions — so a gap in coverage is never mistaken for a clean result.
* **Scheduled Web Vulnerability Scanning:** Web application scanning now runs on a cadence you set — daily, weekly, or monthly — alongside on-demand scans, so an internet-facing application is re-tested on a fixed schedule rather than whenever someone remembers to start one. The dashboard follows each scan through its real states — not started, in progress, completed, report ready — so a completed scan is never mistaken for a stalled one.
* **Authenticated Web Scanning:** A scan can now sign in to your application before it tests, using credentials or a session you supply, so the pages behind your login — where the business logic and the sensitive data actually live — are covered rather than stopping at the front door.
* **Reusable Scan Profiles:** Save a scan configuration as a profile — scope, crawl depth, excluded paths, and credentials — and apply it to any site, so every application in a class is tested the same way every time.

### Enhancements

* **Expanded Web and App Scanner Checks:** Forty new scanner checks, including weak TLS versions and cipher configuration, missing Content-Security-Policy and HSTS response headers, session fixation, insecure direct object reference, and server-side request forgery.
* **Bypass Rules Across Multiple Posture Checks:** A single posture bypass rule can now cover several checks at once, so a documented exception that spans a group of related checks is written and reviewed as one rule rather than repeated per check.
* **Audit Coverage for Administrative and Access Changes:** The audit trail now records administrative and access-control changes with a before-and-after snapshot of exactly what changed, so a review shows the previous value beside the new one instead of recording only that something was edited. Log columns have also been standardized across views, so the same field means the same thing on every page and a filter expression you build on one log carries to the next.

<Info>
  An unauthenticated scan tests your front door. **Authenticated scanning** tests the rooms behind it — where your business logic and your customer data actually are.
</Info>

***

## Version 9.1.2.2

*February 25, 2026*

* **Bypass Rules for Cloud Posture Checks:** Cloud posture results can now be tuned to your environment. A bypass rule marks an individual finding — or an entire check, everywhere it applies — as passed, skipped, or failed, with the reason recorded against it. Accepted risks and known exceptions stop resurfacing on every scan, the recorded reason makes each exception reviewable later rather than a decision someone has to recall, and what remains in your findings list is what still needs action.

### Enhancements

* **Classification Changes Reach Devices on the Next Check-In:** A new or changed application or file classification now reaches managed devices on their next agent check-in rather than waiting for a rebuild, so a control you publish is enforced across the fleet the same day you write it.
* **Log Times Normalized on Ingest:** Event times from the audit trail, authentication, device control, secure server, domain filtering, and web protection logs are normalized to a single format as they arrive, so an incident timeline assembled from several log types lines up rather than drifting between them, and sorting, filtering, and cross-referencing agree across views.
* **CIS Benchmark Mapping on Posture Checks:** Every cloud posture check now carries the CIS Benchmark control it maps to, so a finding is traceable to the published benchmark behind it and your posture results speak the language your auditors already recognize.
* **Granular Removable Media and Peripheral Control:** Device control now treats removable storage, mobile devices, and imaging and printing peripherals as separate classes, so you can block mass storage outright while leaving the peripherals your teams work with connected.

***

## Version 9.1.2.1

*January 22, 2026*

* **Bot and Denial-of-Service Rule Library:** The full rule library behind bot and denial-of-service protection is now visible in the dashboard, organized into named categories such as slow-connection attacks, content-management resource exhaustion, fake search-engine crawlers, and credential-stuffing bots. Open any rule to read what it matches and how often it has fired, and switch protection on or off at category, group, or individual rule level. A single rule can be put into log-only mode so it keeps reporting while everything around it keeps blocking.
* **True Client Address in Logs and Policy Matching:** Web protection records and matches on the originating client address, so country blocking, rate limiting, and source-address exceptions evaluate the address a request came from even when it arrives through a load balancer or upstream proxy, and your logs attribute traffic to the client itself.
* **Origin Load Balancing, Health Checks, and Re-Encryption:** Put several origin servers behind a protected domain and distribute traffic across them by round-robin, least-connections, or hash, with per-server weights, connection limits, and timeouts. Origins that fail their health check are taken out of rotation automatically and returned when they recover, and traffic from Osto to your origin is re-encrypted using only the TLS versions you allow.

### Enhancements

* **Deeper Fields in Web Protection Logs:** Policy violation logs now carry the incident type, the request method, and the request headers, so you can reconstruct exactly which control fired and on what request. Access logs carry the client user agent alongside them.
* **Log Search Operators:** Log search now supports contains, does-not-contain, starts-with, ends-with, in, not-in, and between, with grouping and sorting across far more fields than before, so you can isolate a single source address, path, or rule tag without exporting the log first. A dedicated error log view has also been added.
* **Timestamps in Your Own Time Zone:** Every log timestamp displays in your own time zone, down to the second, so a web protection incident, an endpoint event, and an audit entry line up on a single timeline when you reconstruct what happened.

***

## Version 9.1.2.0

*January 6, 2026*

* **A Complete, Editable Protection Policy Set for Every Site:** Every protected site now carries the full policy set, and each control is created, edited, and deleted per site from the dashboard rather than raised as a request: country-based blocking, sensitive-data leak prevention, error-page cloaking, JSON payload limits, request parameter validation, URL and file-upload protection with cross-site request forgery and evasion detection, cookie hardening, and request rate and size limits. Bot and denial-of-service protection are on from the moment a site goes live.
* **API Discovery and Inventory:** Osto now catalogs every API endpoint called across your protected sites without you declaring any of them, recording host, method, path, client address and country, response and origin timings, payload sizes, content type, and user agent across JSON, XML, and Protocol Buffers traffic. This is how you find the APIs nobody documented — forgotten test routes, versions you believed were retired, and paths that never reached your inventory.
* **Automatic TLS Certificate Issuance and Installation:** A trusted certificate is obtained and installed for every protected domain automatically, covering both the root domain and its www form, and renewed on its own so a lapse can never come down to a missed calendar entry. If you have your own certificate, you can supply it instead.
* **Secure Server Access Provisioning and Access Rules:** Secure Server Access is provisioned with private addressing, encrypted tunnels to your infrastructure, and firewall rules generated from your access model. Every organization starts with a library of common service definitions and a default access rule, and the rule set is regenerated whenever users are added or removed, so access follows your user list instead of drifting away from it.
* **Endpoint Protection Baselines and Their Catalogs:** Endpoint threat protection, application control, and device control each start from a working baseline policy, backed by the application catalog and device catalog they match against and an always-on schedule. Policies apply to individual people or whole user groups.
* **Industry-Aligned Domain Filtering:** Domain filtering starts with the site categories most organizations in your industry block already selected and enforced on managed devices — malware, phishing, anonymizers, adult content, and gambling among them — so browsing is filtered from the first day. Categories can be added or removed at any time, and the change applies to every policy that references them.
* **Data Residency:** Choose where your protection runs and where its data is processed and stored — India (Mumbai) or United States (Virginia), or both. Your web protection and server-access protection are provisioned only into the regions you pick, so you can answer the residency question your auditors and your own customers ask.

***

## Version 9.1.1.9

*December 18, 2025*

* **Updated Web Protection Rulesets:** The detection rulesets behind web application and API protection were refreshed with current signatures for SQL and command injection, cross-site scripting, path traversal, automated scanning, and credential-stuffing traffic. The refresh reaches every protected site without any policy change on your side.
* **Rapid Coverage for Newly Disclosed Vulnerabilities:** When a widely exploited vulnerability is disclosed against a common web framework or component, a matching signature is published to the managed ruleset and applied across every protected site, so your applications are covered at the edge while you schedule your own patching window.
* **Refreshed Web Scanner Checks:** Scanner check definitions were updated alongside the protection rulesets, so a scheduled scan tests for the same newly disclosed issues your protection is already blocking.
* **Expanded Endpoint Classification Definitions:** Endpoint agents received updated application, device, and file classification definitions across Windows and macOS. Coverage now extends to recently released business and collaboration applications, additional archive and container file types, and further removable-media device classes, so application control, device control, and file-based data loss prevention rules match what your people actually install and plug in.
* **Expanded Domain and URL Category Intelligence:** The domain and URL categorization catalog gained newly classified domains and subdomains, extending category coverage into newly registered and recently active sites. The new classifications feed straight into the domain filtering policies you already have in place.

***

## Version 9.1.1.8

*December 1, 2025*

* **Cloud Security (GCP Support):** Posture Management now includes full Google Cloud Platform coverage with automated periodic discovery of key GCP services, enriched cloud asset metadata, and built-in security checks to detect misconfigurations across supported GCP resources.
* **Multi-Cloud Posture Visibility:** The Cloud Security module now offers unified visibility and posture evaluations across Azure, AWS, and GCP projects, enabling complete multi-cloud analysis in a single consolidated inventory.

### Enhancements

**Cloud Security Experience**

* **Visual Refinements:** The Cloud Security interface has been updated with a cleaner layout that improves clarity and creates a more consistent multi-cloud viewing experience.

<Info>
  With this release, the **Cloud Security** module now supports **Azure, AWS, and GCP** — enabling complete visibility and posture analysis across all major cloud providers.
</Info>

***

## Version 9.1.1.7

*November 25, 2025*

* **Cloud Security (AWS):** Full support for AWS environments with automated periodic discovery of key resource types, including EC2, EBS, VPCs, Subnets, Security Groups, S3 Buckets, RDS Instances, IAM Identities, Lambda Functions, EKS Clusters, and more.
* **Comprehensive Asset Inventory:** Includes enriched configuration, networking, identity, and encryption metadata for complete visibility across all discovered AWS assets.
* **Built-in Security Checks:** Get automatic findings for misconfigurations, exposure risks, and security-critical issues, enabling quick detection and faster remediation.

<Info>
  We are now supporting AWS along with Microsoft Azure, with GCP coming soon.
</Info>

***

## Version 9.1.1.6

*November 19, 2025*

* **Posture Management:** New capability to continuously discover, map, and monitor your infrastructure's security posture.
* **Cloud Security (Azure):** Full support for Microsoft Azure with automated periodic discovery of 35+ resource types, including VMs, Disks, NSGs, VNets/Subnets, SQL Servers, Cosmos DB, Storage Accounts, Key Vaults, App Services, Functions, and AKS clusters.
* **Comprehensive Asset Inventory:** Includes configuration, networking, identity, and encryption metadata for complete visibility.
* **Actionable Security Insights:** Get findings and step-by-step remediation guidance powered by near real-time posture evaluation.

<Info>
  Support for **AWS and GCP** is already in development and coming soon.
</Info>

***

## Version 9.1.1.5

*October 31, 2025*

* **Audit Logs:** Gain deeper visibility into administrative activities with enhanced tracking of all changes and actions, providing stronger transparency and compliance oversight.
* **WAF Custom Domain Proxy Support:** Seamlessly connect your static sites (like Bettermode or GitBook) to your custom domain with a one-step proxy setup and automatic SSL management.
* **WAF Upstream Health Alerts:** Stay informed with real-time alerts when upstream servers go down — ensuring you're informed immediately and can act before your users notice.

### Enhancements

* **Web Vulnerability Scanner Performance Upgrade:** Our AI-assisted Web Scanner has been optimized for higher performance — offering 2x faster scan execution, improved detection accuracy, and smoother reporting.
* **User Policy Toggle:** Policies can now be easily toggled between individual users and user groups, streamlining policy management and reducing administrative effort.
* **WhatsApp Notifications for Agent Installation:** Users will now receive WhatsApp alerts when they are added or reminded for agent installation, ensuring seamless setup and onboarding awareness.
* **Enhanced Block Page Design:** The domain filtering block page has been visually refined for a cleaner look and improved user experience.

***

## Version 9.1.1.4

*September 26, 2025*

* **Agent Install Message Copy Option:** A new option on the *Users* page allows admins to easily copy installation messages, which can then be shared on their official communication platforms to ensure smooth agent deployment across the organization. Multiple pre-built message templates are also available for added convenience.

### Enhancements

* **Authentication Logs:** Improved authentication log tracking with richer details and better visibility, helping admins monitor login activity more effectively.
* **Cloaking Pages:** Added new cloaking page templates to strengthen web app protection, making it easier to mask sensitive details and reduce exposure during reconnaissance attempts.

***

## Version 9.1.1.3

*September 16, 2025*

* **Admin Management:** Super Admins can now add multiple Admins and assign tailored permissions for better control and governance.
* **Authentication Logs:** Enhanced tracking of authentication activities for improved transparency and security oversight.

### Enhancements

**Web Application Firewall:**

* **Easy Certificate Setup:** Just add a CNAME record — the certificate will be issued within minutes and automatically renewed, with no manual steps required.
* **Flexible Configuration:** Osto Web App & API Protection Module supports IPv4, IPv6, and domain name configurations.
* **Automatic SAN Certificates:** If your website uses the "www" subdomain, Osto WAF will automatically detect it and issue a certificate that covers both the root domain and the "www" subdomain.

**Domain Filtering:**

* **Improved Domain Filtering Performance:** Optimized traffic processing to reduce latency during high traffic loads — resulting in faster and more reliable domain filtering.
* **Domain Filtering Insights:** Get helpful descriptions for domain categories within the policy settings.

***

## Version 9.1.1.2

*July 2, 2025*

* **MacOS Support:** The macOS Agent is now compatible with macOS versions 14 and 15.
* **AI-Driven Adaptive Web Protection Profiling:** Automatically detect, monitor, and intelligently profile website and API traffic using AI.
* **WebChat Support:** Get help when you need it — now live inside the admin dashboard.
* **TLS Version Configuration:** Configure which TLS versions are allowed under Website advanced settings.
* **MFA for Secure Server Access:** Multi-factor authentication for accessing critical infrastructure.
* **Endpoint Incident Enhancement:** Enhanced user-level visibility for more precise detection and investigation of endpoint activities.

### Enhancements

* **Onboarding Flow Optimization:** Cleaner, faster, and smarter — improved DNS handling, more intuitive TLS settings, and optimized onboarding journey.
* **Expanded Dashboard Insights:** New insights: Shadow APIs, Top 5 Accessed Servers, Top 5 Risky Users.
* **User Asset Management:** View which users have (or haven't) installed the Agent App; bulk notify users missing the app.
* **Domain Category Intelligence (Powered by AI):** Searchable and explainable domain categories with tooltip guidance; automatically uncover related or secure subdomains via AI-driven discovery.
* **One-Click Recommended Policies:** AI-curated best-practice security policies with zero guesswork.
* **Revamped DAST Web Scanner UI:** Cleaner formatting, improved scan report readability, and scheduled email report delivery.
* **Osto Captcha Page UI Revamp:** Smarter and more visually refined captcha page.

### Security Updates

* **Enforced MFA for Server Access:** Multi-factor authentication can now be enforced for all Secure Server and Secure Gateway connections.
* **Granular TLS Version Management:** Fine-grained control over supported protocol versions.
* **AI-Powered Web Categorization:** Our engine now categorizes over 100M+ domains across 60+ categories.


# Best Practices
Source: https://docs.osto.one/support/best-practices

Recommendations to optimize your security posture and manage the platform efficiently.

Follow these recommendations to get the most out of Osto and keep your security posture strong.

## Websites & SSL

* **Keep certificates valid:** Use unexpired SSL certificates and renew them ahead of time. Osto can auto-generate and renew certificates for you, or you can upload your own.
* **Use a low DNS TTL during changes:** Set your DNS record's TTL to 600 seconds or lower before making changes so updates propagate quickly with minimal downtime.
* **Start in Detect, then move to Prevent:** Run a new website in **Detect Mode** first to observe traffic without blocking, then switch to **Prevent Mode** once you're confident legitimate traffic isn't affected.
* **Tune the Advanced policy:** Review the protections in your Website Protection **Advanced** policy (URL Protection, Parameter Protection, Data Theft Protection, Cookie Security, and rate/request limits) so coverage matches your application.

## Endpoint user policies

* **Principle of least privilege:** Put users in groups and grant the minimum access each role needs.
* **Review regularly:** Periodically revisit Device Control, App Control, Domain Filtering, and DLP policies so they stay aligned with current needs.
* **Update as roles change:** Revise policies when roles change or new apps are introduced to avoid stale or overly permissive rules.

## Secure server access

* **Allow Osto connectivity:** Make sure server firewalls permit the connections Osto needs for seamless access.
* **Enable MFA:** Keep multi-factor authentication on for secure-server access.
* **Review session logs:** Check **Logs → Secure Server Logs** for unauthorized or anomalous access.

## Threat protection

* **Set realistic rate limits:** Configure strict-but-realistic rate limiting on sites and APIs to blunt brute-force and volumetric attacks.
* **Keep bot & DDoS mitigation on:** Leave Bot Mitigation and DDoS Protection enabled and review them as attack patterns evolve.
* **Watch for anomalies:** Use the dashboard and **Logs** to monitor unusual activity and act before it escalates.

## Scan and secure proactively

* **Scan before you ship:** Run the **Web Scanner** on your sites and the **App Scanner** on mobile builds, and connect a Git provider to **SAST** (Code Security) to catch vulnerabilities, dependency issues, and secrets early.
* **Connect your cloud:** Add your AWS, Azure, or GCP accounts under **Cloud Security** for continuous posture findings.
* **Stay audit-ready:** Use **Compliance → AutoComply** to generate policies, track controls, and assign security awareness training.

<Note>
  See the [How-to Guides](/how-to-guides/asset-management/index) for step-by-step walkthroughs of each area referenced above.
</Note>


# Frequently Asked Questions
Source: https://docs.osto.one/support/faqs

Answers to common questions about the Osto platform.

## What is Osto?

Osto is an all-in-one security platform that brings web & API protection, endpoint security (device, application, and domain control plus data leakage prevention), secure server access, vulnerability and code scanning, cloud security posture management, and compliance automation together in a single dashboard.

## How do I add my website to Osto?

1. Go to **Assets → Domains → Manage Domains** and click **Add Website**.
2. Enter your domain and click **Verify**, then add your origin server IP (or load-balancer domain) and choose your TLS versions and CDN usage.
3. Set up your certificate — let Osto **auto-generate** one (by adding the provided CNAME record to your DNS) or **upload your own** as a ZIP archive.
4. Point your domain's DNS to Osto as directed so traffic flows through protection.

See [Managing Websites & Subdomains](/how-to-guides/asset-management/managing-websites) for the full walkthrough.

## What's the difference between Detect Mode and Prevent Mode?

**Detect Mode** observes and logs traffic without blocking — useful when you first onboard a site. **Prevent Mode** actively blocks malicious requests. You can switch a website between the two from its row in **Manage Domains**.

## Can I apply multiple policies to a single user or website?

Yes. You can layer policies — for example, separate Device Control, App Control, Domain Filtering, and DLP policies for an endpoint group, or DDoS, Bot, and Advanced policies for a domain.

## What happens if I delete a website or user?

Deleting a website or user permanently removes its associated configuration, policies, and settings. This can't be undone, so back up anything you may need first.

## How long do DNS changes take to take effect?

It depends on your DNS provider and the record's TTL. Changes can appear within minutes but may take up to 24 hours to propagate fully. Set a low TTL (for example, 600 seconds) before making changes.

## Can Osto scan my code and applications?

Yes. The **Scanner** runs vulnerability scans on your websites (Web Scanner) and mobile app builds (App Scanner), and **Code Security → SAST** connects to GitHub, GitLab, or Bitbucket to run static analysis, dependency scanning, and secret detection across your repositories.

## Does Osto help with compliance?

Yes. **Compliance → AutoComply** activates a framework (such as SOC 2), maps out the required controls, generates company policies, tracks compliance tasks, and runs security awareness training for your employees.

## Where can I see activity and threats?

Under **Logs** — Web App Logs (threats, access, and policy violations), Secure Server Logs, Domain Filtering Logs, Incident Logs, Audit Logs (admin actions), and Auth Logs (sign-ins).


# Getting Help
Source: https://docs.osto.one/support/getting-help

How to get support, what to include, and where to find the information Osto's team needs.

If the [FAQs](/support/faqs) and [Troubleshooting](/support/troubleshooting) guides don't resolve your issue, here's how to reach us.

## Contact options

* **Email:** [connect@osto.one](mailto:connect@osto.one)
* **Shared support channel:** post in the channel set up with your Osto representative.

## What to include

Sharing a few details up front helps us resolve issues faster:

* The **area** affected (for example, a specific domain, policy, scan, or server).
* A **Request ID** from **Logs → Web App Logs** when reporting a blocked or suspicious request.
* **Screenshots** of any error message or unexpected behavior.
* The **time** the issue occurred (so we can line it up with logs).

## Useful references

* **Release Notes** — check the latest [release notes](/release-notes) to see if a recent change is related.
* **Logs** — the [Logs](/how-to-guides/logs/index) section is the fastest way to see what happened and when.
* **Audit Logs** — review recent configuration changes under **Logs → Audit Logs**.

<Note>
  The status banner at the top of the dashboard reflects overall platform health in real time.
</Note>


# Glossary
Source: https://docs.osto.one/support/glossary

Definitions for the key terms used across Osto and this documentation.

A quick reference for the terms you'll see throughout Osto and these docs.

## Assets & objects

* **Asset** — something Osto protects: a domain, an endpoint user, or a server.
* **Domain** — a website, web app, or subdomain you protect with Osto.
* **Endpoint User** — a person in your organization (and their device) covered by endpoint policies.
* **Secure Server** — a host you register so users reach it only through Osto, never directly.
* **Secure Gateway** — a single host that brokers access to multiple child servers behind it.
* **Object** — a reusable building block referenced by policies: a **Domain Category**, **Application** group, **Port**, or **Schedule**.
* **Schedule Class** — a time window (such as *Forever* or a set day/time range) that controls when a policy applies.

## Web protection

* **Web Application Protection (WAF)** — Osto's protection layer that inspects and filters traffic to your sites.
* **Detect Mode / Prevent Mode** — whether a site's protection only *observes and logs* (Detect) or *actively blocks* (Prevent).
* **DDoS Protection** — defenses against volumetric, traffic-flooding attacks.
* **Bot Mitigation** — detection and blocking of automated/bot traffic.
* **Advanced policy** — per-domain controls including URL Protection, Parameter Protection, Data Theft Protection, Cookie Security, and rate/request limits.
* **API Discovery** — automatic detection of API endpoints served by your protected domains.

## Endpoint protection

* **Device Control** — rules for hardware (USB, Bluetooth, Wi-Fi, etc.).
* **App Control** — rules for which application categories users can run.
* **Domain Filtering** — allow/block rules for the website categories users can reach.
* **Data Leakage Prevention (DLP)** — rules that limit how sensitive data can be moved or copied.

## Scanning & code security

* **Web Scanner / App Scanner** — vulnerability scans for your websites and mobile app builds.
* **SAST** — static application security testing: analysis of your source code for vulnerabilities.
* **SCA** — software composition analysis: scanning your dependencies for known vulnerabilities.
* **Secret detection** — finding hardcoded credentials, keys, or tokens in code.
* **CWE / CVE** — industry-standard identifiers for a class of weakness (CWE) or a specific known vulnerability (CVE).
* **KEV** — Known Exploited Vulnerabilities; flags issues with active real-world exploitation.
* **Osto Risk Score** — Osto's prioritization score combining severity, exploit likelihood, and known-exploited status.

## Posture & compliance

* **Cloud Security Posture** — continuous discovery of cloud assets and security findings across AWS, Azure, and GCP.
* **AutoComply** — Osto's compliance automation for frameworks like SOC 2.
* **Framework** — a compliance standard (e.g. SOC 2) made up of requirements and controls.
* **Control** — a specific safeguard that helps satisfy a framework requirement.
* **Attestation** — a formal statement, generated from your organization details, used in compliance reporting.
* **Security Awareness Training** — assignable training programs that satisfy "train your people" controls.


# Troubleshooting Common Issues
Source: https://docs.osto.one/support/troubleshooting

Solutions to common problems you may encounter with the Osto platform.

If you hit a problem, review these common issues and fixes before contacting support.

## Website not loading after onboarding

* **DNS configuration:** Confirm your domain's DNS points to Osto as directed during setup.
* **Certificate:** Verify a valid certificate is issued/assigned — either Osto-generated (CNAME added) or your uploaded one.
* **Firewall:** Ensure your origin server allows the connections Osto needs.
* **Policy conflicts:** Check your Website Protection policies aren't blocking legitimate traffic — try **Detect Mode** to confirm.
* **Propagation:** Clear your local DNS cache or allow time for DNS changes to propagate (up to 24 hours).

## Certificate not applying correctly

* **Use a ZIP archive:** Uploaded certificates must be a ZIP containing valid certificate files (`.crt`/`.pem`) and private-key files (`.key`/`.pem`).
* **Domain match:** Ensure the certificate's common name (CN) or subject alternative name (SAN) matches the domain you're securing.
* **Not expired:** Confirm the certificate is still valid.
* **Re-upload:** Re-upload the archive and re-assign it to the website.
* **Or auto-generate:** Let Osto issue the certificate by adding the provided CNAME record to your DNS instead.

## Security policies not applying

* **Correct assignment:** Confirm the policy is assigned to the right users, groups, or websites.
* **Saved:** Make sure you clicked **Save** after editing.
* **Priority/precedence:** For Secure Server Access, a higher-priority policy can override your rule — check for conflicts.

## Secure server connection issues

* **Installation script:** Confirm the generated script ran on the server without errors.
* **Connectivity:** Ensure the server can reach the Osto platform.
* **MFA & access:** Verify multi-factor authentication is satisfied and you're using the correct access for the connecting user.

## Scanner shows no results

* **Scan still running:** Web and app scans run asynchronously — results populate once the scan completes.
* **Right target:** Confirm you selected the correct domain (Web Scanner) or uploaded a supported build — `.apk` or `.ipa`, up to 100 MB (App Scanner).

## SAST isn't picking up repositories

* **Provider connected:** Confirm your GitHub, GitLab, or Bitbucket connection is active under **Code Security → SAST → Integrations** (use **Test**).
* **Repositories synced:** Use **Sync** to refresh the repository list, then start a scan from the Repositories or Scans tab.

***

<Tip>
  Still stuck? Contact your Osto representative at [connect@osto.one](mailto:connect@osto.one) or post in your shared support channel.
</Tip>