ADO Permissions Mitigations
Last updated
Last updated
This page describes the Arnica mitigation process for risks located within Azure DevOps (ADO) organizations.
Any member of the “Project Collection Administrators” and “Project Collection Build Administrators” groups is considered an admin within your ADO organization. Any member of one of these two teams is considered an excessive admin if they have not exercised admin privileges in the last X days, where X is defined by your organization’s policy settings.
When an excessive Admin risk is mitigated, the user is removed from one or both of the above administrative groups and is instead added as a member of the “Contributor” group for each project within the ADO organization. Reverting this mitigation will remove the user from the “Contributor” groups and add them back to the admin group that they were originally a member of.
Users within the organization are considered contributors when they are granted contributor permissions either directly or indirectly to a given branch. Users are granted direct permissions when their contributor permission for the given branch is set to “Allow”. Users are granted indirect contributor permission when added to the Contributor group of a project, or when added to a group that has been granted Contributor rights to a given repo, project, or branch. Contributor permissions can be excessive for one of two reasons: 1. Contributor permissions are considered excessive when the ability to push code is unimpeded by project, repo, and branch level policies, and the user has not pushed code in 90 days. This is only possible when the branch’s policies do not require a reviewer. 2. Contributor permissions can also be excessive if they grant the user the ability to review other pull requests, but they have not reviewed a pull request within the last 90 days. This occurs when a branch protection policy is set to require at least one reviewer, but no reviewers are specified in the policy. This configuration escalates the permissions of the contributor role to allow peer reviews.
When Arnica mitigates an excessive contributor risk it first determines which of the two excessive contributor scenarios is relevant, and then acts accordingly. 1. If the contributor permission is excessive because no review policy is in place, the user’s contributor policy for that branch is set to “Deny”, removing their ability to push code without review.
2. If the contributor’s permission is excessive because the contributor has been granted the ability to complete peer reviews, Arnica will add all contributors who have conducted review to the designated list of reviewers within the branch, limiting reviewer privileges to those users who have completed a review in the last X days.
Pull request reviewers are users who are designated as required reviewers within a branch protection policy. These reviewers may be added as a reviewer to the entire branch, or to a policy where a specific path within the branch is specified. Pull Request Reviewers are considered excessive when they have not completed a review for the specified branch or path.
When mitigating excessive reviewer permissions, Arnica treats the policy for each branch and distinct path individually. For each reviewer list Arnica removes any user present that has not completed a review, leaving only those users who have exercised their reviewer privileges. In the event that a group, and not users are listed in the reviewer list, the group's members will be assessed individually, and a new group will be created by Arnica. This group will include only those members from the original group that were not excessively privileged and will replace the old group on the policy list.