-
Notifications
You must be signed in to change notification settings - Fork 9
Expand file tree
/
Copy pathCODEOWNERS
More file actions
65 lines (61 loc) · 3.75 KB
/
CODEOWNERS
File metadata and controls
65 lines (61 loc) · 3.75 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
# CODEOWNERS — required reviewer routing for security-sensitive paths.
#
# Branch protection on `main` / `v10-rc` should have "Require review from
# Code Owners" enabled (admin task — see
# docs/security/SUPPLY_CHAIN_HARDENING.md §C). With that toggle on, any
# PR that touches a path listed below requires an approving review from
# at least one of the listed owners before it can merge. Without
# CODEOWNERS, the "code-owner review" branch protection rule is a no-op:
# there is nobody to ask, so the requirement is silently satisfied for
# every PR. The 2024 reviewdog supply-chain compromise hinged on this
# exact failure mode — an attacker landed a workflow change that no
# named maintainer was required to approve.
#
# Owner syntax: GitHub @-usernames or @org/team names. Teams are
# preferred for shared infra (no churn when the active maintainer
# rotates). Individual handles are fine for the bootstrap period below
# and can be migrated to a team mention later without touching the
# patterns.
#
# Bootstrap owners — derived from the most recent committers on these
# paths at the time CODEOWNERS landed. Replace with `@OriginTrail/<team>`
# once a maintainers' team is created in the org. Each path needs at
# LEAST two owners so no single account compromise can self-approve a
# malicious change here.
# ----------------------------------------------------------------------
# CI workflow files — full attacker surface. Anything that runs on a
# privileged event (`push` to main, `pull_request_target`, `schedule`,
# `workflow_dispatch`) inherits the workflow's `permissions:` block,
# so a malicious workflow change is equivalent to handing out a token
# in the worst case. These MUST get a security-aware review.
.github/ @branarakic @Jurij89 @zsculac
.github/workflows/ @branarakic @Jurij89 @zsculac
.github/actions/ @branarakic @Jurij89 @zsculac
.github/dependabot.yml @branarakic @Jurij89 @zsculac
.github/zizmor.yml @branarakic @Jurij89 @zsculac
.github/CODEOWNERS @branarakic @Jurij89 @zsculac
# ----------------------------------------------------------------------
# Publish credentials surface — anything that influences what gets
# packed, published, or which packages are public. A change that flips
# a `"private": true` to false on a previously-private package, or
# that adds a postinstall script, lands here.
package.json @branarakic @Jurij89 @zsculac
pnpm-lock.yaml @branarakic @Jurij89 @zsculac
pnpm-workspace.yaml @branarakic @Jurij89 @zsculac
.npmrc @branarakic @Jurij89 @zsculac
packages/*/package.json @branarakic @Jurij89 @zsculac
packages/*/.npmrc @branarakic @Jurij89 @zsculac
# ----------------------------------------------------------------------
# Release / deploy scripts — covered as code, not config. A modification
# here can change what `pnpm build` produces or which file the release
# workflow uploads as a release asset, both of which are publish-trust
# boundaries.
scripts/ @branarakic @Jurij89 @zsculac
packages/cli/scripts/ @branarakic @Jurij89 @zsculac
# ----------------------------------------------------------------------
# Security documentation — keeps the threat-model description in sync
# with the controls actually configured in this repo. Drift between
# the doc and the configured controls was the gap that PR review found
# the first time around.
docs/security/ @branarakic @Jurij89 @zsculac
SECURITY.md @branarakic @Jurij89 @zsculac