fix(security-issue-sync): credit scanner findings as tool, not anonymous - #1124
Merged
Merged
Conversation
The anonymise gate contradicted the framework's own bot-credits policy. `tools/cve-tool-vulnogram/bot-credits-policy.md` states that automation which surfaces a real vulnerability is credited with `type: "tool"` — "Scanners, AI agents, and automation that surface a real vulnerability deserve the credit". But the gate in `security-issue-sync` replaced the credit with `anonymous`, discarding the discovery attribution entirely. The gate conflated two separate concerns. Suppressing an individual who never consented to public credit is correct. Withholding the vendor's commercial product name is correct. Neither requires erasing the fact that a tool made the discovery. Separates them: the scrub now writes the scanner's declared *public credit name* — emitted with `type: "tool"` per the policy — and keeps `anonymous` only as the fallback when no public credit name is declared. Confidentiality is unchanged: the product token still never reaches a public surface, and the audit-trail surfaces are still untouched. Adds a `Public credit name` column to the `scanner-products.md` template so an adopter declares the public-safe name of the tooling that ran the scan, distinct from the confidential product token. Existing adopters are unaffected until they fill it in — a blank column keeps today's `anonymous` behaviour. Also corrects the template's claim that *Reporter credited as* is always emitted as `type: finder`; per the policy it is `finder` for a human and `tool` for automation. Generated-by: Claude Code (Claude Opus 5)
potiuk
added
family:security
This was referenced Aug 29, 2026
potiuk
added a commit
that referenced
this pull request
Aug 29, 2026
…anonymous (#1131) Reconciles #1124 with #1127, as promised in #1127's description. #1124 made `anonymous` the fallback for a scanner-sourced finding whose scanner declares no public credit name. #1127 then landed the finder-credit policy, whose Rule 2 says the opposite: where there is no named finder, omit the `finder` credit rather than writing a placeholder. Both are on `main`, so the framework currently contradicts itself in three places. Rule 2 wins. It is grounded in an ASF CVE reviewer's feedback on a published batch — "I'm not sure how helpful it is to credit 'anonymous' as finder, just leave it out" — and a `credits[]` carrying only the remediation developer is a complete record, whereas a literal `anonymous` occupies the space a reader scans for attribution and answers nothing. Nothing else about #1124 changes: the scanner's public credit name is still written when declared, still emitted with `type: "tool"`, and the confidential product token still never reaches a public surface. Only the no-name-declared branch changes, from writing a placeholder to omitting the row. Grep confirms no `anonymous` fallback remains under skills/, projects/, or tools/. Generated-by: Claude Code (Claude Opus 5)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
security-issue-syncanonymise gate contradicts the framework's own bot-credits policy:tools/cve-tool-vulnogram/bot-credits-policy.mdsays automation that surfaces a real vulnerability is creditedtype: "tool", but the gate replaces the credit withanonymous.Public credit namecolumn to thescanner-products.mdtemplate so the public-safe name of the scanning tooling is declared separately from the confidential product token.Motivation
Found while reconciling a downstream adopter's override against the framework default. The adopter had independently rewritten this rule after the
anonymousbehaviour produced 44 CVE records carrying a bogusanonymousfinder credit — findings that a scanning tool had genuinely discovered and that the CVE 5.x schema has an exact category for.The confidentiality goal is sound and unchanged. The product token still never reaches a public surface, and the audit-trail surfaces (mailing-list thread field, status rollup, mail thread) stay untouched. What changes is only what replaces the suppressed name.
Migration path
Backwards-compatible. The new column is optional: an adopter who leaves it blank keeps today's
anonymousbehaviour exactly. Adopters opt in by declaring a public credit name per scanner. No skill step is renumbered and no anchor moves.Test plan
prek run --files <the three changed files>— all hooks pass, includingmarkdownlint,check-placeholders, andskill-and-tool-validate.lychee --config .lychee.toml --offlineover the changed files — 77 links OK, 0 errors; the in-hook lychee also passes.bot-credits-policy.mdresolve, and theStep 5b 1bback-reference fromgather.mdis unchanged.🤖 Generated with Claude Code