From f0a7f0068151370242311dfe2d50b1df38cdc7db Mon Sep 17 00:00:00 2001 From: Sall Date: Sat, 25 Jul 2026 07:19:34 +0100 Subject: [PATCH 1/4] docs(adr): verify ADR-0010's administrative-settings rollout gap Directly checked, via the GitHub API, what the 2026-07-18 audit left unverified: private vulnerability reporting is enabled on all 86 applicable repos, release immutability is off everywhere sampled (a real gap, not just an unknown), and advisory notifications turn out to be a personal setting outside what this ADR can audit at all. Checks off item 3 of the decision-review checklist. Item 2 (naming a backup incident contact) is a maintainer decision this cannot resolve and stays open; the ADR stays PROPOSED. --- decisions/0010-security-incident-response.md | 36 +++++++++++++++----- 1 file changed, 27 insertions(+), 9 deletions(-) diff --git a/decisions/0010-security-incident-response.md b/decisions/0010-security-incident-response.md index 302e71af1..42c8005d5 100644 --- a/decisions/0010-security-incident-response.md +++ b/decisions/0010-security-incident-response.md @@ -97,9 +97,24 @@ tracker. ### Administrative verification -As of the 2026-07-18 audit, private vulnerability reporting, advisory -notifications, backup access, and release immutability were not administratively -verified. This ADR does not claim that those controls are enabled. +Verified 2026-07-25 (ss-o), via the GitHub API: + +- **Private vulnerability reporting:** enabled on all 86 public, non-fork + repositories in the org. Not applicable to the 2 private repositories + (`.github-private`, `.trunk`); GitHub only exposes this feature on public + repositories, since its purpose is letting reporters without write access + report privately. +- **Release immutability:** not enabled anywhere sampled. The two repositories + that have actually cut a release (`zsh-lint`, packaged `zsh`) both show + `immutable: false` on their only release (`v1.0.0`, 2022). This is a real + gap, not an oversight in this ADR: if the org wants immutable releases, it + needs to be turned on, most usefully before the next tag on a release-cutting + repository. +- **Advisory/backup-access notifications:** not verifiable through the + repository or organization API; these are the incident owner's personal + GitHub notification settings, not an administrative setting this ADR can + audit. Confirming them is a manual step for whoever holds the role. +- **Backup incident contact:** still unresolved; see checklist item 2 below. ## Decision review required @@ -110,15 +125,18 @@ This ADR remains **PROPOSED**. Before acceptance, a maintainer must: (ss-o); see the SLA and severity sections above. 2. [ ] Name a backup incident contact and verify that contact's repository and advisory permissions. -3. [ ] Confirm where private vulnerability reporting, notifications, and - release immutability are enabled or required. +3. [x] Confirm where private vulnerability reporting, notifications, and + release immutability are enabled or required. Confirmed 2026-07-25 + (ss-o); see the Administrative verification section above. Private + vulnerability reporting is fully enabled; release immutability is + verified off everywhere and remains a rollout gap if the org wants it; + notifications are a personal setting outside this ADR's audit scope. 4. [ ] Accept, amend, supersede, or reject this proposal and record the decider and decision date. -Items 2 and 3 are unresolved, so this ADR is deliberately kept proposed rather -than accepted with those as rollout gaps: an incident-response process without -a verified escalation route or verified reporting/notification settings would -overstate what the org can actually deliver. +Item 2 is unresolved, so this ADR is deliberately kept proposed rather than +accepted with it as a rollout gap: an incident-response process without a +verified escalation route would overstate what the org can actually deliver. ## Consequences From f4bc9fb61d0b40b8acb30f236f061bfcc3ad0787 Mon Sep 17 00:00:00 2001 From: Sall Date: Sat, 25 Jul 2026 07:35:28 +0100 Subject: [PATCH 2/4] docs(adr): name wicoop as ADR-0010's backup incident contact Checklist item 2 needed a maintainer decision this couldn't make on its own. Names wicoop (an active org member) as backup, with access granted per incident rather than held standing: added as a draft security-advisory collaborator only when an incident is actually escalated, since wicoop's current repo access is inconsistent (read-only on most repos, admin on wiki, no TSC-team membership) and there's no live incident to grant broader access for yet. All three resolvable checklist items are now closed. Item 4, the accept/reject decision itself, is left open for a maintainer. --- decisions/0010-security-incident-response.md | 36 +++++++++++++------- 1 file changed, 24 insertions(+), 12 deletions(-) diff --git a/decisions/0010-security-incident-response.md b/decisions/0010-security-incident-response.md index 42c8005d5..1affdeee3 100644 --- a/decisions/0010-security-incident-response.md +++ b/decisions/0010-security-incident-response.md @@ -37,9 +37,16 @@ request are optional GitHub capabilities, not guaranteed outcomes. An organization maintainer is the incident owner for each report. The owner acknowledges, triages severity, coordinates the fix, and runs the post-incident -review. **ss-o** is currently the only documented maintainer and therefore the -proposed default incident owner. A named backup with verified access to the -affected repository and advisory is required before escalation is operational. +review. **ss-o** is the default incident owner. **wicoop** (named 2026-07-25) is +the backup incident owner. + +Named 2026-07-25 (ss-o): backup access is granted per incident, not held +standing. wicoop is an active org member today with read access on most repos +and admin on `wiki`, not TSC-team access. When an incident is escalated, the +owner adds wicoop as a collaborator on that repository's draft security +advisory at that time, matching how GitHub advisory collaboration actually +works; this avoids granting broad standing access that would sit unused +between incidents. ### Acknowledgement SLA @@ -66,9 +73,9 @@ slips. ### Escalation -If the owner cannot act within the acknowledgement SLA, use the named, -permission-verified backup route. Until that route exists, escalation is an -acknowledged rollout gap rather than an operational promise. +If the owner cannot act within the acknowledgement SLA, escalate to wicoop and +add them as a collaborator on the affected repository's draft security +advisory, per the Ownership section above. Critical incidents are worked immediately. Before the full fix, prefer a coordinated private mitigation, disabling or pinning affected functionality, @@ -114,7 +121,8 @@ Verified 2026-07-25 (ss-o), via the GitHub API: repository or organization API; these are the incident owner's personal GitHub notification settings, not an administrative setting this ADR can audit. Confirming them is a manual step for whoever holds the role. -- **Backup incident contact:** still unresolved; see checklist item 2 below. +- **Backup incident contact:** named 2026-07-25 (ss-o); see the Ownership + section above and checklist item 2 below. ## Decision review required @@ -123,8 +131,11 @@ This ADR remains **PROPOSED**. Before acceptance, a maintainer must: 1. [x] Confirm the proposed 3/5-business-day acknowledgement and triage targets and the 7/30/90-day remediation targets. Confirmed 2026-07-25 (ss-o); see the SLA and severity sections above. -2. [ ] Name a backup incident contact and verify that contact's repository and - advisory permissions. +2. [x] Name a backup incident contact and verify that contact's repository and + advisory permissions. Named 2026-07-25 (ss-o): wicoop, an active org + member. Access is granted per incident (added as a draft-advisory + collaborator when escalation actually happens) rather than held + standing; see the Ownership section above for why. 3. [x] Confirm where private vulnerability reporting, notifications, and release immutability are enabled or required. Confirmed 2026-07-25 (ss-o); see the Administrative verification section above. Private @@ -134,9 +145,10 @@ This ADR remains **PROPOSED**. Before acceptance, a maintainer must: 4. [ ] Accept, amend, supersede, or reject this proposal and record the decider and decision date. -Item 2 is unresolved, so this ADR is deliberately kept proposed rather than -accepted with it as a rollout gap: an incident-response process without a -verified escalation route would overstate what the org can actually deliver. +Items 1 through 3 are resolved; the remaining gaps (release immutability, +personal notification settings) are disclosed rather than hidden, not left +unaddressed. Item 4, the actual accept, amend, or reject decision, is a +maintainer call this ADR cannot make for itself. ## Consequences From 43666cad6c145735af2b1aa7d10479d6185ae0a6 Mon Sep 17 00:00:00 2001 From: Sall Date: Sat, 25 Jul 2026 08:45:41 +0100 Subject: [PATCH 3/4] docs(adr): close the escalation logic gap Copilot found in ADR-0010 Three fixes from review: - The checklist summary claimed release immutability was "verified off everywhere", overstating the Administrative verification section's actual scope (two sampled repositories). Reworded to match the evidence. - Escalation and Ownership described "the owner adds wicoop" as the access-grant mechanism, but escalation exists specifically for when the owner cannot act -- a real logic gap, not just wording. Since ss-o is currently the org's only admin, there genuinely is no one else who can perform that grant if ss-o is unreachable. Disclosed this plainly in both sections instead of implying an operational route that doesn't fully exist. Also dropped the undefined "TSC-team" acronym and time-relative "today" wording. - Checklist item 2 was checked as "verified" permissions, but the chosen access model deliberately never pre-verifies standing permissions. Reopened the item rather than leave a checked box that overstates what was actually confirmed. --- decisions/0010-security-incident-response.md | 53 +++++++++++++------- 1 file changed, 34 insertions(+), 19 deletions(-) diff --git a/decisions/0010-security-incident-response.md b/decisions/0010-security-incident-response.md index 1affdeee3..0d2cf8a43 100644 --- a/decisions/0010-security-incident-response.md +++ b/decisions/0010-security-incident-response.md @@ -40,13 +40,21 @@ acknowledges, triages severity, coordinates the fix, and runs the post-incident review. **ss-o** is the default incident owner. **wicoop** (named 2026-07-25) is the backup incident owner. -Named 2026-07-25 (ss-o): backup access is granted per incident, not held -standing. wicoop is an active org member today with read access on most repos -and admin on `wiki`, not TSC-team access. When an incident is escalated, the -owner adds wicoop as a collaborator on that repository's draft security -advisory at that time, matching how GitHub advisory collaboration actually -works; this avoids granting broad standing access that would sit unused -between incidents. +Named 2026-07-25 (ss-o): backup access is granted per incident rather than +held standing. wicoop is an active org member as of 2026-07-25, with read +access on most repositories and admin access on `wiki`, but is not a member of +the `tsc` GitHub team that CODEOWNERS assigns as reviewer for this +organization. When the primary owner is available, they add wicoop as a +collaborator on the affected repository's draft security advisory at +escalation time, matching how GitHub advisory collaboration actually works +and avoiding standing access that would sit unused between incidents. + +This has a real limit worth stating plainly: **ss-o is currently the +organization's only admin.** If ss-o specifically is the one who is +unreachable, there is no second admin to perform the access-grant step above, +and escalation is bounded by whatever access wicoop already holds until the +org has a second admin. This ADR does not claim that gap is closed; see +Escalation below for what that means in practice. ### Acknowledgement SLA @@ -73,9 +81,12 @@ slips. ### Escalation -If the owner cannot act within the acknowledgement SLA, escalate to wicoop and -add them as a collaborator on the affected repository's draft security -advisory, per the Ownership section above. +If the owner cannot act within the acknowledgement SLA, escalate to wicoop. +The owner grants wicoop collaborator access on the affected repository's +draft security advisory at that time (see Ownership above). If the owner +cannot act specifically because ss-o, the only org admin, is unreachable, no +one else in the org can currently perform that grant, and wicoop responds +using whatever access they already hold until the org has a second admin. Critical incidents are worked immediately. Before the full fix, prefer a coordinated private mitigation, disabling or pinning affected functionality, @@ -131,24 +142,28 @@ This ADR remains **PROPOSED**. Before acceptance, a maintainer must: 1. [x] Confirm the proposed 3/5-business-day acknowledgement and triage targets and the 7/30/90-day remediation targets. Confirmed 2026-07-25 (ss-o); see the SLA and severity sections above. -2. [x] Name a backup incident contact and verify that contact's repository and +2. [ ] Name a backup incident contact and verify that contact's repository and advisory permissions. Named 2026-07-25 (ss-o): wicoop, an active org - member. Access is granted per incident (added as a draft-advisory - collaborator when escalation actually happens) rather than held - standing; see the Ownership section above for why. + member. Left open rather than checked: standing permissions were + deliberately not pre-verified (access is granted per incident instead, + see Ownership above), and that model has a real gap when ss-o, the + only admin, is the one who is unreachable. "Verify permissions" as + written implies a pre-check this ADR does not claim to have done. 3. [x] Confirm where private vulnerability reporting, notifications, and release immutability are enabled or required. Confirmed 2026-07-25 (ss-o); see the Administrative verification section above. Private vulnerability reporting is fully enabled; release immutability is - verified off everywhere and remains a rollout gap if the org wants it; + verified off in both release-cutting repositories sampled (`zsh-lint`, + packaged `zsh`) and remains a rollout gap if the org wants it; notifications are a personal setting outside this ADR's audit scope. 4. [ ] Accept, amend, supersede, or reject this proposal and record the decider and decision date. -Items 1 through 3 are resolved; the remaining gaps (release immutability, -personal notification settings) are disclosed rather than hidden, not left -unaddressed. Item 4, the actual accept, amend, or reject decision, is a -maintainer call this ADR cannot make for itself. +Items 1 and 3 are resolved. Item 2 is named but deliberately left open: the +backup contact exists and the access model is decided, but standing +permissions were never verified and the single-admin gap means escalation is +not fully operational yet. Item 4, the actual accept, amend, or reject +decision, is a maintainer call this ADR cannot make for itself. ## Consequences From cd6027d516dc0759dfd48c67c46ec66622180a8b Mon Sep 17 00:00:00 2001 From: Sall Date: Sat, 25 Jul 2026 09:06:43 +0100 Subject: [PATCH 4/4] docs(adr): date the single-admin claim instead of saying currently Matches the dating convention used for every other verified/confirmed statement in this ADR, since org-role facts drift. --- decisions/0010-security-incident-response.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/decisions/0010-security-incident-response.md b/decisions/0010-security-incident-response.md index 0d2cf8a43..9751d4658 100644 --- a/decisions/0010-security-incident-response.md +++ b/decisions/0010-security-incident-response.md @@ -49,7 +49,7 @@ collaborator on the affected repository's draft security advisory at escalation time, matching how GitHub advisory collaboration actually works and avoiding standing access that would sit unused between incidents. -This has a real limit worth stating plainly: **ss-o is currently the +This has a real limit worth stating plainly: **as of 2026-07-25, ss-o is the organization's only admin.** If ss-o specifically is the one who is unreachable, there is no second admin to perform the access-grant step above, and escalation is bounded by whatever access wicoop already holds until the @@ -84,9 +84,10 @@ slips. If the owner cannot act within the acknowledgement SLA, escalate to wicoop. The owner grants wicoop collaborator access on the affected repository's draft security advisory at that time (see Ownership above). If the owner -cannot act specifically because ss-o, the only org admin, is unreachable, no -one else in the org can currently perform that grant, and wicoop responds -using whatever access they already hold until the org has a second admin. +cannot act specifically because ss-o (the org's only admin as of 2026-07-25) +is unreachable, no one else in the org can perform that grant, and wicoop +responds using whatever access they already hold until the org has a second +admin. Critical incidents are worked immediately. Before the full fix, prefer a coordinated private mitigation, disabling or pinning affected functionality,