Excessive Code Contributors

Definitions

Code contributors are classified as individuals with the ability to push code to a given source code repository.

Open source projects tend to limit the count of collaborators with write access to the code. Individuals who are interested to contribute to the open source project can fork the repository and create a pull request with the changes. According to this definition, not every developer who contributed code to open source project is considered as a code contributor.

Risks

Having excessive code contributor permissions in a source code repository can pose several operational and security risks:

  1. Uncontrolled changes: If too many people have write access and there is no branch protection policy in place to require pull request reviews, it could result in chaotic and uncontrolled changes to the code. It would be difficult to maintain quality control and stability in the codebase, leading to more bugs and potentially insecure code.

  2. Malicious modifications: Write permissions allow users to modify the source code. If a user account with these permissions is compromised, a malicious actor could introduce security vulnerabilities, alter the program's functionality, or insert backdoors into the software.

  3. Accidental alterations: Users with write permissions could inadvertently introduce bugs or delete crucial parts of the source code. This risk is amplified when more users have write permissions, especially if they're not familiar with all sections of the codebase.

  4. Codebase instability: Excessive write permissions can result in an unstable codebase. Frequent, unreviewed changes could lead to software instability, make debugging more difficult, and slow down the development process.

  5. Inefficient development process: When too many people have write access, it can lead to confusion and conflicts in the development process. Multiple people might unknowingly work on the same feature or issue, leading to conflicts and wasted efforts.

  6. Bypassing development procedures: Established development and deployment procedures, such as code reviews and automated tests, could be bypassed by users with write permissions. This could result in untested or vulnerable code being merged and deployed.

How excessive permissions are determined?

Excessive pull request reviewers and CODEOWNERS are identities that their approval is counted towards the ability to merge code to the target branch, but they did not review any code changes in the applicable source code repository in a given time frame.

How to change the excessive permissions logic?

To configure the time frame for excessive pull request reviewers or CODEOWNERS permissions, go to the Policies page under the Admin section and adjust the permissions definitions settings for Code Contributors.

How to mitigate excessive permissions?

Navigate to the Git Posture page and click on the Permissions widget.

If you have multiple source code management (SCM) tools, select the relevant SCM type at the top right corner menu.

Github: Create CODEOWNERS or "Restrict Push"

Arnica can create a CODEOWNERS file or modify the branch protection policy to restrict who can push code to the important brach in the repository.

Create and enforce CODEOWNERS

Arnica creates a Pull Request with the modified CODEOWNERS file based on the Pull Request activities in each of the branches. If there have been no recent Pull Requests (based on the policy configurations), there is insufficient context to create a CODEOWNERS file.

By selecting this mitigation option, Arnica will generate a CODEOWNERS file and create a Pull Request to approve these changes. Upon approval, Arnica will enable the branch protection policies to require at least 1 approver from the Code Owners file is enabled, as in the screenshot below:

Enable "Restrict Push" branch protection policy

When a repository does not have any branches with recently merged code from Pull Requests, Arnica will assess which branches need to be protected by restricting who can push to these branches. By selecting this mitigation option, Arnica will enable the branch protection policy for each of the selected branches. Below is a screenshot of the anticipated result when only a single user needs to push code to a given branch.

Azure DevOps: Modify branch protection policy

Modify reviewers in branch protection policy

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.

Assign reviewers in branch protection policy

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 90 days.

Last updated