docs(placeholders): the org-level security address has three names and none is registered

[potiuk]

What

The org-level security address — the foundation-wide advisory-admin inbox, as distinct from a project's own security list — is referred to by three different names, none of which is registered in the placeholder table in AGENTS.md § Placeholder convention:

name	where it appears	notes
<security-team-list>	skills/security-issue-sync/github-advisory.md	one use, in the advisory-relay delivery step
<asf-security-list>	AGENTS.md (two uses, cross-project triage guidance)	ASF-branded, in a framework whose whole premise is governance-agnosticism
security_inbox.foundation_security_address	projects/_template/project.md	the actual org-level config path

By contrast the project list is unambiguous: placeholder <security-list>, key security_list, registered in the table.

Why it matters

The distinction is real and load-bearing. github-advisory.md uses both in the same instruction:

Create a draft email to the org's advisory-admin security team (<security-team-list>) … Always CC the project <security-list> so the project security team stays looped in.

Two different addresses, deliberately. Anyone "tidying" the one-off <security-team-list> into the registered <security-list> — which looks like an obvious normalisation — would silently turn that into "email X and CC X", dropping the project security team from an advisory relay. I nearly did exactly that while following up on #1055, and only stopped after reading the surrounding sentence.

So the current state is a trap: the odd-looking name is the correct one, and the "fix" is wrong.

There is a second-order problem too. <asf-security-list> bakes a vendor into a placeholder, in a repository that has spent real effort removing exactly that (#1055 removed the last hardcoded security@apache.org from skills/, #997 and #998 before it). A non-ASF adopter reading AGENTS.md sees a placeholder named after a foundation they are not part of.

Suggested fix

Decide on one name for the org-level address, register it in the placeholder table with its source key, and use it consistently. Something org-neutral — <org-security-list>, or <foundation-security-list> to match the config key — would sit better alongside <governance-body> and <project-stage>, which are already named to avoid ASF-specific vocabulary.

Then:

• replace both <asf-security-list> uses in AGENTS.md;
• replace the <security-team-list> use in github-advisory.md;
• add the row to the placeholder table, sourced from security_inbox.foundation_security_address, noting that it is org-level and inherited rather than declared in project.md (the template already says "Do not declare it here").

Worth doing as one change so the three names collapse together rather than leaving a fourth.

Related

• fix(security): remove ASF address from skills #1055 removed the last hardcoded security@apache.org from skills/, which is what surfaced this.
• The sibling fix for the project list — AGENTS.md and security-cve-allocate both cited a mailing_lists.security key that does not exist — is in flight separately.