Skip to content

Add a draft security threat model (THREAT_MODEL.md) + SECURITY.md + discoverability wiring#12421

Open
potiuk wants to merge 2 commits into
apache:masterfrom
potiuk:asf-security/threat-model-2026-07-04
Open

Add a draft security threat model (THREAT_MODEL.md) + SECURITY.md + discoverability wiring#12421
potiuk wants to merge 2 commits into
apache:masterfrom
potiuk:asf-security/threat-model-2026-07-04

Conversation

@potiuk

@potiuk potiuk commented Jul 4, 2026

Copy link
Copy Markdown
Member

This is a proposal for the Maven PMC to review — please correct, reject, or discuss as needed. The PMC owns the document; nothing here is a requirement.

This adds a draft umbrella THREAT_MODEL.md for the Apache Maven family, a SECURITY.md (apache/maven doesn't currently have one — the model has lived only on maven.apache.org/security.html), and an AGENTS.md wiring AGENTS.md -> SECURITY.md -> THREAT_MODEL.md so an automated scanner can mechanically discover it. Path 3 as agreed on the list (we draft the v0, the PMC reviews).

Generated from Maven's public artefacts (security.html, the Maven 4 docs, the repos) via the threat-model-producer rubric. Provenance-tagged throughout; every (inferred) claim routes to a numbered §14 question (20 of them).

Per the two asks from the list it carries:

  • a 3.x-vs-4.x axis on the trust boundaries (the §2 component-family table + a "Line" dimension in §5a/§6), not a single profile;
  • explicit coverage of the Maven-4-new surface: the consumer / build-POM transform (published POM != source POM), mvnup, the reworked mvnenc encryption, and the resolver changes.

The load-bearing call the model makes (please confirm): §9 states that no build/plugin sandbox exists — arbitrary code execution during a build is BY DESIGN, and §11a lists that (plus "deployed POM != source POM", dependabot alerts on test-scope deps, etc.) as known non-findings, so a scan doesn't report Maven's core behaviour as vulnerabilities.

What's most useful from the PMC: walk the §14 questions and confirm / correct / strike each in-thread — a one-line each is enough. We fold the answers in, then open the per-repo AGENTS.md -> SECURITY.md pointer PRs across the rest of the scope once the model shape is agreed.

Context: the ASF Security team is preparing projects for an automated agentic security scan we're piloting; discoverability is the one hard prerequisite. This PR only adds files — it edits no existing content.

…iscoverability wiring

Generated-by: Claude Code
…nore

apache-rat 0.13 (still used by some PMC repos) does not recognise the short
SPDX identifier, and newer RAT flags the .ratignore file itself. Switching the
generated THREAT_MODEL.md / SECURITY.md / AGENTS.md to the full AL-2.0 header
(HTML comment) makes them pass the license check on every RAT version, so the
.ratignore exemption is no longer needed.

Generated-by: Claude Code
Comment thread THREAT_MODEL.md
- *(inferred)* — reasoned from Maven's architecture, domain knowledge, or the absence of a feature; **not yet confirmed.** Each *(inferred)* tag names the §14 question that must ratify it, e.g. *(inferred, Q5)*.
- **Draft confidence:** ~26 documented / 0 maintainer / ~59 inferred. This is a react-to-me draft, not a ratified model — the heavy *(inferred)* weighting is expected for a v0 the PMC has not yet reviewed.

**What Maven is.** Apache Maven is a build-automation and dependency-management tool for JVM projects. Given a project description in `pom.xml` (the Project Object Model), Maven resolves declared dependencies and build **plugins** from configured **repositories** into a local repository (`~/.m2/repository`), then executes a lifecycle of plugin goals — compiling, testing, packaging, signing, and deploying code. Plugins and build **extensions** are ordinary JVM artifacts that Maven downloads and executes **as arbitrary code in the build JVM**. Maven is invoked from the CLI (`mvn`, or the `mvnd` daemon, or a project-local `mvnw` wrapper) by a developer or a CI runner. Its security model is therefore fundamentally a **supply-chain and arbitrary-code-execution** model, and — by explicit design — Maven does not sandbox the code it is asked to build or the plugins it is asked to run.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is true, though thinking about it now I wonder if we should do better than that?

Comment thread THREAT_MODEL.md

**The 3.x-vs-4.x axis (carried on this table).** Maven is mid-transition. Most plugin `master` branches still compile and run against the **Maven 3.9.x** API; seven "split" plugins have moved `master` to the **Maven 4** API and keep a `*-3.x` maintenance branch on the 3.9.x API. The runtime line changes the trust surface (consumer-POM transform, `mvnenc`, resolver 2.x, `mvnup` — all Maven-4-only; see §6/§9). Each branch-target is therefore tagged with the **Maven API line** it targets, and a finding is triaged against **that** line's surface.

| # | Repository / component | Branch-target(s) | Maven API line | Touches outside process | In model? |

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like quite a few are missing from this table including:

  • maven-war-plugin
  • maven-ear-plugin

probably others. are non-plugins in scope here? If so, then also maven-filtering, maven-shared-utils, and maven-archiver. and I don't recall the current repos, but all the doxia stuff

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants