Skip to content

feat(security): manage confidential advisory responder access - #34

Merged
vitormattos merged 3 commits into
mainfrom
feat/confidential-advisory-response-access
Nov 4, 2026
Merged

vitormattos merged 3 commits into
mainfrom
feat/confidential-advisory-response-access

Conversation

@vitormattos

Copy link
Copy Markdown
Member

Problem

Repository Maintain does not grant access to an unpublished repository security advisory. Granting the organization-wide Security Manager role to maintainers would unnecessarily expand access and administrative powers.

Architecture

  • Use a separate, secret security-response organization team. Advisory administrators grant this team write access on individual confidential advisories; no organization-wide security role or repository-level team permission is required.
  • Add a narrowly scoped, declarative team-access reconciler for future unpublished advisories in LibreSign/libresign only. It does not change any advisory created before the adoption timestamp.
  • A dedicated GitHub App must have only Repository security advisories: write on the libresign repository. Its key belongs in a protected, branch-restricted Actions environment, isolated from the existing ruleset-management App.
  • Keep both repository enablement variables disabled until the dedicated App is provisioned and a manual dry-run passes. The hourly workflow remains inert until then.

Security boundaries

  • Only the collaborating_teams field can be patched. Existing invited users, researchers, other teams, state, publication, CVE, forks, credits and vulnerability metadata are never changed by the automation.
  • Restricted repository and expected team guards; fail closed if current advisory collaborator metadata is unavailable or postconditions cannot be verified.
  • Do not print advisory identifiers, titles, private fork paths or aggregate advisory counts to public CI logs.
  • The team membership roster and any specific confidential advisory references remain outside this public repository.
  • No change to existing rulesets, release workflows or disclosure state.

Verification

  • node --test tests/security-advisory-access.test.mjs: 10 tests passed (dry-run, idempotency, collaborator preservation, date/state cutoff, private triage, malformed data and denied access).
  • An authenticated read-only live run completed against the GitHub API.
  • security-advisory-access.config.json validated as JSON; no embargoed advisory data is committed.
  • Signed GPG commit with DCO verified.

Operational prerequisite

A new dedicated GitHub App (repository security advisories write, installed on LibreSign/libresign only) and environment-scoped key are still required. They are deliberately not bundled into the broader ruleset administrator. See docs/security-advisory-access.md for setup and enabling the scheduled reconciliation.

Risk and limitations

The GitHub API does not expose a narrower 'add advisory team' token scope: Repository security advisories: write is required and could publish advisories if compromised. Restrict the GitHub App to one repository, protect workflow edits via reviews and keep credentials only in the dedicated environment. No unpublished advisory details appear in this PR.

Signed-off-by: Vitor Mattos <1079143+vitormattos@users.noreply.github.com>
@vitormattos
vitormattos requested a review from a team as a code owner November 4, 2026 15:29
Signed-off-by: Vitor Mattos <1079143+vitormattos@users.noreply.github.com>
Signed-off-by: Vitor Mattos <1079143+vitormattos@users.noreply.github.com>
@vitormattos
vitormattos merged commit 0049064 into main Nov 4, 2026
4 checks passed
@vitormattos
vitormattos deleted the feat/confidential-advisory-response-access branch November 4, 2026 15:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant