potiuk opened a new pull request, #498:
URL: https://github.com/apache/airflow-steward/pull/498
## Summary
- New **Step 4a — Preliminary reject-class triage** in
`security-issue-import`, between Step 4 (extract fields) and Step 5 (propose).
It runs on **every** surviving candidate.
- It compares the candidate against the project's reject-pattern taxonomy
(the `<project-config>/canned-responses.md` headings + their Security-Model
anchors) and emits one of `reject-with-canned <pattern>` /
`hold-for-human-review` / explicit no-match — always reported in the Step 5
proposal.
- New `step-4a-reject-class` eval (3 cases) covering the plain-reject,
borderline-hold, and no-match outcomes.
## Motivation
Upstreams Override 1 of the Apache Airflow security team's adopter
(`.apache-magpie-overrides/security-issue-import.md`). Most security teams keep
a documented set of "we already know these are not vulnerabilities" patterns —
exactly the negative replies that already live in `canned-responses.md`. When a
plain instance of one lands on `security@`, importing it as `Needs triage` then
closing it days later wastes triage capacity and leaves the reporter with a
stale disposition. Catching the unambiguous cases at import time pre-empts a
user round-trip ("is this one we normally reject?").
The override's own "should this be upstreamed?" note asked for exactly this:
*"a framework hook that reads a project-config-supplied rejection-pattern table
and applies the same check."*
## Shape (per setup-override-upstream Step 4)
**Add a step** (mandatory). No new config knob — the taxonomy is the
*existing* `<project-config>/canned-responses.md`, which the skill already
references throughout. The airflow-specific pattern table from the override
(Simple Auth Manager, image-scan dumps, Dag-author-input, etc.) stays
adopter-local; the framework step only mandates *running the check*, the
three-way verdict, the proposal-reporting discipline, and the confidence
discipline. It composes with the Step 2b closed-invalid / prior-rejection
cross-check (added in #497): taxonomy match = "out of scope by the Security
Model"; Step 2b = "we already rejected this exact thing".
## Migration path for existing adopters
Additive. Adopters already maintain `<project-config>/canned-responses.md`;
the step reads its headings as the taxonomy. The default-to-import bias (Golden
rule 1) is unchanged for everything that doesn't *plainly* match — borderline
candidates route to `hold-for-human-review`, never to a default reject. Nothing
to opt out of.
## Test plan
- `prek run` green on all touched files (skill-and-tool-validate /
capability sync, markdownlint, typos, placeholders, license).
- New eval
`tools/skill-evals/evals/security-issue-import/step-4a-reject-class` (3 cases)
asserts: a DAG-author-only SQL sink → `reject-with-canned`; the same sink with
a claimed non-author REST path → `hold-for-human-review`; a cross-privilege
stored XSS → `no-match` (default-import).
- `lychee --offline --include-fragments` clean for the changed files — the
two new intra-doc anchors (`#step-4a-…`, `#step-2b-…`) resolve; the only
flagged links are the framework's `<project-config>` placeholder tokens,
excluded by `.lychee.toml`.
- Validated against the airflow-s adopter's live import runs.
Generated-by: Claude Code (Claude Opus 4.8)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
