GitHub's Evergreen app revokes outside collaborator access when a quarterly review goes unanswered
GitHub built Evergreen, an app that revokes outside collaborators' access when nobody answers a quarterly review. GitHub says orgs that share repos with customers can adapt it. It runs on stock GitHub features and a small Go server.
The Engineer · Build desk
Outside collaborators lose access if nobody answers a review, and unchecked ones are revoked when the issue closes. A non-Hubber's close is reopened. Owners come from a custom property or the review team. Repos with no human activity are flagged, warned and archived.
- Who's exposed exposure Outside collaborators If nobody responds to an access review, access is revoked: the safe outcome is the default, claim 3
- Who has to decide decision Unchecked collaborators Revoked when the review issue closes; Evergreen posts a receipt of what it kept and removed, claim 10
- What it limits constraint Non-Hubbers If one closes an access review issue, Evergreen reopens it and posts a note explaining why, claim 11
- What's now possible capability Repo owners Named by an evergreen_repo_owner property, else recent authors on the access review team are cc'd, claim 12
- Who's exposed exposure Repos with no human activity Flagged and warned past a threshold, and archived if still untouched, claim 2
| Who | How | Kind | Claim |
|---|---|---|---|
| Outside collaborators | If nobody responds to an access review, access is revoked: the safe outcome is the default | exposure | 3 |
| Unchecked collaborators | Revoked when the review issue closes; Evergreen posts a receipt of what it kept and removed | decision | 10 |
| Non-Hubbers | If one closes an access review issue, Evergreen reopens it and posts a note explaining why | constraint | 11 |
| Repo owners | Named by an evergreen_repo_owner property, else recent authors on the access review team are cc'd | capability | 12 |
| Repos with no human activity | Flagged and warned past a threshold, and archived if still untouched | exposure | 2 |
What happened
- The second workflow flags repos with no human activity past a threshold, warns their owners, and archives them if they are still untouched.
- Reviews open two weeks before their cleanup runs, and a built-in grace period stops a stray manual run from bringing the cleanup forward.
- Each repo gets a checklist issue. Closing it fires a webhook, and Evergreen keeps the checked collaborators, revokes the rest and posts a receipt comment.
- If someone who is not a GitHub employee closes a review issue, the app reopens it and posts a note explaining why.
- Each repo's review state is one JSON file in a controller repo, recording who had access, the deadline, who decided and what happened.
Why it matters
- Who's exposed exposure Customers and partners carry the default: a review that nobody answers cuts their access, so employee attention is what keeps outside collaborators connected.
- What it limits constraint The close guard and the notification chain both depend on a defined employee group and review team, so an org without that split has to build it first.
- Who has to decide decision Evergreen only archives and never deletes, so an adopter with contractual data-deletion duties to customers has to decide how to handle those separately.
The risky moment in Evergreen is the issue close. According to GitHub, the app reads the checkboxes, retains the checked collaborators and revokes the rest [10]. Close an issue with no boxes checked and no collaborator is retained [14]. That matches the stated rule that the safe outcome is the default outcome [3]. Recovery depends on the record: every access change is written into the repo's tracking issue, and GitHub says undoing a mistake takes a copy-paste of it to Copilot [4].
The state design is the best engineering in the post. Because state is plain files in git, the commit history is the audit trail, and a git log of one repo's state file answers why someone lost access [9]. There is no separate database or bespoke audit pipeline to run [9].
The owner lookup has a seam. A repo's owner comes from an evergreen_repo_owner custom property, or failing that from recent issue and commit authors who sit on the access review team [12]. Under those two steps, a repo with no property and no recent review-team authors would have nobody to notify [15].
For the pattern to transfer, the adopting org needs a group of employees distinct from the outsiders, because the close guard and the notification chain both key on that group [11][12]. The repos also have to be ones whose outside access is meant to lapse, as with the product trials and professional services engagements Evergreen was built for [1]. A partner who uses a repo daily and misses a notice would simply lose access [3]. We think default-revoke is the right tradeoff in GitHub's setting and a worse fit outside it.
GitHub calls the workflows a pattern you can adapt for your own organization [13]. The post text available stops at the deadline-passed section. It does not include repo counts, revocation rates or the inactivity threshold for archival.
What to watch
- Whether GitHub publishes Evergreen's source or a template, since the post describes a pattern to adapt and an adopter would otherwise rebuild the Go server.
- What the full post says happens after a review deadline passes, including how revocations are recorded and reversed.
- Any figures on repos covered, collaborators revoked and access restored after a wrongful revocation.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence40
- Adoption
- Not scored
- Hype gap+10
- Incentives35
- Confidence60
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
GitHub built Evergreen, a GitHub App, for a shared organization where GitHub employees ("Hubbers") collaborate with customers and partners on product trials and professional services engagements.
- [2]
Evergreen runs two workflows: quarterly outside-collaborator access reviews, and stale repository detection in which repos with no human activity past a threshold are flagged, warned, and archived if still untouched.
- [3]
Evergreen is fail secure: if nobody responds to an access review, access is revoked, so the safe outcome is the default outcome.
- [4]
Evergreen never deletes a repository or its contents; archived repos are recoverable, every access change is written into the repo's tracking issue, and GitHub says reverting a mistake is as easy as a copy-paste to Copilot.
- [5]
Evergreen is a small Go webhook server running in a container, built from stock GitHub features: a GitHub App, scheduled actions, webhooks, issues, custom properties, and plain files in a repo.
- [6]
A dedicated controller repo holds four scheduled GitHub Actions workflows that fire repository_dispatch events on a quarterly cadence, and the app does the work when they fire.
- [7]
Reviews open two weeks before their cleanup runs, and a hard grace period means a stray manual run cannot fast-forward the cleanup; each workflow also supports workflow_dispatch for manual triggering.
- [8]
Evergreen tracks each repo's status as one JSON file committed to the controller repo under state/repos/<repo_id>.json, recording who had access, when the review opened, the deadline, who decided, and what happened.
- [9]
Because state is just files in git, the commit history is the audit trail: a git log of the state file shows why someone lost access, and there is no separate database or bespoke audit pipeline.
- [10]
When an access review starts, each repo gets a checklist issue; when the issue is closed, Evergreen receives the issues.closed webhook, reads the checkboxes, retains the checked collaborators, revokes the rest, and posts a receipt comment listing what it kept and removed.
- [11]
If someone who is not a Hubber closes an access review issue, Evergreen reopens it and posts a note explaining why.
- [12]
Evergreen finds whom to notify through a fallback chain: an evergreen_repo_owner custom property (a @user or @org/team) if set; otherwise recent issue and commit authors who are on the access review team are cc'd.
- [13]
GitHub says the workflows in its post exhibit a pattern that can be adapted for other organizations.
- [14]
Closing a review issue with no boxes checked retains no outside collaborator, because Evergreen keeps only the checked collaborators and revokes the rest.
- [15]
Under the two-step owner chain as listed, a repo with no evergreen_repo_owner property and no recent issue or commit authors on the access review team has nobody to notify.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
- github.blogStaying Evergreen: How we automated secure access and repo hygiene in a shared org
1 article · October 15, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.