🎙️ task - feat(org): declare GitHub org security lockdown — actions policy, workflow token defaults, fork-PR policy, 2FA

Ouverte
  • Quelque chose ne va pas ?
#66 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
38/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Calme
Stack technique
typescript
Domaine
api, devops, security

Piste de recherche

Commencez par lire les pairs DeclaredGithubOrg* existants, l’utilisation de genDeclastructDao, ainsi que la table de correspondance des types du provider, la factory et les points d’entrée d’export du SDK. Implémentez les quatre ressources d’organisation demandées avec une nomenclature symétrique, des valeurs par défaut sécurisées, un comportement PUT idempotent et tout préflight 2FA indiqué. Le travail est terminé lorsque chacune dispose d’une couverture d’acceptation KEEP pour l’inclusion dans le plan et après l’application.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

🦫🎙️ dispatch to foreman

💧 task enqueued
   ├─ priority = ?
   ├─ yieldage = ?
   └─ leverage = ?

title
feat(org): declare GitHub org security lockdown — actions policy, workflow token defaults, fork-PR policy, 2FA
description

.what

ehmpathy/declastruct-aws needs to declare an org-level GitHub lockdown policy, and
four of the required resources do not exist in this package yet. this task asks for the
domain objects + DAOs + acceptance that make the whole policy declarable.

audit run against the live ehmpathy org on 2026-08-02 (read-only, via gh api -X GET).

.why

ehmpathy/declastruct-aws is a PUBLIC repo that provisions live AWS accounts. its
ehmpathy-demo-oidc role carries demoPermissionsPolicy (ec2:*, iam:*Role, budgets:*,
ce:*) and its trust policy uses StringLike on repo:ehmpathy/*:* — so any repo, any
branch, any workflow in the org can assume it.

that AWS-side hole gets fixed in declastruct-aws. but the GitHub-side controls that bound the
same blast radius are ALSO wide open, and today they can only be clicked, not declared:

live setting value why it matters
default_repository_permission write every member holds write on every repo -> can push a branch anywhere -> can assume the AWS role
two_factor_requirement_enabled false one phished member = org write = the AWS role
default_workflow_permissions write GITHUB_TOKEN is read-write by default across the org
can_approve_pull_request_reviews true a bot token can approve a PR (OWASP CICD-SEC-1)
allowed_actions all any third-party action, from anywhere, in any workflow
sha_pinning_required false tags are mutable pointers (OWASP CICD-SEC-3 / -4)

a control that can only be clicked drifts silently and leaves no diff for a reviewer. these
belong in a declared wish like every other resource.

.what already exists here (verified, no work needed)

  • DeclaredGithubOrgMemberPrivileges already covers defaultRepositoryPermission,
    membersCanCreateRepositories, membersCanDeleteRepositories,
    membersCanChangeRepoVisibility, membersCanForkPrivateRepositories,
    membersCanInviteOutsideCollaborators
  • DeclaredGithubBranchProtection, DeclaredGithubOrgRuleset, DeclaredGithubRepoRuleset
  • DeclaredGithubOrg READS twoFactorRequirementEnabled

.the gaps — 4 asks

1. DeclaredGithubOrgActionsPermissions

GET/PUT /orgs/{org}/actions/permissions

  • enabledRepositories: all | none | selected
  • allowedActions: all | local_only | selected
  • shaPinningRequired: boolean
  • and the companion GET/PUT /orgs/{org}/actions/permissions/selected-actions
    (githubOwnedAllowed, verifiedAllowed, patternsAllowed)

shaPinningRequired is the highest-value single field in this whole task — it enforces
rule.forbid.insecure.via=unpinned-third-party-code for every repo at once.

2. DeclaredGithubOrgActionsWorkflowDefaults

GET/PUT /orgs/{org}/actions/permissions/workflow

  • defaultWorkflowPermissions: read | write
  • canApprovePullRequestReviews: boolean
3. DeclaredGithubOrgActionsForkPrPolicy

GET/PUT /orgs/{org}/actions/permissions/fork-pr-workflows (and the repo-level peer)

  • the approval-required policy for fork PRs, plus whether a fork PR may read secrets or hold
    a write token

this is the one that lets outside contributors fork and contribute WITHOUT our resources,
which is exactly the posture we want — but it must be declared, not assumed.

4. twoFactorRequirementEnabled -> settable

it is readonly on DeclaredGithubOrg today. make it declarable, either by a move to
DeclaredGithubOrgMemberPrivileges or as its own resource. note it may need a plan-time
preflight: GitHub removes members who lack 2FA when it is turned on, so a set should
surface who would be dropped.

.acceptance

each of the four owes the full four, per
rule.require.dao-and-acceptance-per-declared-resource:

  1. a domain object with unique keyed on the org
  2. a DAO via genDeclastructDao
  3. provider registration (type map + factory) and sdk export
  4. acceptance coverage: plan-inclusion + post-apply KEEP

plus:

  • name them symmetric with the extant DeclaredGithubOrg* peers
    (rule.require.symmetry-with-peer-resources)
  • secure defaults where a default is shipped — a consumer who declares one of these
    without thought should land in the pit of success, not on GitHub\x27s permissive default
  • set must be idempotent (these are all PUT-shaped, so upsert is natural)

.the desired end state, for reference

DeclaredGithubOrgActionsPermissions.as({
  org, enabledRepositories: "all",
  allowedActions: "selected", shaPinningRequired: true,
});
DeclaredGithubOrgActionsWorkflowDefaults.as({
  org, defaultWorkflowPermissions: "read", canApprovePullRequestReviews: false,
});

.sources

filed by beaver on behalf of vlad, out of the ehmpathy-camp grove behavior in
ehmpathy/declastruct-aws

Langage dominant
TypeScript
Étoiles
0
Forks
0
Aucune PR mergée en 30 j

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de ehmpathy/declastruct-github

Toutes les issues de ehmpathy/declastruct-github

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.