potiuk opened a new issue, #337: URL: https://github.com/apache/airflow-steward/issues/337
## Problem `security-issue-sync` reconciles a single tracker entry against its GitHub discussion, the inbound `<security-list>` thread, and any `<upstream>` fix PRs. There is currently no mechanism to detect drift between the project's own tracker and a **separate inventory of the same issues kept elsewhere** — for ASF projects, that other source of truth is the [ASF security dashboard](https://dash.security.apache.org). When the two diverge — a CVE allocated in the tracker but missing from the dashboard, an advisory published on the dashboard but the tracker still showing the issue open, a reporter credited in one and not the other — the divergence today is only caught by manual cross-referencing. That doesn't scale and quietly rots over time. ## Proposal Two pieces, in order: 1. **New substrate tool** — `tools/asf-dash-security`. Read-only client for `dash.security.apache.org`. Pulls the per-project inventory of advisories / CVEs / reporter credit / fixed-version metadata into a normalized in-memory record set that other skills can consume. Pure read (no write API on the dashboard side anyway). 2. **Optional reconciliation step in `security-issue-sync`** — when enabled by the adopter's project manifest, the sync skill performs a one-shot comparison between the tracker entry and the matching dashboard record (matched by CVE ID where present, or by a fuzzy title+date fallback). Surfaces drift in three buckets: - **Present in tracker, missing from dashboard** — needs publishing / allocating upstream. - **Present in dashboard, missing or stale in tracker** — tracker needs to be brought up to date (advisory text, fixed-versions, credit lines). - **Both present, fields disagree** — diff the disagreeing fields and propose a resolution direction (no auto-write — the security team picks the winning source). The step is **optional** because adopters outside ASF won't have this substrate at all; the configuration should gate the step cleanly and degrade to a no-op when the tool isn't configured. ## Out of scope - **Auto-correction.** Surface drift, do not silently overwrite either source. Security data is too high-stakes for that. - **Write API on `dash.security.apache.org`.** Even if one becomes available later, that's a separate skill — `security-cve-allocate` would absorb the write side. - **Cross-project reconciliation.** This is per-project — each adopter reconciles against its own dashboard slice. ## Why this lives in `security-issue-sync` (not a new skill) Sync is already the skill that reconciles one tracker entry against multiple external sources; the dashboard is just one more source. Folding it in keeps the security-team workflow as a single sync invocation rather than splitting attention across two skills. The reconciliation step is optional (gated by adopter manifest), so projects that don't have access to the dashboard see no change in behavior. ## Acceptance criteria - `tools/asf-dash-security` exists, has a `--help`-discoverable CLI, and has end-to-end test coverage against a recorded fixture of the dashboard response. - `security-issue-sync` documentation describes the reconciliation step and the project-manifest flag that enables it. - When the flag is off (or the substrate tool is missing), the step is a silent no-op. - When the flag is on, the step surfaces drift in the three buckets above and proposes a resolution direction the security team can confirm or reject — same proposal-confirmation pattern as the rest of `security-issue-sync`. -- 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]
