Skip to content

vulnerability-response.md

Latest commit

 

History

History
79 lines (67 loc) · 4.41 KB

vulnerability-response.md

File metadata and controls

79 lines (67 loc) · 4.41 KB
Raw

Internal vulnerability-response process

What the maintainer actually does when a report arrives through a SECURITY.md channel (email to toni@git-agentic.com or GitHub private vulnerability reporting). The public policy tells reporters what to expect; this document is the internal side of those commitments. Written as OSTIF-audit follow-up T-16 (G-010/G-031/G-032 — docs/audit/ostif-best-practices-audit.md).

Roles

  • Handler: the maintainer (currently Toni Bergholm, toni@git-agentic.com) owns every step below — acknowledgment, triage, fix, disclosure. When a second maintainer exists, name a primary and a backup here.

The pipeline boundary (agents and public triage)

This repository's default triage is automated and public: agents operate the public GitHub issue tracker (docs/agents/issue-tracker.md), and the audit workflow auto-files findings as public issues. Security reports are the one class of work that must never enter that pipeline:

  1. A privately received report is never filed, labeled, commented on, or otherwise processed through public GitHub issues until the fix has shipped and the coordinated-disclosure date has passed. Tracking before then happens in a GitHub draft security advisory on this repository (private, access-controlled), which is the system of record for the report.
  2. An agent triaging public issues that encounters content resembling an undisclosed vulnerability (a crasher with security impact, a confidentiality break, a report that should have been private) must stop, apply no labels, post no analysis, and escalate to the handler privately.
  3. Agents are not given access to draft advisories or the private report channel. Remediation work an agent performs for a security fix is scoped to the fix branch and must not restate the vulnerability details in public commit messages, PR bodies, or issues before disclosure.

Review requirement for security fixes

A security-fix PR requires a human review distinct from the author before merge, regardless of who or what authored it. Agent-authored security fixes are never merged on the strength of another agent's approval (audit G-032). Since 2026-07-18 the main ruleset enforces this repo-wide for all PRs — 1 required approval from a principal other than the last pusher, with stale approvals dismissed on push and last-push approval required — so a security fix gets the same distinct-reviewer gate as any other change, plus the human-author requirement above for agent-authored fixes.

Steps on receipt

  1. Acknowledge within 3 business days (the SECURITY.md commitment), from the handler, confirming receipt and the expected next update.
  2. Record the report as a draft security advisory (not a public issue): report text, reporter contact and credit preference, affected commit, initial severity guess.
  3. Triage within 7 business days: reproduce (ask for the PoC if missing), assess impact against docs/THREAT-MODEL.md — a documented deliberate boundary is out of scope as a vulnerability (tell the reporter which boundary and why; welcome it as a hardening suggestion), a real break gets a severity and priority. Communicate the verdict to the reporter.
  4. Plan remediation in the advisory: fix approach, target timeline within the 90-day disclosure window, whether history/ciphertext already written is affected (rotation ≠ erasure — state plainly what a fix does and does not retroactively protect).
  5. Coordinate outward if the vulnerability affects third parties (e.g. a protocol break affecting anyone running sc serve, or an upstream dependency issue): notify affected projects before public disclosure.
  6. Fix and verify with the reporter: land the fix through a PR meeting the review requirement above; ask the reporter to confirm the fix against their PoC before closing.
  7. Disclose: publish the advisory at the agreed date (default ≤ 90 days from acceptance), credit the reporter unless they declined, note the fixed commit/version, and add any new deliberate boundary to THREAT-MODEL.md.

After disclosure

  • Backport policy: pre-1.0, only main is fixed (per SECURITY.md).
  • If the report revealed a process failure (not just a code bug), run the relevant section of incident-response.md.