Table of Contents generated with DocToc
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. Nine skills that compose into the canonical 16-step lifecycle, plus one read-only supporting skill for tracker-stats dashboards.
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.
| 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-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. |
| 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. |
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.how-to-fix-a-security-issue.md — hands-on guide for a remediation developer picking up a CVE-allocated tracker and shipping the fix.new-members-onboarding.md — onboarding for a new security-team member: tracker access, mail list subscription, expected reading, first triage shadow.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).The skills resolve project-specific content from the security- workflow files in <project-config>/ — see the adopter scaffold's README.md for the file-by-file index. Required at minimum:
project.md — identity, repos, mailing lists, toolscanned-responses.md — reporter-facing reply templatesscope-labels.md — scope label → CVE product mappingrelease-trains.md — release-manager attributiontitle-normalization.md — CVE-title regex cascadeOptional but commonly needed: milestones.md, fix-workflow.md, security-model.md, naming-conventions.md.
docs/prerequisites.md — what a security triager / remediation developer / release manager needs installed before invoking any skill.