Last month, Yvie Djieya wrote a blog post describing how JupiterOne's security team manages "meeting evidence" as code. Yvie covered the difficulty of managing meeting evidence for various auditing frameworks and elaborated on JupiterOne's process for managing meeting evidence as code. Today, I will take this one step further by covering an automated process to ensure all reviewers have approved the meeting notes and then auto merge the meeting evidence into the main code branch.
Need for Automation
When a reviewer clicks "Approve" for the GitHub pull request, it represents two things:
- the reviewer has confirmed their presence at the meeting, and
- the reviewer agrees that the meeting minutes are accurate.
Before implementing an automated solution, the minutes taker was responsible for ensuring all reviewers approved the pull request before manually merging the pull request into the main branch. However, this step relied on a person to remember to continually check the pull request until all meeting attendees had clicked "Approved" (checking the pull request over a period of minutes, hours, or days after the meeting). Once all reviewers clicked "Approved", the minutes taker could merge pull request. This is yet another task, to add to a plethora of to-dos, for an employee to track.
The other caveat of manually checking reviewers and merging is that a merge could mistakenly happen before all reviewers click "Approve". In this case, the merge will not accurately reflect the evidence of the meeting (i.e. 4 reviewers attended the meeting but only 3 reviewers were accounted for because they clicked "Approve" before the merge happened). The opportunity cost for automating this task is covered by the assurance that the task will not be forgotten by the minutes taker and all reviewers will be accounted for.
Github Action
At this time, there is not an option within GitHub's "Branch Protection Rules" to ensure that all reviewers have approved a pull request. Therefore, JupiterOne wrote a GitHub Action to enforce this desired review behavior.
Installation
Copy verify_all_reviewers.yml and check_for_reviewers.yml to the .github/workflows folder in your repo, in your main branch.
Create an initial run of both workflow actions. These workflows will fail; however, it is required for the following step - configuring branch policy settings.
- Go to "Actions" and "Verify All Reviewers"
- Click the drop down "Run workflow" and then the "Run workflow" button
- Perform the same steps above for "Check for Reviewers"
GitHub Configuration
Set auto-merge
- Go to "Settings" -> General"
- Select "Allow auto-merge"
Set the branch policies
- Go to "Settings" -> "Branches"
- Under "Branch protection rules", either edit a current rule or add a new rule
- Configure the following rule settings:
- "Branch name pattern"
- Enter a branch name (usually 'main')
- "Protect matching branches"
- Select "Require a pull request before merging"
- Select "Require approvals"
- Select "1"
- Select "Require status checks to pass before merging"
- Search for and select "Verify All Reviewers"
- Search for and select "Check for Reviewers"
Click either "Save changes" or "Create"
Automation in Action
- Click on the meeting notes file and click the "Edit" button on the right of the menu
- Add notes from the meeting accordingly, then scroll to the bottom.
- Create a new branch for the meeting notes and click "Propose changes." Then click "Create pull request"
- Click the "Enable auto-merge" button and then "Confirm auto-merge"
- Request the reviewers from the meeting.
Conclusion
Policies, procedures, and documentation are an important part of ensuring security. However, there is a delicate balance between security and usability. If processes are too cumbersome, people will circumvent steps in order to accomplish tasks. Therefore, the more we automate, the easier our jobs will be; let computers do what they do best - perform a task repeatedly at a specified cadence. Employees are then free to do what they do best - create, innovate, and inspire.
