Skip to main content

Best practices for custom roles (Preview) Hosted customers only

If you have multiple teams collaborating on one or more projects, consider creating custom roles. Custom roles ensure that your teams have access to the appropriate resources and the correct permissions for those resources.

You can view the settings for the built-in roles to help you determine the types of actions and resource groups to add to your custom roles.

Custom role planning

Your first step is to create a plan for your custom roles.

  • Think about the roles that people currently have.

    For example, do you have managers and lead developers who need different access than other developers?

  • Think about the resources your teams need to work on.

    For example, will any of your teams use static scanning to check for vulnerabilities? In this case, they will need access to scan projects.

    Consider which applications your teams are working on so you can ensure they have access to them.

  • Think about the tasks or actions that individuals need to perform for the resources they need to access.

    For example, do individuals need to change organization settings? Do they need to be able to upload artifacts for scanning? Do they need to access application data?

Resource groups

Consider these best practices:

  • For ease in management, create resource groups that include one type of resource only. For example, keep your project resources in one group and your applications in another.

    if a built-in resource group meets your needs, you could also use it instead of creating a custom group.

  • Use roles to specify the actions users can take for the different resource groups.

Example

This example shows one approach for creating custom roles.

In this example, an administrator is creating custom roles for development teams collaborating on an ecommerce product.

Step 1: Create a plan for all the custom roles

  • Current roles: For this project, there are development managers, development leads, front-end developers working on a user interface , and back-end developers creating services and APIs. All of these teams collaborate together.

  • Resources: The Ecommerce product includes shared application components that are instrumented with Contrast agents as well as scan projects for code that is scanned early in the development cycle.

  • Actions: The development managers and leads need to be able to manage all settings for applications and scan projects.. The front-end developers need to be able to access shared user interface modules. The back-end developers need to be able to access APIs and back-end services.

Step 2: Create custom resource groups

To accommodate the different permissions you need to assign to different users, you create these resource groups:

  • Shared UI applications: This resource group includes the UI-focused applications that front-end developers need to test at runtime.

  • Shared UI projects: This resource group includes the UI-focused scan projects that front-end developers run to find vulnerabilities during the early stages of development.

  • Shared API applications: This resource group includes the shared API applications that back-end developers need to test at runtime.

  • Shared back-end services: This resource group includes the shared services that back-end developers need to test at runtime.

You group all the resource groups into a parent resource group called Ecommerce development.

All custom roles will include the parent group. You use actions to determine which role can access specific resources and the permissions users have for these resources.

Step 3: Create custom roles.

You set up these roles to use the parent resource group, Ecommerce development, with specific actions:

  • Ecommerce administrator: This role is for the Ecommerce development managers and leads. It includes these actions:

    • Manage application rules: Lets users perform tasks such as changing Assess or Protect rules, setting remediation policies, and setting library policies.

    • Manage application: Lets users change application settings.

    • Create project: Lets users create scan projects.

    • View, edit, delete project: Lets user view, edit or delete scan projects.

    • Delete project: Lets user delete scan projects.

    • View organization: Lets users perform tasks such as viewing score settings and getting API keys.

  • Ecommerce front-end developer: This role is for the Ecommerce front-end developers. It includes these actions:

    • View application: Lets users view application data such as vulnerabilities, application details, and library details.

    • Edit application: Lets users perform tasks such as merging applications, sending data to bug trackers, editing vulnerability settings

    • View organization: Lets users perform tasks such as viewing score settings and getting API keys.

    • Upload scans: Lets users scan code for vulnerabilities for existing projects.

      The action applies to uploading code to the Contrast web interface, using the CLI, and using the Scan local engine. The user who creates projects needs the Create, View, create, edit project action.

  • Ecommerce back-end developers

    • View applications: Lets users view application data such as vulnerabilities, application details, and library details.

    • Edit application: Lets users perform tasks such as merging applications, sending data to bug trackers, editing vulnerability settings

    • View organization: Lets users perform tasks such as viewing score settings and getting API keys.

Step 4:, Create custom users groups

You create user access groups for each role and assign individual users, based on the resources they need to access.

  • Ecommerce administrators: Includes all users with the Ecommerce administrator role.

  • Ecommerce front-end developers: Includes all users with the Ecommerce front-end developer role.

  • Ecommerce back-end developers: Includes all users with the Ecommerce back-end developer role.

In this section: