Skip to content

README.md

Latest commit

 

History

History
157 lines (132 loc) · 9.74 KB

README.md

File metadata and controls

157 lines (132 loc) · 9.74 KB
Raw

Table of Contents generated with DocToc

Security reports

Scope. Works on any project, ASF or not. The ASF intake path (security@, Vulnogram CVE flow) is the default profile; non-ASF adopters swap it for GitHub Security Advisories / a MITRE CNA through the adapter/config layer.

End-to-end automation for an ASF project's security-issue handling process — from inbound report on the project's security@ mailing list through to a published CVE record on cve.org. Eleven skills that compose into the canonical 16-step lifecycle, three that produce, verify, and maintain the project's own security model, one that carries that model into an OSS Scanner enrolment, plus one read-only supporting skill for tracker-stats dashboards (sixteen skills total).

Why a framework skill family? The 16-step process exists across the foundation; every project's security team runs essentially the same workflow with project-specific scope labels, mailing-list addresses, milestone formats, and canned-response wording. Lifting the workflow into a project-agnostic framework lets each adopter plug their specifics into <project-config>/ and reuse the skills verbatim.

Tip

Why this family

  • Every report that lands on security@ becomes a tracked issue, with a receipt drafted to the reporter
  • The whole lifecycle in one place — triage, CVE allocation, the fix PR that does not leak the embargo, and the advisory
  • Read-only until you confirm: no label flips, no closes, and no CVE allocated without you saying so

Install & first runs

Install & first runs has the install command for this family, the files to configure before the first run, and the skills to try first.

Skills

Lifecycle skills

Skill Purpose
security-issue-import Import new reports from <security-list> into <tracker>.
security-issue-import-from-pr Open a tracker for a security-relevant fix opened as a public PR.
security-issue-import-from-md Bulk-import findings from a markdown report.
security-issue-import-from-scan Import findings from a security scanner output (Trivy, Grype, etc.) into <tracker>.
security-issue-import-via-forwarder Import reports relayed through the ASF security forwarder when no direct reporter contact exists.
security-issue-triage Propose an initial-triage disposition (VALID / DEFENSE-IN-DEPTH / INFO-ONLY / INVALID / PROBABLE-DUP / FIX-ALREADY-PUBLIC) for each tracker still in Needs triage; opens a discussion comment, never flips the label.
security-issue-sync Reconcile a tracker against its mail thread, fix PR, release train, and archives.
security-cve-allocate Allocate a CVE for a tracker (Vulnogram URL + paste-ready JSON).
security-issue-fix Implement the fix as a public PR in <upstream>.
security-issue-deduplicate Merge two trackers describing the same root-cause vulnerability.
security-issue-invalidate Close a tracker as invalid with a polite-but-firm reporter reply.

Security-model skills

The lifecycle skills above route one report. These four work on the document they route it against — the project's security model: three maintain it so that routing has something to cite, and one carries it into an external scanner's enrolment. See security-model-preparation.md for the lifecycle and the rationale.

Skill Purpose
security-model-prepare Produce a first model for a project that has none, in draft-first mode, and land it with its discoverability chain as one PR per repository.
security-model-verify Pre-flight an existing model: can an agent mechanically reach it, and does it cover the minimum bar a triager depends on. Discoverability is the only hard gate.
security-model-update Read the decision history back into the model — new known-non-finding entries and a model-gap list, regression-checked against past valid reports.
security-submit-to-oss-scan Prepare the enrolment (or update) PR that puts a project into Anthropic's OSS Scanner — project.yaml, an offline-capable Dockerfile, and a threat_model.md derived from the security model — and guide the maintainer through testing it first.

The rubric these skills measure against is maintained externally by Alpha-Omega (https://github.com/alpha-omega-security/threat-model) and referenced by URL; Magpie keeps no local copy.

Supporting tools

Skill Purpose
security-tracker-stats-dashboard Generate a self-contained HTML dashboard of <tracker> repo statistics (lifecycle bands, opened-vs-untriaged backlog, mean time to triage / first response / fix). Read-only — never modifies tracker state.

The tracker itself need not be a GitHub repository. tracker.platform selects one of three backends of the security-tracker contract: a private GitHub repository (default), Markdown files in a private Git or SVN working copy — learning the format of the reports already there — or a Jira project with an issue-security level. /magpie-setup config asks which; the design explains the choices.

Deep documentation

  • poc-handling-policy.md — what an agent may do with reporter-supplied proof-of-concept code: static review by default, isolated container only on explicit approval, never on the host.
  • security-model-preparation.md — the produce / verify / update lifecycle for the project's own security model: the external Alpha-Omega rubric, the AGENTS.md → SECURITY.md discoverability chain and why it is the only hard gate, why substantive findings go to the private list rather than a public issue, the provenance tags that make a draft-first model safe, and the fence around the known-non-findings section.
  • process.md — the 16-step lifecycle with Mermaid diagram + per-step description; the label lifecycle state diagram + label reference table. The authoritative process reference.
  • roles.md — who owns which steps (issue triager / remediation developer / release manager), the shared conventions every role observes (keeping the reporter informed, recording status transitions, confidentiality), and the role-by-role workflow walkthroughs.
  • fixing-security-issues.md — hands-on guide for a remediation developer picking up a CVE-allocated tracker and shipping the fix.
  • how-the-security-team-works.md — how the team operates and how a new member lands: the triager rotation that runs the skills and delegates, tracker access, mail list subscription, expected reading, first triage shadow.
  • advisory-records.md — recording a published CVE in the project's own security records (a CVE JSON file or a per-release-line page in its site repository, over Git or Subversion), proposed by sync once cve.org shows it published.
  • threat-model.md — release-blocking threat model for the security skill family: trust boundaries, adversary personas, STRIDE matrix per skill, mitigation cross- reference, residual risk, and the re-audit cadence.
  • forwarder-routing-policy.md — when a tracker has no direct reporter contact (ASF-relay, read-only GHSA, anonymous tip), the skills route reporter-facing communication through the forwarder. The policy defines when that mode applies, the milestone list (events that do get relayed), and the negative list (events that don't — including credit-confirmation questions and regular workflow status).

Cross-references