Skip to content

Discovery: bot member for Suggested Solution (was: Auto Remediation)

Problem to solve

In the auto-remediation MVC user research (#36500 (closed)), we found users are not comfortable with being the author of the auto-created merge request. There isn't currently a bot or neutral member/user we could use as an alternative.

📽 view issue kickoff: context, ideation, and questions review

Intended users

Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ -->

Further details

Based on an MVC proposal for a bot (#36500 (comment 260858531)), this discovery looked into the 1) engineering/implementation requirements, 2) security concerns using a bot member, 3) UX with using bot.

Proposal

Consider adding a "bot" user to Ultimate tier instance, called GitLab-Security-Bot. This user would be the author of the auto-created merge requests.

Bot overview
bot_profile

Use case for auto-remediation #36500 (closed):

When activating feature: user that enables the feature in the configuration section and the auto-created MR authored by GitLab Vulnerability Bot (instance user account). The feature is opt-in by default, once container and/or dependency scanning are configured
flow
Discovery review and findings:
  • Learn about our existing “bots” functionality GitLab Support Bot (Service Desk) and/or GitLab Alert Bot
    • How are they created?
      • #10159 (closed) - Bot is added on instance-level. It's User. From the backend side of things bot can be called by User.security_bot. It creates a User entity in the database. Bot isn't a member of any project, it is visible only from Users tab in the Admin panel. Such Bot doesn’t take a seat in the License plan. Bot has a User profile, its username can be used in queries by MR’s author name.
    • Are they out of the box?
      • Adding a new bot is quite simple: add new bot to ee/app/models/ee/user_bot_type_enums.rb and follow example for Alert bot
    • How do they work for saas vs on-premise?
      • It works in the same manner.
    • Are the current bots visible members?
      • Yes, for example: support bot is visible in the list and the functionality is shown like others, but the user is unable to take actions (goes to 404 page when executed). issue created: #208793 (closed). For the GitLab Security Bot we can display the user to surface documentation (actions not visible in UI)
    • How we can add Bot as an MR author?
    • What might we be able to reuse?
    • How do make sure the extra member doesn't add a seat?
      • These bots ain't members, they are "users" on instance level and are operated from inside of GitLab. That means that we can use those bots for any projects.
  • For the use case of auto-remediation MVC:
    • Can we have this bot as a member that’s out of the box? Consider UX when the member is deactivated and the relationship with the opt-in of auto-create merge request
    • UX for findability and discovery of the bot
    • Bot member profile page activity - what/when activity will be shown
    • Identify permissions: who can setup/deactivate feature/bot? Is the bot member a developer?
  • What are the security concerns?
    • Will sync with our appsec team with proposed prototype to review and analyze for security issues
  • Learn about any use cases that may follow
other considerations:
  • Have a link to the Bot's documentation page in the bot's profile that explains the account and how to manage it and what it does
  • For opened merge request, having it automatically assigned could be helpful and/or that aligns to an orgs workflow
  • Add activity or note that "This MR was generated automatically by GitLab" or similar to bot action occurs
  • If we have built-in user accounts, these accounts should have something more than a gravatar and a "Bot" name, there should be some design treatment that clearly denotes this account as a system account.
What does success look like, and how can we measure that?
  • In testing our MVC: #36500 (closed), we found users said they would create a new member to auto-create the merge requests. Does the user use the GitLab-Security-Bot instead?
  • Does the user understand the bot is a member and understands it's role (author of merge request)?
  • Does the user know how to setup the feature?
What is the type of buyer?

GitLab Ultimate

Discovery Conclusion

Discovery outcome: UX/Engineering recommends the proposed solution to introduce a GitLab-Security-Bot user in #36500 (closed).

Engineering notes

How to create a bot?

Adding a new bot is quite simple: you need to add bot to bots_hash and create a class method for User model. Example of adding Alert bot: !10460 (diffs)

Is Bot a User?

Yes, from the code bot can be called by User.security_bot. It creates a User entity in the database. Bot isn't a member of any project, it is visible only from Users tab in the Admin panel. Such Bot doesn’t take a seat in License plan. Bot has a User profile, its username can be used in queries by MR’s author name.

How to assign Bot as an author of MR?

Proposed workflow: Pipeline is successfully finished. We check if available solutions are available on the backend. If there are solutions available, we create an MR with the help of VulnerabilityFeedback::CreateService and we put security_bot as an author of the MR. (now this service use current user as an author) We can reuse this code https://gitlab.com/gitlab-org/gitlab/-/blob/197808d37204cc16886e3404e47205555a24335c/ee/app/services/vulnerability_feedback/create_service.rb#L75 to create an MR automatically. We just need to change current_user to bot.

UX notes

Ongoing and next step efforts:
  • Displaying projects that #210519 is configured in the profile. This is to help the user understand what projects are affected by the system bot. (since the profile will span across different projects)
  • UX bug: removing front-end actions available to bots in admin > user, related issue #195309 (closed). The Security Bot will be seen in the admin
  • Work closely with the technical writing team to ensure clear documentation. Additionally, evaluate as new tasks are added to the bot.
  • In #36503 (closed) and any other system tasks the bot may adopt: evaluate with app sec team to ensure alignment and identify security concerns.
  • Look into creating a custom bot emoji to reinforce it’s a bot (key UXR question: do users understand this is a system, not their org user)
  • Visual design: 1) create an avatar for the security bot, and 2) align profile with other bots for consistency and better communication to the user that it’s a system bot (#210523). Example: that https://gitlab.com/support-bot does not include links to documentation or visually anything to distinguish it as a system bot.
User research questions:
  • What is the user’s perception of the bot?
  • Does the user understand that the user is a GitLab system feature?
  • If the user wants to learn more, what do they do?
  • Is the documentation accessible and clear?
Edited by Nicole Schwartz