magpie-security-issue-import-from-scan

name	magpie-security-issue-import-from-scan
family	security
mode	Triage
description	Triage a security scanner's multi-finding output (read via a pluggable scan-format adapter) and turn findings into security work only after a complete operator-reviewed triage. Reads the scan's finding index plus its per-finding evidence; buckets each finding by disposition; applies only the operator's confirmed per-entry decisions. Publishes the report as a gist and can open a report-back PR.
when_to_use	Invoke when a security team member says "import the scan", "triage the <scanner> findings for <repo/component>", "import scan results from <issue>", or hands one or more paths / tree-URLs to scan report folders. The reference adapter is ASVS, but the flow is scanner-agnostic via `tools/scan-format/`. Skip for a single human-authored inbound report (use `security-issue-import`), a single markdown findings file with no per-finding evidence split (use `security-issue-import-from-md`), or a public PR to anchor on (`security-issue-import-from-pr`).
argument-hint	[scan-source ...] (one or more GitHub issues and/or report folders)
capability	capability:intake
license	Apache-2.0

security-issue-import-from-scan

This skill is the scanner on-ramp of the security-issue handling process. It converts a security scanner's multi-finding output into security work — but, unlike the human-report on-ramps, it never defaults to import. A scan emits dozens of machine-generated findings, most of which are by-design, already-fixed, or below the CVE bar for the project's threat model. So the first-pass deliverable is a triage report; any tracker or PR is opt-in per the operator's reviewed decision.

It composes with:

• security-issue-import — the Gmail on-ramp; this skill reuses its Step 2a fuzzy-dup search, its reject-pattern check, and its Step 7 tracker-creation path.
• security-issue-triage — whose Security-Model trust-boundary cheat-sheet and closed-invalid / positive-precedent searches do the actual classification.
• security-issue-fix — where a confirmed PR-worth finding becomes a public hardening PR.

The scan-format details (how to parse a given scanner's index + evidence, the finding schema) live behind a pluggable adapter at tools/scan-format/; ASVS is the reference adapter. The project declares its scan sources and enabled formats in <project-config>/project.md.

Golden rules

Golden rule 1 — triage-first, never auto-import. The first pass always produces the report; trackers and PRs are opt-in. Do not create any tracker, and do not open any PR, for a finding the operator has not confirmed.

Golden rule 2 — never blindly trust the scanner; default to 1-by-1. Scanner output systematically over-states severity and reachability, so the disposition table is a starting hypothesis, not a verdict. Default to a 1-by-1 review — present findings one at a time and let the operator decide each — unless a set is cleanly groupable and the call is obvious (an "already-fixed" cluster, a row of identical by-design findings). Actively invite the operator to dig in: for any finding they're unsure of, show the actual source code at the cited path, trace the call sites and the real attacker / threat model, and check whether the behaviour is reachable / already-mitigated / by-design — rather than acting on the title. State this expectation explicitly when presenting the report.

Golden rule 3 — PR-worth / defense-in-depth findings NEVER become trackers. They are proposed per entry and the operator opens a public PR or skips. A scanner-found, below-CVE-bar hardening does not belong in the private security tracker. Only the bucket — a genuine Security-Model violation reachable by an in-scope attacker — creates a issue.