root - chore: defense - record repository lockdown - #474
Conversation
Check off § 2 settings after the maintainer lockdown apply and Dependabot auto-dismiss rule. Update SECURITY.md to list live PR, tag, and Actions allowlist controls. Co-authored-by: Jared Wray <me@jaredwray.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #474 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 18 18
Lines 2760 2760
Branches 836 845 +9
=========================================
Hits 2760 2760 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c166f65217
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - All changes land through pull requests — direct pushes to `main` are blocked, and merging requires passing status checks. | ||
| - Tags (and therefore releases) can only be created by repository admins. | ||
| - Workflow runs from outside collaborators always require maintainer approval, and only allowlisted GitHub Actions can run. | ||
| - CI runs with read-only permissions; every action is pinned to a full commit SHA; Socket Firewall wraps package installs; workflows are security-linted with zizmor on every PR. |
There was a problem hiding this comment.
The security policy now promises that CI runs with read-only permissions, but the release-triggered build-binary job explicitly grants contents: write in .github/workflows/build-binaries.yaml:12-14 and uses that token to upload release assets. This makes the public description broader than the implemented control; retain the previous “defaults to read-only” wording or document the release-job exception.
Useful? React with 👍 / 👎.
| - Every action is pinned to a full commit SHA. CI workflows default to read-only `contents` permissions, and checkouts that do not push set `persist-credentials: false`. Socket Firewall wraps package installs; workflows are security-linted with zizmor on every PR. | ||
| - Dependencies install through pnpm with a 7-day cooldown on new versions, and lifecycle scripts are blocked by default. CI installs with a frozen lockfile. Socket reviews every dependency change; Aikido scans every build, and the release workflow's stage-publish job requires a passing Aikido release gate. | ||
| - All changes land through pull requests — direct pushes to `main` are blocked, and merging requires passing status checks. | ||
| - Tags (and therefore releases) can only be created by repository admins. |
There was a problem hiding this comment.
When a non-admin collaborator has write access, blocking that user from creating tags does not also prevent them from creating a GitHub release targeting an existing tag. Publishing such a release triggers the release workflows in .github/workflows/release.yaml:5-6, .github/workflows/build-binaries.yaml:5-6, and .github/workflows/deploy-site.yml:5-6, so the parenthetical claims a security boundary that the documented tag ruleset alone does not provide; remove the inference or document and enforce a separate restriction on managing releases.
Useful? React with 👍 / 👎.
| - [x] `.github/CODEOWNERS` covers `/.github/`, `/.cursor/`, `/.devcontainer/`, `/scripts/` with owners the maintainer names — PR #473 | ||
| - [x] Lockdown script run; `lockdown-repo.sh --check` passes clean — verified 2026-08-16 (maintainer apply) | ||
| - [x] Pull requests required on the default branch (1 approving review of the latest push, including code owners on owned paths; only the repository owner can merge, and they may merge without a review); force pushes and deletion blocked — verified 2026-08-16 (ruleset "Pull requests required") | ||
| - [x] Merges blocked unless required status checks pass (`--required-checks "build (22),build (24),build (26),zizmor"`) — verified 2026-08-16 |
There was a problem hiding this comment.
When the repository owner uses the bypass documented on the preceding line to merge without review, that GitHub ruleset bypass applies to the other rules in the same branch ruleset as well, including required status checks. Consequently this unconditional claim, repeated in SECURITY.md:26, overstates the protection for the one actor permitted to merge; either enforce checks in a ruleset the owner cannot bypass or explicitly document the exception.
Useful? React with 👍 / 👎.
Check off phishing-resistant 2FA, offline recovery codes, and VM egress firewall after maintainer confirmation. Co-authored-by: Jared Wray <me@jaredwray.com>
2 participants
Summary
Record the maintainer
lockdown-repo.shapply and remaining § 2 manuals, and list the now-live PR/tag/Actions controls inSECURITY.md.Status update
DEFENSE_IN_DEPTH.md: § 2 GitHub settings + CODEOWNERS → verified 2026-08-16 / PR #473DEFENSE_IN_DEPTH.md: Dependabot auto-dismiss low + medium → verified 2026-08-16 (maintainer)DEFENSE_IN_DEPTH.md: phishing-resistant 2FA, offline recovery codes, VM egress firewall → verified 2026-08-16 (maintainer)SECURITY.md: added live PR-required, admin-only tags, and Actions allowlist bulletsChanges
Verification
pnpm test(831 tests, 100% coverage)"Pull requests required"and"Tags only by admins"are active, with required checksbuild (22),build (24),build (26),zizmorReference
defense-in-depth-nodejs § 2