docs(security): write down the threat model and correct two claims

.github/CODEOWNERS

@@ -111,6 +111,12 @@ src/config-dir.ts     @sunny-wego @yeouchien-wego @chuyeowego
 src/target.ts @sunny-wego @yeouchien-wego @chuyeowego
 src/config.ts @sunny-wego @yeouchien-wego @chuyeowego
 
+# THE DECLARED SCOPE. The self-update and credential entries above cite
+# SECURITY.md as their reason for being owned. If any writer could narrow that
+# scope without a signer's review, the stated reason for owning those paths
+# could shrink with it.
+/SECURITY.md @sunny-wego @yeouchien-wego @chuyeowego
+
 # THE INPUT TO THE api<->cli CONTRACT CHECK. Owned for REVIEW VISIBILITY, not
 # for runtime reach - and the distinction is the reason this comment exists.
 #

SECURITY.md

@@ -8,11 +8,13 @@ we prefer.** `security@wego.com` also reaches us, and is the right choice if you
 would rather not use GitHub for this.
 
 We prefer the Security tab because a report there can be taken into a temporary
-private fork and fixed there. `main` is public and `edge-cli` publishes on every
-merge to it, so a vulnerability fixed in the open is disclosed by its own diff
-before the fixed binary reaches a single user. Nothing else in this repository
-closes that window. A report there also notifies all ten repository admins,
-rather than landing in one mailbox.
+private fork and fixed there. `main` is public, and `edge-cli` publishes whenever
+a merge changes the CLI's source or build (the `paths:` filter in
+`.github/workflows/edge-cli.yml`). A fix for a vulnerability is such a change, so
+a fix developed in the open is disclosed by its own diff before the fixed binary
+reaches a single user. Nothing else in this repository closes that window. A
+report there also reaches the repository's maintainers through GitHub, rather
+than landing in one mailbox.
 
 Reporting this way is not what lets us publish an advisory. We can do that
 either way, and always could. It only changes where the fix is developed.
@@ -66,10 +68,45 @@ which version you are on.
 - The Wego API and website. This policy covers the CLI and its release pipeline;
   reports about the wider Wego platform are triaged by Wego's security team
   rather than by this repository's maintainers.
-- Findings that require an attacker to already control the user's machine or
-  their account.
+- Findings that require an attacker to already run code as the user, or to
+  already hold their Wego credentials. Exposure to *other* local users or
+  processes, such as the permissions on stored tokens, is in scope.
 - Missing hardening with no demonstrated impact.
 
+## Threat model
+
+This section is about the repository and its release pipeline. The scope above
+is about the people who run the CLI.
+
+**Who we defend against:** anyone outside the `wego` GitHub organization. That
+includes the author of a pull request from a fork, anyone who can influence the
+bytes an install or `wego update` downloads, and a compromised third party such
+as an upstream action, a dependency or a vendor.
+
+**What we protect, in priority order:**
+
+1. People running `wego update` and the `/install` script.
+2. The credentials the CLI holds.
+3. The release pipeline and the signed build records it produces.
+
+**Where the boundary sits:**
+
+- The repository is public, so a pull request from a fork runs with a read-only
+  `GITHUB_TOKEN` and no secrets. No workflow here uses `pull_request_target`,
+  and none that a fork can trigger starts a privileged `workflow_run`.
+- A change to a release path needs a review from a code owner, as listed in
+  `.github/CODEOWNERS`.
+- Only the release automation and the release signers can create a release tag.
+- What a release carries once it is built is described under "How releases are
+  protected" below.
+
+**Insiders:** Members of the organization acting within the access they were 
+granted are out of scope for this policy. Insider risk is managed through Wego’s 
+internal access and monitoring controls. A member who is coerced or negligent, or 
+whose account is taken over through phishing or social engineering, remains in 
+scope. Leaked or stolen member credentials are also in scope and are triaged 
+based on their demonstrated impact.
+
 ## How releases are protected
 
 Useful background if you are looking at the supply chain: