> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/security-testing-orchestration/3.0/troubleshooting-and-resources/rbac.md). # RBAC for STO - Role-Based Access Control Harness STO offers granular Role-Based Access Control (RBAC) for all its resources. You can precisely control who can view, create, or manage resources across different scopes. RBAC ensures that only authorized users or teams can access or perform actions on critical resources such as **Issues**, **Scans**, **Exemptions**, **Test Targets** etc. You can configure permissions and resource groups at the **Account**, **Organization**, or **Project** level. For more details on general RBAC setup, refer to the [Harness RBAC configuration guide](/harness-ai/use-harness-platform/platform-access-control.md). This document details about: * [STO Resources and Role Permissions](#sto-resources-and-role-permissions) * [Built-in STO Roles (Default Roles)](#built-in-sto-roles-default-roles) {% embed url="" %} {% hint style="info" %} To assign Roles, you need Administrative privileges at the **Account** level (**Account Admin** role). {% endhint %} ### STO Resources and Role Permissions STO resources can be managed and secured using Role-Based Access Control (RBAC). Each resource has its own set of permissions, which you assign to roles. [**Roles**](/harness-ai/use-harness-platform/platform-access-control/add-manage-roles.md), when combined with [**Resource Groups**](/harness-ai/use-harness-platform/platform-access-control/manage-resource-groups.md), determine the access level and permissions users have within STO. Access to STO resources depends on the [**scope**](/harness-ai/use-harness-platform/platform-access-control.md#permissions-hierarchy-scopes) at which a role is assigned: * **Account**: Permissions apply across the entire account. * **Organization**: Permissions apply to all projects within an organization. * **Project**: Permissions apply only within a specific project. STO resources are available at different scopes, and not every scope includes all resources. The table below outlines which resources are supported at each scope. Here's how it looks at the Project level. The following table provides a detailed overview of each STO resource, its supported permissions, available scopes, and descriptions: | Resource | Permissions | Project Scope | Organization Scope | Account Scope | Description | | -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-----------: | :----------------: | :-----------: | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Issues | | ✅ | ✅ | ✅ | Vulnerabilities identified by security scans. Tracked at project level and viewable at higher scopes. | | Test Targets | | ✅ | ❌ | ❌ | [Approve Base Image](/security-testing-orchestration/3.0/use-sto/set-up-sto-scans/container-scanning/base-image-vulnerabilites/approve-base-image.md) Targets for labeling and policy enforcement. | | Scans | | ✅ | ❌ | ❌ | Security test executions within pipelines. | | Exemptions |

(Refer to Exemption Permissions Matrix for more details.)

| ✅ | ✅ | ✅ | Requests to ignore identified vulnerabilities from policy enforcement. | | External Tickets (*coming soon*) | | ✅ (*planned*) | ❌ (*planned*) | ❌ (*planned*) | External issue-tracker tickets linked to STO vulnerabilities (e.g., Jira). | #### Permission Details Permissions control the specific actions users can perform on STO resources: * **View**: Allows users read-only access to resources. * **Create/Edit**: Enables users to configure, create, or modify resources. * **Delete**: Grants the ability to remove resources (where applicable). * **Approve/Reject**: Provides authority to approve or reject resources. ### Built-in STO Roles (Default Roles) Harness includes two built-in roles specifically designed for STO use cases. [**Security Testing Developer**](#security-testing-developer) and [**Security Testing AppSec**](#security-testing-appsec). These roles come pre-configured with sets of permissions on STO resources to match typical developer and security team responsibilities. #### Security Testing Developer For development or DevOps engineering teams, this role allows full access except for "Delete" on external tickets and "Approve/Reject" on exemptions. #### Security Testing AppSec For security operations and application security teams, this role grants all available permissions including exemption approvals and ticket deletions.
Assign Security Testing roles: Default workflow 1. Select **Account/Organization/Project Settings** (left menu) > **Access Control**. 2. In the **Users** table, select the user profile. 3. Under Role Bindings, select **+Role**. 4. Assign the **Security Testing Developer** role or the **Security Testing AppSec** role to the user profile.