Add SECURITY.md + AGENTS.md pointing at the published security model

[potiuk]

This is a proposal for the PMC to review — please correct, reject, or discuss as needed. Nothing here is a requirement; the maintainers are the decision-makers.

This adds two small files so that an automated scanning agent can mechanically discover the project's existing security model through the conventional AGENTS.md → SECURITY.md chain:

• SECURITY.md — points at the published model at https://avro.apache.org/project/security/, which remains the single source of truth. Nothing is duplicated or restated here; the file is a pointer.
• AGENTS.md — a Security section linking to SECURITY.md.

No existing content is changed — both files are new, and the security model itself is untouched.

Context

The Apache Security team is preparing the project for an automated agentic security scan we're piloting. Such scans anchor to a project's own threat model, and refuse to run when the model can't be found from the repository — refusing upfront beats spending PMC reviewer time triaging a noise-heavy report produced against no model at all.

Avro is in the good case here: the project already has a published security model, so nobody needs to write one. We read it against our rubric and it is usable as-is — it is explicit about what the library is responsible for, that transport is outside the library's scope, that avoiding leaks into side channels such as log files is a stated non-goal, that schema parsing itself is safe while SPIs remain a trust decision, and it places four numbered duties on applications using Avro. That is more than many projects start with.

The only gap was mechanical: there is no AGENTS.md or SECURITY.md at the repository root, so the discovery chain doesn't exist. This PR is that chain and nothing more.

This was requested on the PMC's private list — Martin Grigorov asked us to go ahead on behalf of the Avro PMC.

Not in this PR

Separately, and explicitly not blocking anything, the PMC has invited us to propose deepening the published model. The sections most useful to a scanner are an enumerated adversary model, a "known non-findings" list (the single biggest lever for cutting false positives in a report), and triage dispositions. Those touch the website content rather than this repository, so they'll come as a separate proposal.

Questions and pushback welcome — happy to adjust wording or file placement to match project house style.

[uros-b]

Nice, @potiuk!

[steveloughran]

It's possible to put abbreviated asf copyright headers in (as hadoop security.md does); this reduces the token count.
Maven rat plugin may need updating to recognise these though.

Content-wise, looks straightforward. After all, it's not defining the model, just linking to the existing one.

[potiuk]

Thanks @steveloughran — that's a fair point and it lands harder here than it would on a normal file, because these two files exist specifically to be read by agents. The current ASF header is 17 lines of boilerplate in front of about 12 lines of actual content, so the header is the majority of what a scanner ingests. Hadoop's one-line <!-- SPDX-License-Identifier: Apache-2.0 --> is a real improvement on that ratio.

Two things I checked before answering, both of which make this the PMC's call rather than mine:

• Avro runs apache-rat-plugin, so the header has to satisfy RAT, and
• there is currently no SPDX header anywhere in this repo — this would be the first.

So it isn't just a wording swap: it sets a precedent for the repo and needs the RAT config taught to accept the short form. That's a small change, but it's a house-style decision I shouldn't make on the PMC's behalf in a PR that's otherwise deliberately additive-only.

Happy either way:

1. Leave the full header — consistent with every other file in the repo, costs tokens.
2. Switch both files to SPDX and update the RAT config in this PR — I'll make the change and confirm mvn apache-rat:check passes before asking for another look.

If anyone from the PMC has a preference, say the word and I'll do (2). Otherwise I'd default to (1) purely on the "don't set a repo-wide precedent inside an unrelated PR" principle, and we can do SPDX repo-wide as its own change if it's wanted.

And thanks for confirming the content reads straightforwardly — that was the main thing I wanted eyes on.