This is an automated email from the ASF dual-hosted git repository.
potiuk pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/airflow-steward.git
The following commit(s) were added to refs/heads/main by this push:
new e7b3b8f docs(agents): reply drafts to reporter must use conditional
language for dependency claims (#141)
e7b3b8f is described below
commit e7b3b8fc02455f370e6d70936b394b20a123febb
Author: Jarek Potiuk <[email protected]>
AuthorDate: Tue May 12 23:22:54 2026 +0200
docs(agents): reply drafts to reporter must use conditional language for
dependency claims (#141)
When a reporter claims the vulnerability lives in one of the
project's dependencies, drafted replies must not adopt the claim
as fact. The project has no authority to confirm a vulnerability
in code it does not maintain — that judgement belongs to the
dependency's own maintainers and CNAs.
Add a sibling rule under "Writing and editing documentation" that
shows do / don't phrasings (forward to the dependency's
maintainers, condition the assessment on their confirmation), and
pair the rule with the existing
"Reporter-supplied CVSS scores are informational only" rule (same
shape: position from the reporter the team has not yet evaluated).
Carve out the case where the report actually describes a flaw in
the project's own code that happens to involve a dependency — at
that point the finding is ours and the brevity rule above takes
over.
---
AGENTS.md | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 51 insertions(+)
diff --git a/AGENTS.md b/AGENTS.md
index 0e97827..841e672 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -25,6 +25,7 @@
- [Threading: drafts stay on the inbound Gmail
thread](#threading-drafts-stay-on-the-inbound-gmail-thread)
- [ASF-security-relay reports: a special case for
drafting](#asf-security-relay-reports-a-special-case-for-drafting)
- [Point reporters to the project's Security Model, don't re-explain
it](#point-reporters-to-the-projects-security-model-dont-re-explain-it)
+ - [Reporter claims about dependencies: conditional language
only](#reporter-claims-about-dependencies-conditional-language-only)
- [Linking CVEs](#linking-cves)
- [Linking tracker issues and PRs](#linking-tracker-issues-and-prs)
- [Mentioning project maintainers and security-team
members](#mentioning-project-maintainers-and-security-team-members)
@@ -1005,6 +1006,56 @@ Security Model first. If no chapter covers the case,
that is a signal
the Security Model should be updated upstream (in the project's source
repository) rather than duplicated in the canned responses.
+### Reporter claims about dependencies: conditional language only
+
+When a reporter says the vulnerability they found lives in **one of
+the project's dependencies** (a third-party library, a transitive
+package, an upstream tool the project bundles), drafted replies
+must **not adopt the claim as fact**. The project's security team
+has no authority to confirm a vulnerability in code it does not
+maintain — that judgement belongs to the dependency's own
+maintainers and CNAs.
+
+Use **conditional phrasing** in every reply that touches the
+claim:
+
+- ✗ *"Thanks for finding this vulnerability in `<library>`."* —
+ endorses the claim.
+- ✗ *"We've confirmed the issue in `<library>` is exploitable
+ through our usage."* — endorses the claim plus a downstream
+ consequence.
+- ✓ *"Thanks for the report. We're forwarding your finding to
+ `<library>`'s maintainers; if confirmed there, we will reassess
+ whether our usage exposes it."*
+- ✓ *"We will track the upstream report. Once `<library>` issues
+ an advisory, we will evaluate the impact on our deployment."*
+
+Why this matters:
+
+- The reporter can screenshot or forward a confirmation in our
+ voice as evidence of an unconfirmed vulnerability in a
+ third-party project — pressuring its maintainers and damaging
+ relationships the project depends on.
+- A wrong endorsement (the dependency maintainers disagree, or
+ the behaviour turns out to be intentional / not exploitable as
+ described) becomes a public correction the team has to retract.
+- We may not have the deployment context to know whether the
+ claimed primitive is reachable in our usage at all. A
+ conditional reply is honest about that.
+
+This rule pairs with
+[Reporter-supplied CVSS scores are informational only — never propagate
them](#reporter-supplied-cvss-scores-are-informational-only--never-propagate-them):
+the team independently assesses anything that ends up attributed
+to the project's voice. Dependency claims are the same shape — a
+position from the reporter the team has not yet evaluated.
+
+When the report turns out to describe a real vulnerability in the
+project's **own** code that *happens to involve* a dependency
+(e.g. the project calls the dependency's API in a way that
+exposes a primitive), this rule no longer applies — that finding
+is the project's and the reply can state it plainly per the
+brevity rule above.
+
### Linking CVEs
Whenever a CVE ID appears in text this repository produces — status
