Table of Contents generated with DocToc

• Security threat model
  • Purpose
  • Scope
  • Out of scope
  • Assumptions
  • Definitions
  • Trust boundaries
    • B1 — Untrusted-input and skill
    • B2 — Skill and private tracker
    • B3 — Private tracker and public upstream
    • B4 — Pre-disclosure and post-disclosure
    • B5 — Agent host and ASF infrastructure
  • Adversaries
    • P1 — Malicious reporter
    • P2 — Hostile public contributor
    • P3 — Compromised supply-chain dependency
    • P4 — Network-layer adversary
    • P5 — Negligent insider
  • Asset inventory
  • STRIDE matrix per skill family
    • Skill family A — Inbound import
    • Skill family B — Triage and reconciliation
    • Skill family C — CVE allocation
    • Skill family D — Public remediation
    • Skill family E — Closure
  • Cross-skill threats
    • X1 — Prompt-injection chained across skills
    • X2 — Tracker URL leaks the existence of an embargoed issue
    • X3 — Sandbox bypass via developer override
    • X4 — Credential exfiltration via dependency
  • Mitigation cross-reference
  • Residual risk and accepted gaps
  • Re-audit cadence and ownership
  • Change log

Security threat model

Purpose

Apache Steward automates the 16-step security-issue lifecycle on behalf of an ASF project’s security team. Every skill that ships in the framework either reads from, writes to, or moves data across a trust boundary that the foundation treats as release-blocking — the private security tracker, the embargoed pre-disclosure window, the upstream public repository, the CVE Numbering Authority, and the credentials that authorise each of those moves.

This document is the authoritative threat model for that automation. It enumerates the trust boundaries, the adversaries that may attack each boundary, the asset each adversary is after, and the mitigations the framework relies on. It is a release-blocking artefact: a Drafting skill that touches a security tracker without a STRIDE row in this document is, by construction, unreviewed.

The intended readers are:

• security-team members evaluating whether to enable a skill in Triage or Drafting against their tracker;
• contributors proposing a new skill in the security family or a change that crosses one of the trust boundaries below;
• ASF Security and the project PMC during a pre-release security review.

Scope

In scope for this document:

• the eight skills in the security workflow skill family;
• the privacy-LLM tooling (redactor + checker) those skills invoke on inbound content;
• the agent host’s sandbox configuration in .claude/settings.json and the secure-agent-internals guide;
• the credential surfaces a skill may touch — gh tokens, Vulnogram OAuth tokens, Gmail OAuth tokens for the security mailing list, and any per-adopter scoped tokens declared in projects/_template/;
• the data flows across the five trust boundaries enumerated in Trust boundaries.

Out of scope

The following are out of scope and should be addressed in their own threat model when they are introduced:

• Auto-merge auto-merge — not implemented in v1; see docs/modes.md. When proposed, Auto-merge requires its own threat model entry and a separate ASF Security review.
• generic Drafting beyond security-issue-fix — proposed but not shipped. Each new Drafting skill ships with its own STRIDE row in the STRIDE matrix.
• the underlying LLM provider’s infrastructure — treated as a trusted component subject to its own provider-side threat model. The framework’s posture is that prompts and tool outputs that cross the provider boundary are subject to the redactor contract; the provider’s data-handling guarantees are an upstream concern.
• adversaries with physical access to the maintainer’s workstation — outside the agent’s authority; covered by the maintainer’s host hygiene, not by the framework.
• denial of service against ASF infrastructure (lists.apache.org, cveprocess.apache.org, GitHub) — the framework can amplify but not originate; rate-limit posture is delegated to those services.

Assumptions

The threat model is valid only while these assumptions hold. A violation of any assumption invalidates the corresponding mitigation and triggers a re-audit.

1. The maintainer reviewing a Drafting output is competent and acting in good faith. Drafting ships agent-authored fixes gated on human review; the human is the final defence against subtle agent error. A maintainer who rubber-stamps Drafting output collapses Drafting into Auto-merge, which is explicitly out of scope.
2. The agent host’s filesystem sandbox is enforced by the runtime, not by the agent’s good behaviour. permissions.deny entries are advisory and visible to the agent; sandbox.filesystem.denyRead and sandbox.network.allowedDomains are runtime-enforced. The real controls are the runtime ones; see secure-agent-internals §172.
3. The private security tracker enforces its own access control. The framework does not gate access to the tracker; it only avoids leaking content out of the tracker. A misconfigured tracker (public visibility, over-broad collaborator list) is a tracker problem, not a framework problem — though the framework declines to operate against a tracker it detects as public.
4. Credentials in ~/.config/apache-steward/ are honoured by denyRead. The default sandbox blocks the agent from reading that path. An adopter who relaxes that block (for example by adding it to allowRead) accepts the resulting threat surface.
5. The CVE Numbering Authority API and the ASF mailing-list archives are authentic and uncompromised. The framework treats responses from cveawg.mitre.org, cveprocess.apache.org, and lists.apache.org as authoritative for the data they return.

Definitions

• Tracker — the private security issue tracker for a project. In apache/airflow-security this is a private GitHub repository; the framework is tracker-agnostic but ships GitHub-issue support.
• Upstream — the public source repository where the fix PR is opened (for the pilot adopter, apache/airflow).
• Embargo window — the period between a report arriving on security@ and the public advisory being published. During this window the existence and detail of the issue are confidential.
• Triage / Mentoring / Drafting / Auto-merge — see docs/modes.md. Triage is read-only triage; Mentoring is mentoring; Drafting is agent-authored PRs gated on human review; Auto-merge is auto-merge (not shipped).
• Privileged egress — any agent action that publishes content outside the agent host: a comment on the public upstream, a CVE record submission, a mailing-list reply, a gh pr create.
• Untrusted ingress — any agent action that reads attacker- controlled content: a mailing-list message body, a tracker comment, a public PR description, an issue title, a markdown report file.

Trust boundaries

                                    ┌───────────────────────┐
                                    │    Public upstream    │
                                    │  (apache/<project>)   │
                                    └──────────┬────────────┘
                                               │
        ── B3: confidentiality wall ──         │  ── B4: embargo wall ──
                                               │
                                    ┌──────────┴────────────┐
                                    │   Private tracker     │
                                    │  (apache/<…>-security)│
                                    └──────────┬────────────┘
                                               │
        ── B2: skill ↔ tracker ──              │
                                               │
              ┌──────────┬───────────┬─────────┴──────┬────────────┐
              │          │           │                │            │
        security-list   PR body   tracker body    md report    cve.org
              └──────────┴───────────┴────────────────┴────────────┘
                                    │
        ── B1: untrusted-input ↔ skill ──
                                    │
                            ┌───────┴───────┐
                            │  Skill core   │
                            └───────┬───────┘
                                    │
        ── B5: agent host ↔ ASF infra ──
                                    │
                       ┌────────────┴────────────┐
                       │   Egress allowlist      │
                       │ (api.github.com, …)     │
                       └─────────────────────────┘

B1 — Untrusted-input and skill

Any byte the agent reads that originated outside the framework is untrusted. The agent treats five untrusted-ingress sources as attacker-controlled by default:

• security@<project>.apache.org mail bodies, including reporter- supplied attachments and HTML-formatted multipart sections;
• private tracker issue bodies and comments — confidential but not trusted, since a reporter or co-maintainer may have authored them;
• public PR descriptions, commit messages, and review comments pulled from upstream;
• markdown report files passed to security-issue-import-from-md;
• the contents of any URL the agent fetches inside the network allowlist (a lists.apache.org archive page, a public commit on github.com).

The threat at this boundary is content-as-instruction: a reporter who embeds prompt-injection text aimed at getting the agent to exfiltrate tracker contents, mis-classify the issue as invalid, or re-route the fix PR.

B2 — Skill and private tracker

The tracker holds the confidential body of the report and the internal triage discussion. Crossing this boundary in the read direction is constrained by the agent’s gh token scope; in the write direction the constraint is the permissions.ask entries in .claude/settings.json for gh issue * and gh api * -X *. The threat is unauthorised modification (Tampering) and unauthorised read by a skill operating in a context where the user did not expect tracker access.

B3 — Private tracker and public upstream

The confidentiality wall. The tracker is private; upstream is public. A skill that copies content from the tracker to upstream without redaction breaks the wall. The framework’s posture is:

• tracker URLs and IDs are public-safe (treated as reference-only identifiers; see AGENTS.md §confidentiality);
• tracker contents (titles, bodies, comments) are private;
• the security framing of an upstream PR (the words “security”, “CVE”, “vulnerability”) is embargoed until the advisory ships.

security-issue-fix is the only skill that legitimately crosses this boundary in the write direction during the embargo window.

B4 — Pre-disclosure and post-disclosure

The embargo wall is temporal, not topological. The same data crosses from confidential to public at advisory-publish time (Step 13). Skills must not act as if the wall has fallen until they have observed Step 14 (public advisory URL captured) for the specific tracker. The threat is premature disclosure — a skill that adds the CVE ID to a public PR title before the advisory is out, or that posts a credit note on the PR before Step 16 runs.

B5 — Agent host and ASF infrastructure

Egress from the agent host to ASF and CVE infrastructure. Constrained by sandbox.network.allowedDomains. The threat is two-way: an exfiltration attempt by a compromised dependency (which the allowlist limits to ASF/CVE/GitHub destinations only — still bad, but bounded), and an inbound malicious response from one of those destinations (a tampered archive page).

Adversaries

The adversaries below are the personas the framework defends against. Each persona has a name, a capability profile, a goal, and a typical attack surface. Threats in the STRIDE matrix are tagged with the persona ID that motivates them.

P1 — Malicious reporter

Submits a crafted message to security@<project>.apache.org whose real purpose is not to report a vulnerability but to manipulate the agent that triages the report.

• Capabilities — can author arbitrary mail body, headers, and attachments; cannot read the tracker; cannot see the agent’s internal state.
• Goal — induce the agent to (a) leak existing tracker contents back into a reply, (b) auto-close a real outstanding issue as invalid, (c) post the agent’s prompt or credentials into a public reply, or (d) cause the agent to fetch and execute attacker-hosted content.
• Surface — security-issue-import, security-issue-import-from-md, security-issue-deduplicate when it pulls a recent report into context.

P2 — Hostile public contributor

A contributor on the public upstream who has noticed a fix PR or issue and is trying to deduce the embargoed vulnerability from clues the agent leaks.

• Capabilities — can read all public upstream content; can comment on public PRs; cannot read the tracker.
• Goal — confirm the existence of an embargoed issue, deduce its scope before the advisory, or pre-empt the advisory by publishing an independent disclosure.
• Surface — security-issue-fix when it writes the public PR; security-issue-sync when it posts cross-references.

P3 — Compromised supply-chain dependency

A package the agent host transitively depends on (a Python dependency of a tool, a gh extension, the redactor’s models) turns malicious — typosquat, account takeover, or upstream compromise.

• Capabilities — runs arbitrary code in the agent host’s process at the privilege level the host runs at.
• Goal — exfiltrate tracker contents, exfiltrate credentials, pivot into upstream commit signing.
• Surface — every skill, equally; the threat is at B5 and at the credential surface, not at any specific skill.

P4 — Network-layer adversary

An attacker between the agent host and lists.apache.org, cveprocess.apache.org, cveawg.mitre.org, or api.github.com.

• Capabilities — TLS interception (assumed unsuccessful against publicly-pinned ASF/MITRE/GitHub endpoints), DNS tampering (assumed unsuccessful against system resolvers), or outright connection blocking.
• Goal — feed the agent a tampered archive page or a tampered CVE record so the agent acts on bad data.
• Surface — any skill that fetches a URL inside the allowlist; most acute for security-issue-sync (which pulls archive pages) and security-cve-allocate (which posts to CVE infra).

P5 — Negligent insider

A security-team member with legitimate tracker access who accidentally pastes confidential content into a public surface, or who misconfigures the agent in a way that broadens its authority beyond what the threat model assumes.

• Capabilities — full tracker access; ability to relax the sandbox (.claude/settings.json is in the repository and can be edited locally); ability to override the redactor.
• Goal — none; the persona is non-malicious. The threat is accidental disclosure or accidental relaxation of a control.
• Surface — every skill, but the framework’s defence is the redactor (catches accidental paste-through) and the permissions.ask prompts on privileged egress (forces a human re-look before a write to upstream or CVE).

Asset inventory

Each row is an asset the framework defends, the adversaries interested in it, and the boundary that protects it.

STRIDE matrix per skill family

The eight security skills group into five families by where they sit in the lifecycle. STRIDE rows below are per-family; per-skill deviations are noted inline.

Each row carries a threat ID (<family>.<n>), the STRIDE category, the adversary, the boundary, and the mitigation. Mitigations link to the cross-reference table.

Skill family A — Inbound import

Skills: security-issue-import, security-issue-import-from-pr, security-issue-import-from-md.

Skill family B — Triage and reconciliation

Skills: security-issue-sync, security-issue-deduplicate, security-issue-invalidate.

Skill family C — CVE allocation

Skill: security-cve-allocate.

Skill family D — Public remediation

Skill: security-issue-fix.

Skill family E — Closure

Steps 13–16 of the lifecycle, currently driven by humans with agent assistance from security-issue-sync. No dedicated skill family E exists in v1; this section captures the threats the agent must respect when assisting closure.

Cross-skill threats

Threats that do not belong to a single skill but emerge from the composition of skills.

X1 — Prompt-injection chained across skills

A reporter (P1) submits a crafted report on day 0. security-issue-import imports it. On day 7, a triager invokes security-issue-sync, which reads the tracker body the agent wrote on day 0 — including any text the importer didn’t recognise as injection but propagated. The injection now executes inside security-issue-sync’s context.

• Why this is hard — defence at A.1 alone is insufficient; the redactor must also run on tracker reads, not only on inbound mail.
• Mitigation — M.1 is invoked on every untrusted-ingress read in every skill, not only on the initial import. The skills framework treats the tracker body as untrusted-ingress on read.

X2 — Tracker URL leaks the existence of an embargoed issue

A tracker URL is public-safe per AGENTS.md §confidentiality. But if a tracker URL is posted on the public upstream (in a PR linking to the fix) before the advisory ships, an observer (P2) sees both the URL and the fix-PR diff and combines them into a confirmation.

• Mitigation — M.12 plus a secondary check in security-issue-fix: the tracker URL is added to the PR body only after Step 14.

X3 — Sandbox bypass via developer override

A maintainer (P5) running locally edits .claude/settings.json to add ~/.config/apache-steward/ to allowRead because they are debugging an authentication issue. They forget to revert. The next agent run reads the credentials.

• Mitigation — M.29 (planned, not yet shipped — see residual risk #4). When implemented, the framework’s CI will lint the shipped .claude/settings.json against an allowlist of changes on every PR that touches the file. The local-override case is unavoidable if the maintainer edits the file outside a PR — accepted residual.

X4 — Credential exfiltration via dependency

A compromised package (P3) reads GH_TOKEN from the environment and POSTs it to an allowlisted host (an attacker-controlled GitHub repository would not be allowlisted, but api.github.com is — the attacker can write to a repo they control via the token itself).

• Mitigation — M.14 limits destinations but not what is sent there; M.15 limits the token’s scope (read-only on private tracker, write on a single upstream repo); the residual is the ability of an attacker holding the token to write to that one upstream repo. Accepted as bounded.

Mitigation cross-reference

Each M.<n> ID below corresponds to a specific control. Where the control is implemented in code or config, the link points there; where it is a human process, the link points to the document that describes it.

Residual risk and accepted gaps

The framework does not claim zero residual risk. The following are known gaps the security team accepts at v1, with the rationale and the trigger that would force a re-evaluation.

1. Per-skill redactor wiring is partial. PR #81 finding 9 identified that the redactor contract (M.1) describes the what but not which skills call the redactor at which step. v1 ships the redactor; v1.1 ships the per-skill wiring. Trigger for re-eval: any new Drafting skill, or any reported false-negative from the redactor on a skill that does not yet wire it explicitly.
2. Mailing-list flood (A.7) has no framework-side rate limit. The agent will process whatever the mailing-list moderator lets through. Trigger for re-eval: a reported import-budget exhaustion or a gh rate-limit incident attributable to inbound volume.
3. Patch-as-disclosure (D.2) is intrinsic, not a control failure. The mitigation is operational (minimise the embargo-to-release window), not architectural. Trigger for re-eval: any foundation-level decision to support a private-PR workflow that delays public commit until advisory time. v1 explicitly chose the public-PR path; see process.md Step 8 vs Step 9.
4. Local sandbox override (X3) is unavoidable. A maintainer editing .claude/settings.json locally cannot be prevented. The CI lint (M.29) catches changes shipped via PR but not local overrides used during a single agent run. Trigger for re-eval: a runtime mechanism that can attest to the sandbox config in use.
5. Quarterly red-team testing is not yet scheduled. PR #81 finding 8 recommended a recurring red-team exercise against the security-skill family. v1 ships without a scheduled cadence. Trigger for re-eval: automatic — a re-audit is due before v1.1 ships, see Re-audit cadence and ownership.
6. permissions.deny is advisory. PR #81 finding 3 documented that the deny list is visible to the agent and is not a real control; the network allowlist is the real control. The deny list remains in the shipped settings as a defence-in-depth signal and as a hint to a benign agent. Trigger for re-eval: a runtime change that promotes the deny list to enforced.
7. TLS pinning is not used (M.17). The framework relies on the system trust store. A compromise of a system-trusted CA would admit P4 attacks against allowlisted destinations. Trigger for re-eval: a published CA-compromise incident that affects the allowlisted destinations.
8. Attribution drift (D.6). Agent authorship is recorded via a Generated-by: commit trailer per AGENTS.md; Co-Authored-By: for agents is forbidden. A future ASF policy change on agent-authoring conventions would force a revision of M.25 and the trailer wording. Trigger for re-eval: ASF Legal or PMC guidance on agent-authoring attribution.
9. Skill-scope discipline (M.7) is convention, not enforcement. No runtime mechanism prevents a skill’s prompt from chaining into the behaviour of another skill mid-run; the discipline is a property of how each SKILL.md is written and reviewed. An injection that successfully prompts the agent to behave as a different skill (A.4, B.1) would not be blocked by a runtime guard. Trigger for re-eval: any reported case of cross-skill behaviour drift, or the introduction of a runtime mechanism that could enforce single-skill activation.
10. Commit signing (M.22) is per-adopter, not framework-enforced. A P3 dependency that bypasses signing on the agent host evades D.3 entirely. The mitigation depends on adopter policy plus the human reviewer’s verification of the signed commit chain. Trigger for re-eval: a framework-level mechanism to attest to the signing posture of an agent run, or an ASF foundation- level mandate.
11. Token-rotation cadence is undocumented in the adopter scaffold (M.18). The v1 projects/_template/ ships no template that prescribes rotation cadence for Vulnogram, Gmail, or gh tokens. Adopters are expected to operate a per-team rotation practice; the framework cannot detect or enforce it. Trigger for re-eval: drafting a tokens.md template under projects/_template/, or any incident report involving stale-token misuse on an adopter deployment.

Re-audit cadence and ownership

This document is release-blocking and time-bounded. The cadences below are the framework’s commitment.

• On every new Drafting skill — the proposing PR must add a STRIDE row to the matching skill family in STRIDE matrix per skill family. A Drafting skill without a row does not pass review.
• On every change to .claude/settings.json — the proposing PR must update the Trust boundaries and Mitigation cross-reference sections to reflect the new sandbox posture.
• On every change to the 16-step process — the proposing PR must reconcile the affected STRIDE rows and the Residual risk section.
• Quarterly red-team exercise — a structured adversarial review against P1–P5 personas, scope-bounded to the skills in scope at the time of the exercise. Findings are filed against the framework as PRs that update this document and (if applicable) the process.md flow.
• Pre-release audit — every framework release that bumps the major version, or that ships a new Drafting skill, requires a fresh pass over Assumptions, Adversaries, and Residual risk.

Ownership is the framework’s security-skill-family maintainers (see the CODEOWNERS for docs/security/ and .claude/skills/security-*/). ASF Security review is required on the pre-release audit.

Change log